Memory usage and USE statement order

[Olsen__Oystein]

I have case where the order of the USE statements have a huge effect on the compiler's memory usage.  

The attached archive contains two folders, one called memory_usage and another called build_memory_usage. To build the example it should be as simple as:

[bash]$ cd build_memory_usage
$ cmake ../memory_usage
$ make[/bash]

Hence, it is necessary to have cmake installed to build the test examples.

As the code is now, it should build without any problem until it reaches the test_body (its source is located memory_usage/src/tests).  I can not build it with 4GB ram. But there are several ways to make the program compile, but I do not think they should be relevant:

1) Commenting out USE HS2String ensures that the program compiles, and as the comments in that program explain: It is also possible to use the same statement at the beginning of the list of USE statements without any issue.

2) Remove "USE HS2Orbit, ONLY: HSJPLOrbit" in each of the appos funtions within "memory_usage/src/libs/hsspace/hsbody/hsbody.f90" and adding one at the beginning of the module (and leaving test_body.f90 in its original state)

3) Remove all  code relevant to the private object HSNumOrbit in "memory_usage/src/libs/hsspace/hsorbit/hsorbit.f90" and the code compiles with reasonable memory usage again (that is a few percent of the available ram)

This is with intel fortran 2013.0.079 on openSUSE 12.2 x86_64

[Heinz_B_Intel]

I have duplicated the memory usage. On my system ( 24 GB of memory) it compiles fine but I see, that for file test_body.f90 the compiler uses some 3.7GB of memory. This confirms what you report. I will try to get a smaller test case and will discuss this with compiler engineering then. Not relevant here I believe: I get a link error because of linker option "-ldl". I'm working on Redhat 6.0. May you know why this happens. This library ( libdl) exists only as shared library on my system. Do you have a static version on your OpenSUSE system ?

[Olsen__Oystein]

Yes, I have a static version of libdl on my system. It is provided by the rpm glibc-devel-static.
I have just come across an internal compiler error that might be relevant to the one reported above. That problem can be worked around by either moving a USE statement from a subroutine to the beginning of the module or by switching the order of two USE statements at the beginning of the module. (The last work-around results again in significant memory usage) The full error message is:
/home/oyo/tmp/Heliosat2/src/ephemeris/access.f90(43): error #6404: This name does not have a type, and must have an explicit type. [COMPUTEACCESSPOLYGON%HSNUMORBIT] CONTAINS ^ /home/oyo/tmp/Heliosat2/src/ephemeris/access.f90(374): catastrophic error: Internal Compiler Error: possible out of order or missing USE compilation aborted for /home/oyo/tmp/Heliosat2/src/ephemeris/access.f90 (code 1)
Do you want me to upload an example here or open a new thread?

[Heinz_B_Intel]

Please add the sample for the 'Internal Error" here. I will make sure it will be reported to compiler engineering. In case you prefer to submit the sample to me only, do a 'privat' upload or let me know before.

[John4]

I was also experiencing the same problem with the 2013.0 version ---i.e., while compiling, all of my laptop's RAM and swap are consumed at about 50% of the compilation process. I reverted back to the 2011.x.x version in the meantime... but, does the 2013 update 1 solve the issue?

[Heinz_B_Intel]

There is some very good news regarding 13.0 Update 1: I just tested the new compiler on your code and compilation time went down from 3min18sec to 1min16 sec - a nice improvement. The bad part: For file test_body.f90 the compilation still uses 3.7 GB memory on my system. I will continue to work on this with the compiler developers.

[John4]

 Hi,

 Does the 13.0 update 2 version solve the huge memory use during compilation?

[Olsen__Oystein]

Hi,

13.0 update 2 does not solve the huge memory use during compilation. It is still an order of magnitude slower than 12.1 update 6, which I am still using.

[Olsen__Oystein]

The latest release 13.1.1 does not solve this memory problem. I have tested the complete software on a machine with 16 GB of RAM. That was not sufficient.

I have done a rewrite of the software. That version does not have a significant memory problem, but now I get extremely long compile times, i.e. 12+ hours. I do not know why the memory problem has gone away. 

Would it be useful if I uploaded the full version of my old code and the current one?