Transfering COMMON with ALLOCATE

[Jack_S_]

Hi all,

I have a large Fortran-90 model which consist of numerous COMMON arrays in the main program (also very few inside subroutines).  Part of the COMMONS in the main program have a characteristic size of (513,43,190).

The model compiles well under the default Intel composer option of -mcmodel=small (with has the default in V13 of -shared-intel ; I'm using the options : ifort -O3 -mcmodel=medium -fpconstant -fp-model source -axCORE-AVX2 -fpe0 -ftrapuv -gen-interfaces -warn interfaces -tracebac ). Being compiled this way I assume the whole static data < 2Gb as stated in numerous conversations here in the forum.

Now, I'm trying to transfer COMMONS to be ALLOCATABLE in a module (as in the example below). I keep doing so for certain amount of arrays, placing the module Common_Arrays in the correct subroutines across the code, and everything is compiled nicely (I get the same double precision results between the two runs ) - until certain amount of arrays are allocated, where I get the "relocation truncated to fit" error. At this point the model consist the rest of the COMMONS and some ALLOCATABLE arrays. It compiles when I put -mcmodel=medium.

My question is : (1) Should this ALLOCATABLE process reduce the memory consumption of the application ? Or should I get it all wrong, where trying to apply this in this way. What is the best practice to ALLOCATE large arrays across large amount of source code files ?

(2) I have been observing a reduce in efficiency when applying -mcmodel=medium, so I would like to bypass this option - How should one can do it ? Should I expect to the same results between two runs (double precision) with -mcmodel=medium ?

Thanks in advance,

Jack.

~~~ 

module Common_Arrays
 IMPLICIT NONE

DOUBLE PRECISION,ALLOCATABLE :: ZINIT(:),PINIT(:),TINIT(:),DPINIT(:),RH_INIT(:)

end module Common_Arrays

---

SUBROUTINE Allocate_Arrays  
 
 use twodimprm,only:NI,NK
 use Common_Arrays
 
 IMPLICIT NONE
 
  ALLOCATE(ZINIT(NK),PINIT(NK),TINIT(NK),DPINIT(NK),RH_INIT(NK),STAT=AllocateStatus)
                       IF (AllocateStatus /= 0) STOP "Not enough memory for (1) "

SUBROUTINE Allocate_Arrays  

[jimdempseyatthecove]

 "relocation truncated to fit" is a Link time failure that indicates for memory model selected the

Code + static data + literall + initializer data

exceeds that of the memory model.

With small this may include the stack or stacks if multi-threaded plus heap.

When medium or large this does not include heap or stack.

The allocatable arrays will require ~80-100 bytes or so for the array descriptor.

If your program has extremely large static data (constants/parameters) and if you are running up against the  "relocation truncated to fit" then consider excising that data into a different program and writing it to a file. Then in your main program, read that file into an allocatable array(s).

I suspect you are also running as a 32-bit program.

If so, consider switching to 64-bit (if possible) as not only can your heap be larger, you also have more registers to use and in which case may speed up your program more than playing around with memory model.

Jim Dempsey

[Jack_S_]

Hi Jim,

Thank you for the detailed answer.

My program has large arrays (values which are changing with time, not constants) which are needed in numerous subroutine, so I do not think its very applicable in my case.

Is there an option to transfer all the program to 64-bit (i.e., Integers and real arrays) by using a certain flag at compilation time ?

Thanks,

Jack.   

[jimdempseyatthecove]

Several ago I had a 32-bit Fortran solution with 13 projects and ~750 source files that I wanted to port to my then new 64-bit platform. The solution (collection of related projects) was built on a Windows platform with Visual Studio 2005 using Intel Visual Fortran 8.something or 9.something. The conversion just required selecting the x64 platform (and having the x64 bit version of Intel Visual Fortran).

The only hiccoughs were in locating the 64-bit version of the 3rd party libraries and a few cases in library function calls where the Fortran code was erroneously written to assume 4-byte integer arguments holding API related handles. Once I knew the problem, the fixes took less than an hour. There were no issues at all amongst the Fortran-to-Fortran calls.

Jim Dempsey