[gpaw-users] vdW calculations

[Janne Blomqvist]

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.

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