Does the problem run with other (possibly smaller-grid) cases? If so, there’s possibly an un-checked ALLOCATE
statement that is failing but for which the status is not being checked, and the program is going ahead and trying to use what should have been the result of that ALLOCATE
anyway.
Generally, you can get more information in the backtrace if you compile with both debug and backtrace enabled (for GNU gfortran, compile-flags -g -O0 -fbacktrace
; for Intel ifort or PGI pgf90, -g -O0 -traceback
) instead of the -O2
or -O3
optiomization-fl;ags you probably have.
BTW, here’s an example of a properly-checked ALLOCATE statement, if you can find out where the seg-fault is happening, and it turns out to be related to a previously-ALLOCATE
d array:
…
INTEGER ISTAT ! allocation-status
…
ALLOCATE( BUF1( NCOLS1NROWS1, NLAYS1 ),
& BUF2( NCOLS2NROWS2, NLAYS1 ), STAT = ISTAT )
IF ( ISTAT .NE. 0 ) THEN
WRITE( *, ‘( A, I10)’ ) ‘Buffer allocation failed: STAT=’, ISTAT
STOP
…
Error status numbers ISTAT are compiler-vendor dependent; it’s relatively easy to find them for Intel and PGI compilers. However, gfortran error-numbers are not documented properly (according to extensive searches I have performed). The most-frequent allocation-error is “not enough memory” (either in terms of actual system RAM or in terms of your limit memoryuse… quota; however, I have seen allocation for other (programmer-bug) reasons.
[Forgive the indentation problems: this forum’s edit-windows refuse to Do the Right Thing® for talking about software.]