[Carpet] memory leak while running with carpet

[Yosef Zlochower]

Erik Schnetter wrote:
> The Fortran 90 standard allows the compiler to not automatically 
> deallocated allocatable arrays in Fortran routines.  The Fortran 95 
> compilers changed this.  Some code may assume Fortran 95 semantics 
> while your Pathscale compiler may insist on being a true Fortran 90 
> compiler.  I don't know the Pathscale compiler, but the PGI compiler 
> is such a thing.
>
> -erik
>

Hi,

  The only significant Fortran code that I use is the Fortran code in 
Carpet itself.
Do the Fortran routines in Carpet make this assumption?

Yosef
> On Jul 16, 2007, at 09:09:11, Yosef Zlochower wrote:
>
>> Hi,
>>
>>   I believe I tracked the problem down to the  compiler.  I don't see 
>> any
>> evidence of the memory leak while using the Intel version 10.0 
>> compilers,
>> but do see the problem when using the pathscale version 3.0 compiler.
>> I found that the the pathscale compiler produced the memory leak both
>> with aggressive optimizations
>>  -O3 -OPT:Ofast -fno-math-errno -ffast-math
>> and with the less aggressive
>>  -O2
>>
>> Has anyone else seen problems with memory leaks when using the psc 
>> compiler
>> on a similar system (AMD X86_64 procs with HTX Infiniband interconnect)?
>>
>> Yosef
>>
>> Erik Schnetter wrote:
>>> Hi Yosef,
>>>
>>> we found that the HDF5 library allocates some memory for internal
>>> purposes, and continues to hold on to it, probably buffering
>>> something.  This is much worse for 1.6.x than for 1.8.x.  You could
>>> give 1.8.x a try.
>>>
>>> Christian Ott found a misbehaviour of the GNU libc which is triggered
>>> by CarpetIOASCII (and probably also CarpetIOScalar and
>>> CarpetIOBasic.)  Can you try running without them (or without
>>> outputting anything with them) to see whether this helps?
>>>
>>> Apart from this a memory leak is difficult to track down.  It could be
>>> anywhere -- Cactus, Carpet, your code, or it could be some interaction
>>> between them.  There are no "relevant sections" of a parameter file;
>>> there can only be such section if you know already where the memory
>>> leak occurs.
>>>
>>> Can you try to remove thorns from your thorn list, trying to make the
>>> memory leak go away?  After that it is necessary to watch the
>>> simulation, probably in a debugger, and catch it increasing its memory
>>> usage.  If you can point me to a routine we can go on from there.
>>>
>>> I'm afraid that your section of a parameter file doesn't ring any
>>> bell.  Your parameter settings look pretty normal, and I don't see
>>> such a drastic problem.
>>>
>>> -erik
>>>
>>> On Jul 10, 2007, at 03:54:45, Yosef Zlochower wrote:
>>>
>>>> Hi,
>>>>
>>>>   I forgot to mention that the memory leak is quite significant. The
>>>> memory load tends
>>>>  to double after a few hours of runtime.
>>>>
>>>> Yosef
>>>>
>>>> Yosef Zlochower wrote:
>>>>> Hi
>>>>>
>>>>>  I am trying to locate the source of a memory leak in my code. I am
>>>>> using
>>>>> stable (version 3) version of carpet and I noticed that the memory
>>>>> usage
>>>>> continuously increases with time. If  I  checkpoint and restart, then
>>>>> the memory usage goes back to its original size, but then increases
>>>>> with time.
>>>>>
>>>>> I attached the relevant sections of the par file. Any suggestion on
>>>>> how I can
>>>>> track down the source of this leak. I am running the code on a 
>>>>> cluster
>>>>> consisting
>>>>> of dual core AMD X86_64 procs with HTX Infiniband interconnect and 
>>>>> the
>>>>> pathscale compiler.
>>>>>
>>>>> Thanks
>>>>>
>>>>> Yosef
>>>>> ------------------------------------------------------------------------ 
>>>>>
>>>>>
>>
>> _______________________________________________
>> developers mailing list
>> developers at lists.carpetcode.org
>> http://lists.carpetcode.org/listinfo/developers
>>
>
>
> --Erik Schnetter <schnetter at cct.lsu.edu>
>
> My email is as private as my paper mail.  I therefore support encrypting
> and signing email messages.  Get my PGP key from www.keyserver.net.
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> developers mailing list
> developers at lists.carpetcode.org
> http://lists.carpetcode.org/listinfo/developers
>