[CP2K:2669] Re: Memory leak on Mare Nostrum

[Teodoro Laino]

Let me just say that rather than a compiler bug this is, like Marco 
said, a more tunable behavior of the xlf compiler.
In fact, by default XLF does not deallocate arrays that are declared 
locally without either SAVE or STATIC attributes when the subprogram 
terminates (which is the correct thing for F77 and F90, while it is not 
for F95 and F2003).

To change this behavior within XLF it is enough to tune properly some 
options (compilation flags as Marco mentioned).
For this specific case:

-qxlf90=autodealloc

will make that work for you. Default for that keyword is noautodealloc 
for xlf90_r and xlf_r. For xlf95_r and xlf2003_r the default is the 
correct one: autodealloc (unless changed in your local installation).

Another thing to mention is that although not required by F95 standard 
and beyond it should be a good programming style to deallocate 
allocatables at the end of each subprogram (other compilers, like PGI, 
suffer frequently from version to version of this very same problem).

Best Regards,
Teo

Juerg Hutter wrote:
>> Ciao Teo,
>>
>> I confirm what Rachel says: Ialso have tried it on another platform
>> and it works fine. As you suggest it should be some problem with the
>> compiler; maybe it's stricter than other compiler and it expects ALL
>> allocated arrays to be deallocated. I will check if there is some
>> compilation flag in the compiler to make it less strict.
>
> Hi
>
> with the xlf compiler you can use libhmd for memory leak detection.
> The free g95 compiler or the valgrind program also have this capability.
> However, as pointed out before, your case is most likely a compiler bug.
> This has nothing to do with being strict (this implies that the other
> copilers are not strict, they are).
>
> Juerg
>
>>
>> thanks a lot
>>
>> marco
>>
>>
>> On Apr 14, 2:00 pm, rachel <rachel... at theochem.rub.de> wrote:
>>> Hi Teo, Marco
>>>
>>> not sure if my post got thro, so once again, i tested Marco's input
>>> with my latest version of cp2k and there was no memory leak as far as
>>> i could see. Probably an older bug;-)
>>>
>>> cheers
>>>
>>> Rachel
>>>
>>> On 14 Apr., 11:51, Teodoro Laino <teodor... at gmail.com> wrote:
>>>
>>>> Ciao Marco,
>>>
>>>> This is probably a bug in the compiler: when you allocate ALLOCATABLE
>>>> you can avoid to release them since the compiler should automatically
>>>> deallocate them when leaving the subroutine. In any case, I remember
>>>> quite well that few of these problems were fixed in the last 2 years
>>>> (i.e. each allocatable after being allocated was followed by a
>>>> deallocate at the end of the subroutine). Probably, other allocation
>>>> (not followed by deallocation) have been introduced since then.
>>>> We can try to find/fix them but in order to do so I need to know
>>>> precisely if you checked this behavior with an up-to-date cp2k 
>>>> version.
>>>
>>>> Cheers,
>>>> Teo
>>>
>>>> marco masia wrote:
>>>>> Dear Developers,
>>>
>>>>> I am experiencing a problem when running cp2k on Mare Nostrum @
>>>>> Barcelona Supercomputing Center. After a certain number of steps
>>>>> (always different in the tests I run), the job is killed by the 
>>>>> master
>>>>> node because a great amount of memory is required. It seems that
>>>>> little by little the memory requirement increments during the
>>>>> execution. I asked support from Mare Nostrum staff and they told me
>>>>> that it is probably due to a bug in the code. Are you aware of this
>>>>> problem? In case it was due to some miscompilation I attach the file
>>>>> for the Mare Nostrum architecture:
>>>
>>>>> ****
>>>
>>>>> # The following settings worked for MareNostrum at BSC
>>>>> # (by courtesy of S. Caravati, 08.11.2007)
>>>>> CC       = mpicc
>>>>> CPP      = cpp -traditional
>>>>> MPIHOME  =
>>>>> FC       = mpif90 -qsuffix=f=f90
>>>>> LD       = mpif90
>>>>> AR       = ar -r
>>>>> DFLAGS   = -D__AIX -D__ESSL -D__FFTSG -D__FFTESSL\
>>>>>            -D__parallel -D__BLACS -D__SCALAPACK #-D__LIBINT
>>>>> CPPFLAGS = -C $(DFLAGS) -P
>>>>> FCFLAGS  = -O3 -qnosave -qstrict -q64 -qarch=ppc970 -qcache=auto -
>>>>> qmaxmem=-1 -qtune=ppc970 -qxlf90=autodealloc #-
>>>>> qextname=wrapper_build_deriv1
>>>>> _eri:wrapper_build_eri:wrapper_free_libderiv:wrapper_free_libint:wrapper_init_deriv:wrapper_init_lib 
>>>>>
>>>>> FCFLAGS2 = -O0 -qnosave -q64 -qarch=ppc970 -qcache=auto 
>>>>> -qtune=ppc970 -
>>>>> qxlf90=autodealloc #-
>>>>> qextname=wrapper_build_deriv1_eri:wrapper_build_er
>>>>> i:wrapper_free_libderiv:wrapper_free_libint:wrapper_init_deriv:wrapper_init_lib 
>>>>>
>>>>> LDFLAGS  = $(FCFLAGS) -L/gpfs/apps/SCALAPACK/1.8/mpich2/64// -L/usr/
>>>>> lib64\
>>>>>            -L/gpfs/apps/BLAS/blas-1.0.0/64/lib
>>>>> LIBS     = -lscalapack /gpfs/apps/SCALAPACK/1.8/mpich2/64/
>>>>> blacsF77init_MPI-LINUX-0.a\
>>>>>            /gpfs/apps/SCALAPACK/1.8/mpich2/64/blacs_MPI-LINUX-0.a \
>>>>>            -L/gpfs/apps/LAPACK/3.2.1/64/lib -Wl,-rpath,/gpfs/apps/
>>>>> LAPACK/3.2.1/64/lib -Wl,-rpath,/gpfs/apps/SCALAPACK/1.8/mpich2/64/ -
>>>>> llapack
>>>>> -Wl,-Bstatic -lblas -Wl,-Bdynamic -lessl #/gpfs/apps/LIBINT/1.1.4/64/
>>>>> lib/libderiv.a /gpfs/apps/LIBINT/1.1.4/64/lib/libint.a -lstdc++
>>>
>>>>> OBJECTS_ARCHITECTURE = machine_aix.o
>>>
>>>>> ### To speed up compilation time ###
>>>>> mc_moves.o: mc_moves.F
>>>>>         $(FC) -c $(FCFLAGS2) $<
>>>>> f77_interface.o: f77_interface.F
>>>>>         $(FC) -c $(FCFLAGS2) $<
>>>>> pint_types.o: pint_types.F
>>>>>         $(FC) -c $(FCFLAGS2) $<
>>>>> f77_int_low.o: f77_int_low.F
>>>>>         $(FC) -c $(FCFLAGS2) $<
>>>
>>>>> ****
>>>
>>>>> thanks
>>>
>>>>> marco
>>
>> -- 
>> You received this message because you are subscribed to the Google 
>> Groups "cp2k" group.
>> To post to this group, send email to cp... at googlegroups.com.
>> To unsubscribe from this group, send email to 
>> cp2k+uns... at googlegroups.com.
>> For more options, visit this group at 
>> http://groups.google.com/group/cp2k?hl=en.
>>
>>
>