getcell does not get correct values in RF calculations

Phonons, DFPT, electron-phonon, electric-field response, mechanical response…

Moderators: mverstra, joaocarloscabreu

Locked
Robin
Posts: 61
Joined: Thu Jan 14, 2010 3:18 am

getcell does not get correct values in RF calculations

Post by Robin » Wed Oct 20, 2010 6:33 am

Dear developers,

When I try to use getcell and getred in some RF calculations (Strain, IR, and Raman) after a geometry optimization, I find the getcell does not get the correct value (in GS calculation, it works fine). The attached is my test files, and the following are some data from the main output file.

Sincerely,
Guangfu Luo

#-----------------getcell values in the main output file---------------
getcell1 0 #GeoOpt part
getcell2 1 #GS part
getcell3 1 #Strain part
getcell4 1 # DDK part
getcell5 1 #IR part
getcell6 1 #Raman part

#----------------result of "grep volume *out"--------------------------
Unit cell volume ucvol= 3.6526432E+02 bohr^3
Unit cell volume ucvol= 3.8304572E+02 bohr^3
Unit cell volume ucvol= 3.6526432E+02 bohr^3
Unit cell volume ucvol= 3.6526432E+02 bohr^3
Unit cell volume ucvol= 3.6526432E+02 bohr^3 (this part failes because of the too bad cell it gets)
Attachments
getcell-in-RF.zip.in
remove .in
(80.5 KiB) Downloaded 399 times

mverstra
Posts: 655
Joined: Wed Aug 19, 2009 12:01 pm

Re: getcell does not get correct values in RF calculations

Post by mverstra » Thu May 26, 2011 12:55 am

1) do your geometry relaxation separately. You rarely need to or can run the whole thing from a single input file all at once
2) you are correct, this is kind of a limitation (and bug) - driver.F90 does not pass getcell-updated acell in case of:
*respfn
*nonlinear respfn
*susceptibility

but just uses the default values in dtset%

this might be corrected (or at least a test introduced to stop if you combine these with getcell)... I can't tell off hand if it would complicate the respfn calculations...

cheers

Matthieu
Matthieu Verstraete
University of Liege, Belgium

mverstra
Posts: 655
Joined: Wed Aug 19, 2009 12:01 pm

Re: getcell does not get correct values in RF calculations

Post by mverstra » Tue Oct 17, 2017 12:21 pm

Update many years later: the lattice vectors in the output WFK file are always reset to the initial ones, even after relaxation. This is ugly, but needed because the lattice vectors are set by the initial R and G vectors, and are not reallocated on the fly. The number of G and their distribution in the wf array length can change (sometimes a lot if the cell goes all over the place).

One solution is to re-do a scf or non scf calculation at the final coordinates: in this case the cell and xred are correct from the beginning of the scf, and the G vectors will be allocated in the correct size and order.

We have found this to be a problem also with finite electric field calculations. One would like to progressively increase the field and reuse both the wfk and cell from the previous datasets, instead of restarting each time from a cubic cell. If you do this, however, there is a mismatch in the G vectors, and though the wf coefficients are correct the G vectors are not adapted in the output of the datasets, so the next dataset has to "know" that it is reading a G distribution corresponding to a cubic cell: it reads this from the WFK file.
Matthieu Verstraete
University of Liege, Belgium

User avatar
jzwanzig
Posts: 504
Joined: Mon Aug 17, 2009 9:25 am

Re: getcell does not get correct values in RF calculations

Post by jzwanzig » Thu Jun 20, 2019 3:11 pm

Even re-doing a GS calc after relaxation and then a response function calc, fails. That is:

ndtset 4

1) Relax ions
2) Relax ions and cell using ions from 1
3) Compute accurate GS WFK and DEN, using cell and ions from 2
4) Compute DDK using WFK, cell, and ions from 3

== FAIL

The output file reports correctly in DATASET 4 that the cell and xred are to be read from DATASET 3, but the cell at least is then echoed as the cell from original input file.

Looking at the code, it would appear that "respfn" does not include a section similar to the gstateimg code section on looping over previous images, and I think that currently the multi-dataset mode is treated in "driver" as a form of multiple images. My suspicion is that when the use of images in the GS code was expanded (and parallelized?) the getcell/getxred/getxcart feature broke for response functions.

any comments or suggestions?
Josef W. Zwanziger
Professor, Department of Chemistry
Canada Research Chair in NMR Studies of Materials
Dalhousie University
Halifax, NS B3H 4J3 Canada
jzwanzig@gmail.com

Locked