large array allocation failure 41

[BLaub1]

my code allocates a large array.  I've used Lahey fortran for years and no problem, but with intel, it won't allocate the array.  This is the allocation 

    REAL(8) , Allocatable, Dimension(:,:,:,:) ::	gas      ! Gas properties array		
    ALLOCATE( gas (ncham,nsteps,nspecies,nparam),stat=st)

ncham is 5, nsteps is 250,000, nspecies is 10, and nparam is 19.  my estimate is this is somewhere in the 20GB range.  My machine has 128 GB of RAM avail, but I'm getting the following error message:

 status after allocation of variable gas is           41
forrtl: severe (157): Program Exception - access violation
Image              PC        Routine            Line        Source
libifcoremd.dll    0FFF9F99  Unknown               Unknown  Unknown
libifcoremd.dll    10023738  Unknown               Unknown  Unknown
libifcoremd.dll    1005A4AF  Unknown               Unknown  Unknown
libifcoremd.dll    10058E40  Unknown               Unknown  Unknown
AIPPintel1.exe     0138C772  Unknown               Unknown  Unknown
AIPPintel1.exe     013A11CC  Unknown               Unknown  Unknown
AIPPintel1.exe     013DB70F  Unknown               Unknown  Unknown
AIPPintel1.exe     013DBC91  Unknown               Unknown  Unknown
KERNEL32.DLL       74CF8494  Unknown               Unknown  Unknown
ntdll.dll          770941C8  Unknown               Unknown  Unknown
ntdll.dll          77094198  Unknown               Unknown  Unknown

my virtual memory is set at 198 GB for all drives.  What could the problem be?  

thanks

Brian

[Steve_Lionel]

The "size" option to heap-arrays is useless - don't bother setting it to anything but zero.

[andrew_4619]

6.7430E-11_rk

[BLaub1]

thanks for all the comments.  I'll try to absorb the information.  FYI, I'm using the demo version with a 30 day trial, so perhaps transporting .exe's from one computer to the other is a no-no.  My guess is that the laptop does not contain the libraries that Jim suggested, but what is strange is that when Lahey compiled things,  they ran anywhere.  in fact, the same code, ran on any machine.  a little confusing.

more suggestions are welcome.  Also, I'm lost on lines 5 and 6 in post 20.  how is that a "kind"?  why not just
 

real(8), allocatable, dimension(:,:,:,:) :: gas

what witchcraft is the dp parameter?  sorry, old school here.  learned fortran in 1983...  allocatable arrays was a huge step for me.  looks like there's a lot to learn.

Regards,

Brian

[andrew_4619]

The size of reals can vary by compiler and machine architecture. your 8 is a "kind" if you use a global parameter you can change the kind by one simple edit in one place. You can also set the kind in code based on the level  of precision demanded by the application.

[John_Campbell]

Steve Lionel (Ret.) (Blackbelt) wrote:

The "size" option to heap-arrays is useless - don't bother setting it to anything but zero.

Steve,

Thanks for your reply. The combination of /Qopenmp and  /heap-arrays[:size] without :size is a problem to me, assuming this combination is a possibility. For cache efficiency, it is useful to direct small private arrays to the stack, while for stack management, it is best to direct large arrays to the heap. Ignoring :size, implies for automatic arrays this decision is done at compile time, rather than run time when the size is known. ( perhaps /heap-arrays is limited to only the master thread ? )

The /heap-arrays option provides a robustness for when a range of array sizes are possible, but reduce the effectiveness of managing L1 cache via Fortran. Additionally with /Qopenmp, matching each thread stack to the L1 cache then becomes more elusive.

For /Qopenmp, applying /heap-arrays[:size] to PRIVATE arrays also has/would have many benefits, with the proviso of applying a memory page break between heap arrays of different threads.

I have been trying to draw attention to this issue on a number of forums, but have not yet attracted much support.

I do note that OpenMP Ver 5.0 has introduced Memory Allocators, but like Fortran that ignores the "byte", OpenMP has ignored "stack" and "heap" and instead used some rather vague terms like "omp_large_cap_mem_space" or "omp_low_lat_mem_space". Could the first be heap and the second be cache ? 

At present there is not a lot of documentation of the management of automatic arrays and array copies, being either temporary or PRIVATE.

[Steve_Lionel]

One would like the size option to heap-arrays to be useful, but it doesn't do what it says in the documentation. Or, rather, the situations where the size is utilized are so rare as to not be useful. It certainly won't help you here.

[jimdempseyatthecove]

>>For cache efficiency, it is useful to direct small private arrays to the stack, while for stack management, it is best to direct large arrays to the heap.

subroutine foo(incomimgArray)
  real :: incomingArray(:)
  integer, pragma :: localArraySize=10000  ! whatever size you want on stack or in SAVE
  real, target :: localArray(localArraySize) ! may be SAVE too depending on if you enter as serial or parallel
  real, pointer :: workingArray(:)
  ...
  if(size(incomingArray)<=localArraySize) then
    workingArray => localArray(1:size(incomingArray))
  else
    allocate(workingArray(size(incomingArray)))
  endif
  ... 
    if(size(incomingArray)>localArraySize) deallocate(workingArray)
end subroutine foo

Jim Dempsey

[BLaub1]

So, this is 4000 lines of code, transient,  with many interdependencies at each time step which prohibits me from running parallel (at least from what I can tell).   Even so, the code runs in less than 5 seconds typically, so I don’t see a need to pursue trying to make it run parallel.

I’ll check on including the redistributables on the laptop and see if the error message goes away.

the error message is 

APPLICATION ERROR 
The application was unable to start correctly (0xc000007b).  Click OK to close the application

I'll google it but at first sight, it's not very helpful and pops up immediately.

[Steve_Lionel]

That error usually means that some way the application was built makes it unable to run. The most common cases for this are static code and data exceeding 2GB (or close to that), or a stack reserve linker setting too high.

[BLaub1]

I reduced the stack size down to 250000 and it still wouldn't run on a laptop with 32 GB Ram.  I was running a model that only utilized 500 MB of RAM on the desktop and even that wouldn't run on the laptop. 

When I run the code using a stack size of 25Million on my desktop and increasing the size of the model by a factor of about 10, it shows memory usage of only 5 GB for a 15 second run.   Not sure if that's helpful information but it seems that even a small stack size isn't the problem.

[jimdempseyatthecove]

Build your program with all the warnings (fix any that show up)
Then build your program with all runtime checks enabled.

If your program fails due to runtime check, you should receive an informative message.

Often a program with uninitialized variables, and/or calling procedures with incorrect arguments can exhibit problems such as yours.

Please note too, that 32-bit only programs often declared external procedures to Windows API using INTEGERs for both call and return args that were intended to be HANDLE and/or DWORDPTR. These are improper calling conventions for x64 programs. DWORDPTR is often OK as on x64 the ....POINTER (and or LP...) are correctly defined. However, in some cases, the argument is indended to point to a pointer/handle and these are usually address size. e.g. sizeof(void*)

Jim Dempsey

[Steve_Lionel]

The problem here is that the program doesn't even start executing. 

The next diagnostic step I would suggest is to open the EXE with DependencyWalker, save a .dwi file, ZIP it and attach to a reply here. It will complain about some things that aren't real, but may provide a clue. Make sure you download the 32 or 64 bit version that matches your executable.

I would also ask that you include in the ZIP the .map file created when you enable the link map in the Linker project properties.

I will comment that the amount of RAM the system has is not relevant.

[BLaub1]

things are working better, but since I'm on a demo version, my codes cannot be transferred due to other users missing a .dll file.  do you know if it's OK to re-install Lahey in addition to the Intel Fortran Demo into Visual Studio or will that cause issues?

[Steve_Lionel]

You can't have two different Fortran language integrations in Visual Studio. If the Lahey install doesn't include VS integration (older ones did, I recall), or you can deselect it, that should be ok. Do watch out for Lahey changing the association for Fortran source files in the registry, which can cause weird problems in Visual Studio.