I’m working with the phase diagrams that involve Mg and trying to do calculations that are compatible with the MP database.
I have been successful with reproducing MP compatible calculations for many other species and systems, however, I have trouble reproducing specifically the pure Mg endpoint. The MP database energy for mp-1056702 ends up at around -1.6 eV/atom (-1.6003 eV/atom), however, over many different attempts I always get around -1.49 eV/atom.
I am using pytmatgen to generate the input files (using the MPRelaxSet), I’ve taken care to use the correct pseudopotentials (matching the pymatgen hashes), and I use the MaterialsprojectCompability (but it does not adjust anything for pure Mg).
It may also be noteworthy that this endpoint was apparently found to be the lowest energy one in a recalculation 2020-09-02, whereas it seems previously a structure closer to the experimental ground state, mp-153 was the endpoint. However, also for that structure, I find the same discrepancy; MP reports -1.5909 eV/atom (so ~ -1.6 eV/atom just as the newer endpoint), and my own attempts at calculating this system also end up ~ -1.5 eV/atom. Another observation is that in an earlier archive of the mp database ( Materials Project Data ) the energy of mp-1056702 (the current endpoint of Mg ) has an energy of -1.4819 eV/atom ( which is close to what I calculated).
Is there a possibility that the input parameters for vasp calculations were changed in the custodian workflow? ( i am not using custodian for my workflow, so i might have missed this correction) ( What happens to the updated INCAR files mp/database wise when custodian corrects for an error? )
None of these calculations (mp-1056702 or mp-153) seems to be present in Nomad. Could you please consider sharing the raw output files from either of these to help me try to understand this discrepancy?
Thanks in advance!
Hi @Abhijith_S , thanks for posting. I am not sure exactly what may be happening, but if I understand correctly, you are comparing the output of a DFT calculation you ran with what we show in the database, and you are getting a somewhat different energy, right?
Here are a couple of things to consider:
- Most of our energy calculations in MP are now derived from static calculations rather than structure optimizations, i.e. we use
MPStaticSet rather than
MPRelaxSet for final energies. The settings are similar but there are some slight differences, so you might want to examine those
- The corrections possibly applied by custodian can be seen in this file (look at the
correct method). In principle, most changes made here should not affect the final energy, but there are sometimes unpredictable interactions between parameters.
- As you point out, atomic endpoints do not receive any energy corrections, so you should not need to use
- Note that with the recent database release, we switched to the 2020 compatibility scheme by default. Again, this will not affect pure elements, but could affect the energies you see for other compounds. (see release notes)
I hope this helps. Please let us know if you aren’t able to make progress figuring this out.
Thanks a lot for your reply. I realized that I might have failed to mention it, but my protocol did consist of doing relaxations using MPRelaxSet and then doing static calculation using MPStaticSet. There are some preliminary 'pre’relaxations involved to get the cell shape manageable, but that shouldn’t affect the end result. The bottom line is that with every other endpoint, my ‘Materials Project compatible’ calculations ( ie, by doing structural relaxations and static calculations as prescribed by Materials project, so that the calculations are compatible with MP) are well within a margin of error, expect Mg ( and Ge ).
To add a bit of background to the story, at first applying the same schema to Li (mp-1018134) also gave me an energy discrepancy ( calculated energy: -1.7163 eV/atom, Materials Project energy: -1.9089 eV/atom ). I increased the EDIFF parameter for a tighter difference ( than what MPRelax and MPStatic set prescribed) and got converged energy of -1.907 eV/atom, which is acceptable. But for Mg ( and Ge to some extend), these values did not change. It was this peculiar nature of Mg that led to asking this question, and seeing similar energy values in older calculations with the same structure (Materials Project Data) raised some suspicions.
Perhaps I could get to the bottom of this issue if I could get my hands on the final calculation files ( for which referral links are pointed to NOMAD, but it doesn’t exist.) Could you perhaps point to, if they are available; where I might acquire those files?
Thanks a lot !!
Interesting; thanks for the additional context. Flagging @tschaume re: NOMAD data.
The older dataset you linked is from 2018. If memory serves, between then and now I think we had some internal discussion about some unexpected interactions between EDIFF / EDIFFG and other parameters in our input sets. @mkhorton or @munrojm might know better.
There is also this commit which changed ICHARG and LASPH. I am not an expert here but I believe we found LASPH True vs. False to cause surprisingly large discrepancies in final energy under some circumstances.
Thanks for the detailed report @Abhijith_S, the information offered is very helpful, do you have a set of VASP inputs/outputs available too?
I don’t have any immediate suggestions beyond what’s already been said but I’ll try to take a look this coming week. When there’s a specific issue with a given element like this, and everything else seems to have been done correctly, it’s definitely something I’d like to get to the bottom of … 0.1 eV is not insignificant, and could even be why we have the incorrect on-hull polymorph.
@rkingsbury I don’t think the aspherical corrections (LASPH) would be significant in this case due to the lack of d-orbitals. The ICHARG change could be a factor depending on when @Abhijith_S ran the static calculations, whether the charge density from the relaxation was used, and what version of pymatgen was used. My first guess is always pseudopotentials but seems like that’s been ruled out.
Regarding the raw calculation data hosted by NOMAD, we had an update today from Michael Wu and @tschaume that the majority of our remaining data should be fully uploaded by the end of the year. That said, for a specific example, we can look it up manually if it becomes necessary.