Re: run a program with more than 2**32 bite

In article <1191063889.189829.121570@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
sarahimi1983@xxxxxxxxx writes:

$ gfortran -mcmodel=medium [filename]

If it is a 64-bit version linux, you should not need the -mcmodel
option.

$ ./a.out

(what is the total image size in medium size of 64bit gfortan?is it
2**48 bite?)

The (virtual) address space is probably 2**48.


one of answers was guiding me to use m64 in order to transform
variable into 64bit correctly but
I don't know what does this mean.
for example suppose "A" is a real variable in a program with total
size more than 2**32.how should be its definietion?

You probably want to use dynamic memory allocation.

when I'm using "real-m64::A",fortran compiler dosen't realize
it and takes an error.

I doubt that any compiler will recognize the above. Just use
REAL.

this is a module of my program ,defining variables.
what changes should I make precisely for going to 64bit one?

module test
real,dimension(128,-64:64,128,-64:64)::x,y,z,vx,vy,vz,fp,fg
end module

If I did the arithmetic correctly (need more coffee), the
above is about 8 GB of memory. Without seeing the actual
error messages, I suspect gfortran compiles the above without
problem until it hands the intermediate code to the linker.
ld then has problems.

Try

module test
implicit none
integer, n1, n2_lo, n2_hi, n3, n4_lo, n4_hi
real, allocatable, dimension(:,:,:,:) :: x,y,z,vx,vy,vz,fp,fg
end module test

program sara
use test
implicit none
integer stat
!
! I'd suggest a read statement, so you can change the size to see
! what is the maximum permitted by you OS, ie,
! read(*,*) n1, n2_lo, n2_hi, n3, n4_lo, n4_hi
n1 = 128 ! Or whatever dimension
n2_lo = -64
....
n4_hi

allocate(x(n1, n2_lo:n2_hi, n3, n4_lo:n4_hi), stat=stat)
if (stat > 0) then
print *, 'allocation error'
stop
end if
!
! Repeat as needed for other variables.
!
end program sara

I'll note that if x, y, and z are the Cartesian coordinates, you
don't need 4 dimensional arrays. By using a 1 dimensional array,
you save yourself a boat load of memory.


--
Steve
http://troutmask.apl.washington.edu/~kargl/
.