[CP2K:189] Re: Memory leaks?

[Teodoro Laino]

I patched the files.. The problem is that there's this bug in the PGI  
compiler:

subroutine pippo()
   real, allocatable, dimension(:) :: myvar


   ...
   call pluto()

  contains
    subroutine pluto()
    ...

   allocate(myvar(mydim))

   end subroutine pluto
end subroutine pippo

the variable myvar should be automatically deallocated when exiting  
pippo..
PGI deallocate it if it's allocated in the same body of the  
subroutine where it is declared (pippo)..
but if it's allocated  in a contained subroutine (like pluto), PGI  
does NOT deallocate the
array when exiting from pippo..

If someone of you (Axel??) has contacts with PGI guys just send them  
this bug report..
introducing the proper deallocation (that are useless according the  
standard but needed to get around the PGI bug) everything works..
I checked the memory in a geometry optimization and now it's stable  
in a range of +/2MB from the first cycle..

Teo

On 14 Jul 2007, at 21:50, Axel wrote:

>
>
>
> On Jul 13, 7:33 pm, Teodoro Laino <teodor... at gmail.com> wrote:
>
> hi teo,
>
>> Ciao Axel,
>>
>>  From the stack trace you sent I can identify the following modules:
>
> this is not a stack trace, only parts of a valgrind output.
>
>> -) cp_units   (not updated since 6 months)
>> -) input_cp2k_restarts  (relevant possible update 11days ago)
>> -) cp_output_handling (not updated since 2 months)
>> -) input_val_types (not updated since 6 months)
>
> it need not be any of those modules directly, but a
> utility routine used by them.
>
>> The only possible problems could than be with input_cp2k_restarts..
>> But what about the error messages localized in the other modules??
>>
>> Looks more like a general problem of the pgi_trim than something
>> localized in recent changes..
>
>
>> (though you said that the version of the 18-06 was ok!) (did you try
>> to recompile now with same
>> compiler/library  that version (18-06-07)?)
>>
>> The strange thing is that I can't reproduce the error you had with
>> the oldest file H2O-32.inp with
>> pgi-7.0.4 :((
>
> please check with how many nodes you are running? that input does
> only 10 steps and that could fit into the nodes, if you use enough
> of them.
>
> i have now made a test with an arch file that is a copy of yours
> and compiled a serial(!) version of it (so i removed the parallel
> defines and changed the compiler from ftn to pgf90, using pgi 7.0.4
> (after a make distclean!). the resulting binary should not include
> any cray code and runs also on my desktop.
>
> now if i run tests/QS/H2-md.inp and monitor the memory usage with
> top, one can see, that the memory consumption goes up in stages of
> about 15M for each completed scf calculation.
>
> i sometimes wonder whether there is something like
> %ifdef annoy_axel
>    call do_someting_annoying
> %endif
> somewhere hidden in the code... ;-)
>
> ciao,
>   axel.
>
>
>> teo
>>
>> On 13 Jul 2007, at 23:57, Axel wrote:
>>
>>> from looking at the changelog there were some input related
>>> changes recently, but only the people having implemented
>>> them can tell, whether there is an alternate way to do
>>> the same and not trigger this (compiler) bug... :-(
>
>
> >