0

I am trying to run an OpenMP Fortran code using Intel Fortran.

At the beginning of my code I allocate 7 very large matrices:

! Allocate 
REAL, ALLOCATABLE :: m1(:,:,:,:,:,:,:,:,:)
REAL, ALLOCATABLE :: m2(:,:,:,:,:,:,:,:,:)
REAL, ALLOCATABLE :: m3(:,:,:,:,:,:,:,:,:)
REAL, ALLOCATABLE :: m4(:,:,:,:,:,:,:,:,:)
REAL, ALLOCATABLE :: m5(:,:,:,:,:,:,:,:,:)
REAL, ALLOCATABLE :: m6(:,:,:,:,:,:,:,:,:)
REAL, ALLOCATABLE :: m7(:,:,:,:,:,:,:,:,:)

ALLOCATE(m1(2,161,20,2,2,21,30,2,2))   
ALLOCATE(m2(2,161,20,2,2,21,30,2,2))   
ALLOCATE(m3(2,161,20,2,2,21,30,2,2))   
ALLOCATE(m4(2,161,20,2,2,21,30,2,2))   
ALLOCATE(m5(2,161,20,2,2,21,30,2,2))   
ALLOCATE(m6(1,161,20,2,2,21,30,2,2))          
ALLOCATE(m7(1,161,20,2,2,21,30,2,2))   

I then run a code with a big parallelized loop.

!$omp parallel do default(private) shared(m1, m2, m3, m4, m5, m7,  someothervariables)

Some of the matrices m1 to m7 are indeed used in subroutines, which might lead to creation of temporary arrays. In any case the code runs fine if done serially. But it crashes with the following error if run with openMP regardless of the number of cores I am using:

enter image description here

The machine I am using has 128GB of ram. Not sure if this is the limiting factor or not. If I decrease the last index of each matrix to 1, the code runs fine in 24 cores. Given that I am increasing the size of the memory used by 2, it should run in 12 cores, at least no?

Maybe I am doing some big error, or perhaps is just some Fortran option that needs to be changed ...

phdstudent
  • 1,060
  • 20
  • 41
  • 1
    A common recommendation when running openmp codes on linux is to increase the size of your stack (often making it unlimited with `ulimit -s unlimited`) as all variables in the openmp section will go onto the stack. It looks like you're running in windows so [this answer](https://stackoverflow.com/a/20744680) may be helpful. – d_1999 Jul 28 '17 at 07:27
  • 1
    Have a look at the [`OMP_STACKSIZE`](http://www.openmp.org/wp-content/uploads/openmp-4.5.pdf#page.298) environment variable. – Gilles Jul 28 '17 at 08:47
  • 1
    If you like to make your code less susceptible for this without needing to always change the stack size we need to see a [mcve]. Allocatable arrays should *not* cause stack overflow. I normally recommend to use allocatable arrays *to avoid* stack overflow, see https://stackoverflow.com/a/37403568/721644 – Vladimir F Героям слава Jul 28 '17 at 08:59
  • 1
    Debug the code and find out access to which variable causes the stack overflow. You can change the stack size of the main thread with the linker argument `/STACK:large_value_in_bytes` (the stack size is embedded in the executable header, not controlled by the resource limits set by the parent process as on Unix). You should be able to set the value in the project properties in Visual Studio. – Hristo Iliev Jul 28 '17 at 09:13
  • Thanks for all the answers! Somehow increasing the Stack commit size to 99999999 solved the problem. Not sure why though. – phdstudent Jul 28 '17 at 19:29

0 Answers0