[gpaw-users] vdW calculations

[Nichols A. Romero]

We are taking the FFT of the charge density?

n(k) 

And this is not parallelized over k-space grid?

A 3D parallel FFT would be non-trivial to implement and
difficult weak scale.

Nichols A. Romero, Ph.D.
Argonne Leadership Computing Facility
Argonne National Laboratory
Building 240 Room 2-127
9700 South Cass Avenue
Argonne, IL 60490
(630) 252-3441


----- "Jens Jørgen Mortensen" <jensj at fysik.dtu.dk> wrote:

> On Fri, 2010-03-26 at 13:41 +0200, Janne Blomqvist wrote:
> > Jess Wellendorff Pedersen wrote:
> > > Dear Jussi,
> > > 
> > > You are right that the vdW-DF functional uses revPBE setups and
> these 
> > > must therefore be generated manually.
> > > 
> > > A general status of the FFT implementation of the vdW-DF in GPAW:
> > > 1) Forces work, and we expect them to work well.
> > > 2) The spatial integral over all electron densities that
> vdW-interact 
> > > with each other is handled by an FFT, which is why the vdW-DF
> takes more 
> > > memory than usual GGA calculations. This is highly dependent on
> system 
> > > size: The extra memory used grows rapidly as one approaches large
> unit 
> > > cells, say 20x20x20 Å. Also, periodic boundary conditions takes
> less 
> > > memory than non-periodic ones.
> > > 3) Apart from the memory issue, the functional is reasonably
> ready-to-go 
> > > as is, and as a starting point one can use it without giving any 
> > > arguments for the functional. I.e. just do calc=GPAW(..., 
> > > xc='vdW-DF',.....). It works in parallel with up to 20 processors.
> When 
> > > in parallel, each processor handles one of the 20 cubic
> interpolation 
> > > splines, so if only 16 processors are used, 12 processors must
> wait for 
> > > 4 processors to handle the remaining 4 splines.
> > 
> > In my experience, the memory consumption is a big problem in
> practice. 
> > On a big machine with only 1 GB per core (louhi, should be familiar
> to 
> > Jussi!), I have used N*160 cores. As there are 8 cores per node,
> with 
> > 160 cores there is then only 1 vdw job per node, and the vdw job can
> use 
> > all the remaining memory on a node. Sometimes, even that is not
> enough.
> > 
> > On way to slightly reduce memory consumption is to use real->complex
> 
> > FFT's instead of complex-complex. Jens-Jörgen posted a patch to
> trac, 
> > and I have a half-done effort at this lying around in my home dir,
> but 
> > AFAIK nothing has been committed to trunk yet.
> 
> My patch seemed to work, but I didn't have time to polish and test it
> carefully.  If someone could finish that work, that would be very
> welcome!
> 
> JJ
> 
> > I suppose another step would be to domain decompose the arrays, and
> 
> > implement a MPI distributed FFT, but that's a lot of work.
> > 
> > Performance-wise, I'm happy with the current FFT implementation. 
> > Compared to the GGA calculation, the calculation time for the vdw 
> > correction seems to be quite insignificant, at least for decent
> sized 
> > systems (I don't actually have numbers, just my seat-of-the-pants
> feeling).
> > 
> > > 4) A word of caution, however: The vdW-DF implementation is still
> not as 
> > > robust and ready-to-go as GGAs. One recently realized issue
> concerns the 
> > > value of cutoff-radius used for density-density interactions (rcut
> in 
> > > the code). Default is 125 Bohr, but for some reason this large
> cut-off 
> > > sometimes leads to diverging interaction energies when increasing
> the 
> > > unit cell size. Most often so for small systems such as molecules,
> rare 
> > > gas dimers etc. The reason for  this is still unresolved. For
> metallic 
> > > adsorption systems, however, rcut=125 Bohr is well suited.
> > 
> > One thing I have noticed is that the effective potential seems a bit
> 
> > weird. With a GGA calculation, the xy-averaged potential (surface
> calc, 
> > see 
> >
> https://svn.fysik.dtu.dk/projects/gpaw/trunk/doc/exercises/surface/work_function.py)
> 
> > looks like one would expect, but the same system calculated with vdw
> the 
> > potential seems 'spiky'.
> > 
> > > 
> > > Sincerely,
> > > Jess Wellendorff
> > > CAMD ph.d student
> > > 
> > > 
> > > Jussi Enkovaara wrote:
> > >> Jussi Enkovaara wrote:
> > >>> Hi,
> > >>> it seems that vdW functional uses revPBE functional for some
> parts. 
> > >>> As revPBE setups are not
> > >>> distributed in gpaw-setups-0.5.3574.tar.gz, these have to be 
> > >>> generated manually, am I right?
> > >>>
> > >>> Are there some other things one has to consider when peforming 
> > >>> self-consistent vdW calculations?
> > >>
> > >> One question already came to my mind, do forces work correctly
> with vdW?
> > >>
> > >> Best regards,
> > >> Jussi
> > >> _______________________________________________
> > >> gpaw-users mailing list
> > >> gpaw-users at listserv.fysik.dtu.dk
> > >> https://listserv.fysik.dtu.dk/mailman/listinfo/gpaw-users
> > > _______________________________________________
> > > gpaw-users mailing list
> > > gpaw-users at listserv.fysik.dtu.dk
> > > https://listserv.fysik.dtu.dk/mailman/listinfo/gpaw-users
> > 
> > 
> > -- 
> > Janne Blomqvist
> > _______________________________________________
> > gpaw-users mailing list
> > gpaw-users at listserv.fysik.dtu.dk
> > https://listserv.fysik.dtu.dk/mailman/listinfo/gpaw-users
> 
> _______________________________________________
> gpaw-users mailing list
> gpaw-users at listserv.fysik.dtu.dk
> https://listserv.fysik.dtu.dk/mailman/listinfo/gpaw-users