Page 1 of 1

getcell does not get correct values in RF calculations

Posted: Wed Oct 20, 2010 6:33 am
by Robin
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)

Re: getcell does not get correct values in RF calculations

Posted: Thu May 26, 2011 12:55 am
by mverstra
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

Re: getcell does not get correct values in RF calculations

Posted: Tue Oct 17, 2017 12:21 pm
by mverstra
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.

Re: getcell does not get correct values in RF calculations

Posted: Thu Jun 20, 2019 3:11 pm
by jzwanzig
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?