Incorrect energy value in vasprun.xml

[ehermes]

Hello,

I am writing a script to parse vasprun.xml using Python, and I have noticed a discrepancy in the values that are reported for the energy between those printed in the SCF loops and those printed at the end of each ionic step. As far as I can tell, the energy values that are printed in the SCF loops (calculation/scstep/energy) are consistent with the values that are printed to the OUTCAR. However, the values that are printed at end of each ionic step (calculation/energy) appear to be mislabeled.

Specifically, the three values that are printed are "e_fr_energy", "e_wo_entrop", and "e_0_energy". While the free energy (e_fr_energy) has the same value as that printed in the energy section of the final SCF iteration, "e_wo_entropy" instead contains a value that matches "e_0_energy" from the last SCF cycle, and "e_0_energy" contains a value that matches "eentropy" from the last SCF cycle.

This makes parsing the vasprun.xml somewhat troublesome. I wish to extract the E0 energy, I could currently use the "e_wo_entropy" from "calculation/energy" since that contains the value that I want, however should this bug ever be fixed my code will start returning the wrong value. If I instead read "e_0_energy" from the final "calculation/scstep/energy" entry, then I will not get the classical (i.e. VDW) corrections in my energy. Therefore, I must first calculate the difference between E0 and F from the final "calculation/scstep/energy" (e_0_energy - e_fr_energy), and then apply that correction to F printed in "calculation/energy".

I believe the fix is to be made in main.F. Specifically XML_ENERGY is called (around lines 3132 and 3280, not sure of the exact positioning as I have modified main.F in other places) with the arguments "TOTEN,TOTEN-EENTROPY/(2+NORDER),EENTROPY" where it should instead be called with "TOTEN,TOTEN-EENTROPY,TOTEN-EENTROPY/(2+NORDER)".

Thank you,
Eric Hermes

[deyan_mihaylov1]

Yes. I am seeing the same thing (as of 5.4.4).

[martin.schlipf]

Thank you for reporting this to us. This will be fixed in Vasp.6.