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

[Juerg Hutter]

> 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.
>
>