Hi,

I have a module with many global arrays,

!------------------------------------------------------
 module Global
      integer, save                            :: dims(4)=(/0,0,0,0/)
      real (kind = 8), save, allocatable       :: A(:,:,:,:)
! save data read from a file
    	real (kind = 8), save, allocatable       :: B(:,:,:,:) ! B to E
have the same size
    	real (kind = 8), save, allocatable       :: C(:,:,:,:) ! as A
      real (kind = 8), save, allocatable       :: D(:,:,:,:)
    	real (kind = 8), save, allocatable       :: E(:,:,:,:)
            . . .
            . . .
            . . .
    	logical, save, allocatable               :: L(:,:,:,:)

 contains
    !
    ! subroutines here
    !
 end module Global
 !--------------------------------------------------------

 When I read in the dimensional information to dims, these arrays can
be allocated.

 The process is
        * read in dimensions
        * allocate A, populate A using file stream I/O
        * allocate B, save intermediate results in B (e.g. sub1(B,A))
        * allocate C, do something like sub2(C,B)
        etc

 Everything works fine when I compile the codes with g95.

However, when I tried to use Intel Fortran compiler 9, it only works
when the data size is relatively small, say dims= (/30,30,8,30/). For
large dimensions like dims=(/256,256,25,30/), it crashes when I call
sub3 to allocate D array. The error report is stack overflow:

 forrtl: severe (170): Program Exception - stack overflow
 ( I have not found the error code 'severe (170)' in Intel docs)

  The computer has plenty of memory (4GB). I also check the status
after each allocate statement.

  I am wondering why the data size matters.
  Is it related to the 'save' attribute?
  Will it be helpful if I reduce the number of those global arrays?

Any suggestions and comments are welcome.

Thanks.

Ben

try to set the stack size larger

ulimit -s 512000

or similar (google). If the arrays are large, also temporaries
generated by the compiler can be a problem, and these might be hard to
avoid.

Joost

Joost wrote:
> try to set the stack size larger
> 
> ulimit -s 512000
> 
> or similar (google). If the arrays are large, also temporaries
> generated by the compiler can be a problem, and these might be hard to
> avoid.
> 
> Joost
> 

Even better: ulimit -s unlimited

cheers,

Rich

Ben wrote:
> Hi,
> 
> I have a module with many global arrays,
> 
> !------------------------------------------------------
>  module Global
>       integer, save                            :: dims(4)=(/0,0,0,0/)
>       real (kind = 8), save, allocatable       :: A(:,:,:,:)
> ! save data read from a file
>     	real (kind = 8), save, allocatable       :: B(:,:,:,:) ! B to E
> have the same size
>     	real (kind = 8), save, allocatable       :: C(:,:,:,:) ! as A
>       real (kind = 8), save, allocatable       :: D(:,:,:,:)
>     	real (kind = 8), save, allocatable       :: E(:,:,:,:)
>             . . .
>             . . .
>             . . .
>     	logical, save, allocatable               :: L(:,:,:,:)
> 
>  contains
>     !
>     ! subroutines here
>     !
>  end module Global
>  !--------------------------------------------------------
> 
>  When I read in the dimensional information to dims, these arrays can
> be allocated.
> 
>  The process is
>         * read in dimensions
>         * allocate A, populate A using file stream I/O
>         * allocate B, save intermediate results in B (e.g. sub1(B,A))
>         * allocate C, do something like sub2(C,B)
>         etc
> 
>  Everything works fine when I compile the codes with g95.
> 
> However, when I tried to use Intel Fortran compiler 9, it only works
> when the data size is relatively small, say dims= (/30,30,8,30/). For
> large dimensions like dims=(/256,256,25,30/), it crashes when I call
> sub3 to allocate D array. The error report is stack overflow:
> 
>  forrtl: severe (170): Program Exception - stack overflow
>  ( I have not found the error code 'severe (170)' in Intel docs)
> 
>   The computer has plenty of memory (4GB). I also check the status
> after each allocate statement.
> 
>   I am wondering why the data size matters.
>   Is it related to the 'save' attribute?
>   Will it be helpful if I reduce the number of those global arrays?
> 
> Any suggestions and comments are welcome.
> 
> Thanks.
> 
> Ben
> 

Some array operations use a lot of stack space when it is necessary to 
create a temporary array. Array allocations should not need much stack 
space, but it is not unusual for a default stack limit to be rather 
small. Assuming a POSIX environment, what do you get from the command 
"limit stack"? You can try a larger number, or just try "limit stack 
unlimited".

As for the SAVE attributes, they probably have no effect, but it is a 
good practice. It is possible (but unlikely) for values to become 
undefined if a module is not USEed from the main program.

Joe

No, I've personally experienced that you need an explicit limit on some
systems. I don't know exactly why.

Joost

Joost <jv244@cam.ac.uk> wrote:

> No, I've personally experienced that you need an explicit limit on some
> systems. I don't know exactly why.

I don't recall having seen that, though maybe I've just forgotten. I'll
believe that you have seen it. I posit that those cases, whatever they
are, where you must have an explicit limit are outnumbered by the cases
where specifying an explicit limit will cause problems because it ends
up being to small at some point (probably long after the user has
forgotten about having specified it).

Thus, I think I'll "vote" for Rich Townnsend's position of unlimitted as
being "better", though I'd agree with qualifying it with "in most
situations".

-- 
Richard Maine                     | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov            |       -- Mark Twain

Joost wrote:
> No, I've personally experienced that you need an explicit limit on some
> systems. I don't know exactly why.
> 
> Joost
> 

OK, I wasn't aware of that. But in the OP's case, he should be OK with 
'unlimited', since the only system he could possibly be using (at the 
moment) is Linux, right?

cheers,

Rich

> Some array operations use a lot of stack space when it is necessary to
> create a temporary array. Array allocations should not need much stack
> space, but it is not unusual for a default stack limit to be rather
> small. Assuming a POSIX environment, what do you get from the command
> "limit stack"? You can try a larger number, or just try "limit stack
> unlimited".
>
> As for the SAVE attributes, they probably have no effect, but it is a
> good practice. It is possible (but unlikely) for values to become
> undefined if a module is not USEed from the main program.
>
> Joe

Do I need to define or assign the stack size during the program
compilation?

OR I need to set the stack size to some large number or unlimited every
time I run the compiled program.


Ben

every time you run the program. And if it matters, in parallel runs on
all nodes where the code runs. 

Joost

Hi,

After increasing the stack size to 1GB, the overflow is gone. I have
not tried the unlimit option yet.  Hope this won't affect the system
performance and other applications. BTW, I also found some good
discussions about the stack overflow at the Intel Fortran forum.

Thank you all.

Ben

In article <e0hbvq$4vk$1@scrotar.nss.udel.edu>,
Rich Townsend  <rhdt@barREMOVEtol.udel.edu> wrote:

>OK, I wasn't aware of that. But in the OP's case, he should be OK with 
>'unlimited', since the only system he could possibly be using (at the 
>moment) is Linux, right?

Mondern 32-bit Linux kernels are one of the ones that does different
things for large and infinite stack sizes.

-- greg