For rutile WO2, in trying to reproduce these values I found that the energy changes between two ‘tasks’ by 1 eV Login vs. Login with different magnetic orderings. The higher energy value is labeled as the ‘uncorrected energy’.
What, then, determines the energy that is placed with the mp-id, and therefore throughout the analyses from the API?
Thank you,
Michael
Hi @michaelcraig, welcome!
For the specific rutile WO2 case, I can’t comment without taking time to investigate further, but I can talk in a general case.
We group calculations together based on structural similarity (determined by the StructureMatcher algorithm in pymatgen. This is agnostic to magnetic ordering, so if we’re attempting multiple magnetic orderings for that material, we will have multiple calculations, each with a different energy. We will then select the lowest energy calculation, and report that on our website. This is codified in our open-source emmet code, which we use to build our database.
Sometimes, we will deprecate old materials because we suspect they are inaccurate in some way, so that they are not used to report the energy, but these deprecated calculations are still made publicly available for historical reference.
Finally, a correction scheme is applied to remove some of the systematic biases in the DFT method. These are applied element-wise, and are why both a “corrected” and “uncorrected” energy are reported.
On tungsten specifically, I have a suspicion the +U value we use at the Materials Project is too large. The impact of this is quite small for Materials Project, due to the correction scheme we use, but if you are doing a detailed investigation of this material I would advise thinking about the best U to use.
Hope this helps!
Matt
Thanks for the welcome and of course for this really comprehensive answer, Matt, definitely cleared things up.
Is there any version history or labeling scheme or something that might explain why a given calculation would be deprecated, despite being lower in energy?
Noted about the U value, thank you.
The database is versioned, retrievable both on the website and the API. For the legacy website see this page and the next-gen website see the footer on any page to find the current database version serving the website.
We’re still working on a single page for database release notes (see here), but we also keep a database release log here.
Currently, we do not publicly show why a specific deprecated task is deprecated, but that’s on our roadmap. The logic for deprecations is all publicly available in our emmet database builder code however, for anyone sufficiently motivated 
See here for that.
Improved docs for all of this is also on the roadmap.
Best,
Matt
Just restarting this thread.
Is there any magnetic moment validation going on? I can’t see that within emmet, and spotted a similar thing as in my original comment for rutile FeO2 Also, how are the initial moments are set? It is strange to see them set to 0 for Fe(4+), and I can’t identify why the value with the higher energy is listed over the ferromagentically-ordered, lower energy calculation. I think taking the lower energy FM value makes rutile Fe roughly the same formation energy as the lowest FeO2 morphology.
To me, checking the derived magnetization is at least as important as the input sets to determine whether to deprecate a calculation, ie. identify deviations from expected magnetic moments for given elements given expected oxidation states, by maybe checking whether they match other magnetic moments for the same stoichiometry and coordination. Eg. you can identify mp-1097003, the octahedrally-coordinated FeO2 which is furthest from the hull, also has 0 moments for Fe(4+). In cases where you don’t have these examples maybe you set some range for the moments you expect.
For example, for mp-22194 an ICSD material, the E above hull here is 0.483 eV, potentially explained by the fact that the listed calculation has Nb, Fe with moments 0, 0.3 respectively, ie. Nb(5+), Fe(~2+), which is strange since if Nb is 5+ Fe should be 3+, which your paper indicates has a moment of ~4. I would expect something like Nb(4.5+), Fe(3.5+), and the other GGA+U static calc, which isn’t taken as the energy, is 0.43 eV/atom lower in energy and while I cannot see the OUTCAR in this case, the INCAR moments were high, indicating the ordering should explain the difference.
Nice work on the high-throughput magnetic ordering, impressive stuff, and a fun paper to read. I can see then that you have been working on this, but just wanted to share my musings!
Best,
Michael
Hi @michaelcraig,
Apologies for the slower response here, I’ll answer in brief now but happy to give an extended answer later.
Is there any magnetic moment validation going on?
No, I don’t believe so. We did do some validation where we had incorrect magnetic moments due to a parsing error with a set of older calculations whereby the moments would be placed on the wrong atoms(!), but this was not an extensive issue.
Also, how are the initial moments are set?
They are set typically according to the defaults defined in pymatgen – these are typically initialized high-spin, assuming they will relax down, with the exception of Co, which is generally initialized low-spin.
However, this for the relaxation and the static calculation will typically inherit the final magnetic moments from the relaxation – so if magnetic moments are quenched for some reason, and perhaps incorrectly go to zero (or almost zero), that will get picked up by the static calculation too. When the magnetic moments are defined with initial values that look “noisy” (for want of a better word), this is usually because they’ve been inherited from a previous calculation.
For the specific examples mentioned, I would need to investigate further – I definitely agree this is worthy of investigation, thank you for bringing it to our attention. If you spot any other clues, please do let us know. As you can imagine, with a large database it is difficult to detect all issues automatically!
Best,
Matt