[CP2K:167] Re: about output handling in cp2k

[Teodoro Laino]

Unfortunately there are no memory leaks.. ;-) (99.99999 % sure)..

The fact is that once you write the first restart file (immediately  
after the 0 step) the input file in memory is larger because
it contains more information (i.e. the "memory image" to continue the  
calculation exactly  from that point).. This information
is always kept in memory unless you don't ask to deallocate it...

That's why you go out of memory at that point..

to deallocate the structure of the input file in memory use the keyword:
http://cp2k.berlios.de/input/ 
InputReference~__ROOT__~GLOBAL.html#SAVE_MEM

This is a typical problem of XT3/4 (where the amount of memory  
required is ~1.5 than on normal linux, maybe due to the catamount  
kernel).
Moreover,  in the dual-core version the max amount of memory per node  
is ~850MB per proc (even less if you use more than 100MB for the IO  
buffer(that is the default on our configuration))..
I'm just a little bit surprised because 850 MB should be more than  
enough for each proc for this input file..
how much memory can you really access per proc on your machine?

Teo

On 12 Jul 2007, at 01:03, Axel Kohlmeyer wrote:

> On Thu, 12 Jul 2007, Teodoro Laino wrote:
>
> TL> >
> TL> > i have to use 7.0.2/7.0.4
> TL> > since older pgi crap out on parsing .psf files with QM/MM.
> TL> >
> TL> I checked right now 7.0.4 and it works as well with the same arch
> TL> file as the previous e-mail..
>
> ok, i see a common theme here: i've been compiling on a node
> that is not consistent with the runtime, and there is another
> change. now after compilation on the 'right' login node i get:
>
>                                          - safer DIIS on
>   preconditioner : FULL_KINETIC        : cholesky inversion of T + eS
>   stepsize       :    0.15000000
>   energy_gap     :    0.20000000
>   eps_taylor     :   0.10000E-15
>   max_taylor     :             4
>
>   ----------------------------------- OT
> --------------------------------------
>      1  OT DIIS        0.15E+00    1.12        0.0000168008
> -1115.2412301104
>  Out of memory ...
>
>
>  **********************
>  *** ERROR in fft3d ***
>  **********************
>
>  *** The memory allocation for the data object <sbuf> failed. The ***
>  *** requested memory size is 34 Kbytes                           ***
>
>
>  ===== Routine Calling Stack =====
>
>            12 fft3d_ps
>            11 fft_wrap_pw1pw2_160
>            10 fft_wrap_pw1pw2_all
>             9 density_rs2pw
>             8 calculate_rho_elec
>             7 scf_iter
>             6 scf_env_do_scf
>             5 qs_energies
>             4 qs_forces
>             3 velocity_verlet
>             2 qs_mol_dyn2
>             1 CP2K
>
>  CP2K| Stopped by process number
> 54
>  CP2K| Abnormal program termination
>
> aborting job:
> application called MPI_Abort(MPI_COMM_WORLD, 0) - process 54
>
>
> so that could be a memory leak. i'll have to test some more.
>
> ....
>
> a.
>
> ps.: now going to have some homebrewed booze
> and watch a soccer match...
>
>
>
> TL>
> TL> > PSC (or cray) has a weird policy of distributing software.
> TL> > i just found that they have gfortran (4.1.2, but dies with ICE
> TL> > on atoms_input.f90) and pathscale (not yet tried that one),
> TL> > but only one some special login nodes (not the one i usually
> TL> > get dropped in). bastards!
> TL>
> TL> Unfortunately gfortran cannot still compile/run cp2k (not even on
> TL> linux boxes)..
> TL>
> TL> teo
> TL>
>
> -- 
> ====================================================================== 
> =
> Axel Kohlmeyer   akoh... at cmm.chem.upenn.edu   http:// 
> www.cmm.upenn.edu
>    Center for Molecular Modeling   --   University of Pennsylvania
> Department of Chemistry, 231 S.34th Street, Philadelphia, PA  
> 19104-6323
> tel: 1-215-898-1582,  fax: 1-215-573-6233,  office-tel: 1-215-898-5425
> ====================================================================== 
> =
> If you make something idiot-proof, the universe creates a better  
> idiot.
>