heap array

[BABAK]

Hi

In my program when the size of the arrays which are passed between subroutines increases
I get the error:''Stack overflow'. When I omit the subroutine containing these heavy-sized arrays and write
them as part of the main program everthing is fine when the HEAP ARRAY is blank, but when I change the
HEAP ARRAY size to '0' the result of the calculations would be "NaN". As I have read through other related posts
one way in order to avoid 'Stack overflow' when calling subroutines with heavy-sized arrays is to change it to
'0'.This is my first problem.

One other way which you have suggested for solving this issue is to use allocatable arrays but can I use this form of arrays in subroutine arguments like:

subroutine good(a,b)
real(kind=8),dimension(:,:),allocatable,intent(in) :: a
real(kind=8),dimension(:,:),allocatable,intent(out) :: b
.......

or I can just use allocatable arrays for arrays within a subroutine?

Thanks

[TimP]

Of course you can use allocatable locally in a subroutine. Every textbook from f95 on will explain about automatic deallocation when you leave the subroutine, and save attribute to over-ride it.

If you use OpenMP, you can look up on line how OpenMP standard explains in some detail how allocatable may be used. As Intel compilers claim OpenMP 3.0 implementation, you are entitled to file bug reports about any discrepancies.

[BABAK]

Hi

What about the "Heap Array" problem? I didn't get any answer for that.

And Also where can I get OpenMp ?

Thanks

[TimP]

I didn't understand whether you were commenting about heap-arrays option; if so, what were you getting at. /heap-arrays (without a number) is (I think) the most usual version. That puts all such allocations on heap. /heap-arrays:25 would put all allocations on heap except those which are known at compile time to require always < 25 bytes.
Intel, Microsoft, and gnu compilers (at least on linux) (and many others) provide support for OpenMP parallelism. The /Qparallel option of Intel compilers currently also works with (uses same libraries as) OpenMP. No point in mentioning it further if your question doesn't involve threading, but you can find descriptions in the Intel compiler documents, on line, and in a few textbooks.

[BABAK]

Hi

I think here we have a misunderstanding. In a very small program when I debug the program with the "Heap Array" being without a number or with number '0' there is no problem. But when in my large program which consists of subroutines with large-size ARGUMENT arrays when the "Heap Array" is blank I get an error about stack overflow. As I have read throug other threads one way is to change the "Heap array " number to '0' to solve this problem. But when I do so my output would only be 'NaN'. I don't know how to solve this problem.

BUT when I run my large program without SUBROUTINES I do not get any error with stack overflow when the "Heap Array" is blank. But when I change the "heap array" to '0' or '25' I again get "NaN" .

How can I solve this problem?

Thanks

[IanH]

It sounds like there may be another underlying problem with your code.

If you haven't already, try running a debug configuration that has the following (all together):
- Running with the heap arrays option set to zero (/heap-arrays)
- Having all compile time and run time warnings turned on (set the property Fortran > Diagnostics > Compile Time Diagnostics to "Show all" and set the property Fortran > Run-time > Runtime Error Checking to "Check all", command line equivalents are /warn:all and /check:all respectively).
- Setting the property Fortran > Floating Point > Floating Point Exception Handling to Underflow gives 0.0; Abort on other IEEE exceptions, or /fpe:0 on the command line - this can help pick the location (approximately sometimes) in the source where the NaN is generated. It may also be worthwhile setting the Floating Point Model to Source and the Reliable Floating Point Exceptions model to Enable (or alternatively set the Floating Point Model to Strict) to help make the floating point instructions that the processor executes more consistent with the expressions in your source code.
- Turn the traceback on (Fortran > Run-time > Generate Traceback Information).

Does your program call any procedures recursively? If so - do those procedures have the recursive attribute, and how deep is that recursion likely to go?

[SergeyKostrov]

Let's take a look ata main difference between "Allocation on the Stack" and "Allocation on the Heap".

1. When a compiler creates anapplication it allocatesin Physical Memory( RAM )andreservesin Virtual Memory (VM ) someamount of memoryfor theStack and Heap. Remember, 2 values for every type!By defaultthese4 numberscould be just 1 MB, and it is a very small amount to handle processing in a "heavy" application that uses lots of data and lots ofcalls to some functions.

For example, in an abstract applicationthese valuescould look like:

Stack Reserve size ( in VM )= 16 MB
Stack Commit size ( inRAM)= 16 MB
HeapReserve size ( in VM )= 16 MB
HeapCommit size ( inRAM )= 16 MB

In total,there arejust 64 MB forthe application's codes anddata! What to do? These values must be increased.

>>...In my program when the size of the arrays which are passed between subroutines >>increases I get the error: 'Stack Overflow'...

2. It happened because all allocated and reserved memory was used! Check default value(s) for the Stack and increase it as much as you can. If, for example, it was64 MB try to make it256 MB.

>>...When I omit the subroutine containing these heavy-sized arrays and write them as
>>part of the main program everthing is fine when the HEAP ARRAY is blank...

3. It happened because memory for these arrayswas allocated from the Heap. On Win32 platformsan application could allocate up to 2 GB of memory from the Heap.

>>...but when I change the HEAP ARRAY size to '0' the result of the calculations
>>would be "NaN"...

4. Sorry, I don't understand why you did it. But, a value 'NaN'is possibly a result of corruption of your arrays allocated on the Heap.

>>...one way in order to avoid 'Stack overflow' when calling subroutines with
>>heavy-sized arraysis to change it to '0'. This is my first problem...

5. But you need some memory for the Heap anyway. In item'2.' I've alreadyexplained that the'Stack Overflow' error happens when an application used all available memory for the Stack.

[BABAK]

Hi

I did what you mentioned, but now when the "heap array" is '0' I get the error :" floating point overflow" .
There is no problem with my code, because when I run it with 'heap array' being blank(using stack memory) I don't have any problem but when I change the "heap array" to '0'(using heap memory) I get "NaN" results or the "floating point overflow" error.

Thanks

[IanH]

Well - you do have a problem - a floating point overflow!!

The error message should pinpoint the location in the source code that has overflowed (more or less), work out what's going wrong (why did it overflow), then work backwards from there.

Variation in a program's behaviour can sometimes be explained by using undefined (or unitialised) variables.

[Les_Neilson]

You should start by turning on all the diagnostic aids, both compile and runtime - especially uninitialised variables, and array bounds checking. You may also want to turn on "check routine interfaces".
There is also (under Project->Properties->Fortran->Data) there is an option to "Initialise stack variables to an unusual value"
Do you have "implicit none" in all your code?

It sounds very much as though you have a data corruption problem.

Les

[BABAK]

I again emphasize that when the "heap array" is blank there is no error, but when I change it to '0' I get
"floating verflow" error.

and I think the following is where it overflows.

" call stack location :
practice.exe! _mkl_blas_p4m3_dgemm_pst() + 01121 bytes "


I am using LAPACK and BLAS in my code. I also have initialized all of the arrays and variables.

[SergeyKostrov]

Hi Bob,

Did you try toinvestigate the problem in aDebug configuration of your application? Or, did you try tounderstand what is going onas soon as theapplication crashes with the Debugger?

Best regards,
Sergey