MP API elasticity collection between API, legacy webui, and next-gen is inconsistent; also, deprecation status seems inconsistent

there seems to be some inconsistencies between elastic data from mp. apologies if this is the intended behavior

Mismatch between deprecation of materials under summary and elasticity collection

via the API there are MPIDs which return bizarre unphysical or “null” VRH moduli for failed calculations which, under summary docs, are not deprecated, but under elasticity docs are deprecated.

minimal script showing this:

import os

from mp_api.client import MPRester

MPIDS = ['mp-11261', 'mp-13132', 'mp-1974', 'mp-2396', 'mp-2406', 'mp-559976',
         'mp-569265', 'mp-631345', 'mp-631467', 'mp-672229', 'mp-672356',
         'mp-776320', 'mp-961671', 'mp-972237', 'mp-978497']

with MPRester(os.environ["MP_API_KEY"]) as mpr:
    docs = mpr.materials.elasticity.search(material_ids=MPIDS)
    depr = {str(s.material_id): s.deprecated for s in
            mpr.materials.summary.search(material_ids=MPIDS,
                                         fields=["material_id", "deprecated"])}

print("mpid formula K_vrh G_vrh state elas_depr summ_depr")
for d in docs:
    kg = [getattr(m, "vrh", None) for m in (d.bulk_modulus, d.shear_modulus)]
    if any(v is None or not 1 < v < 10000 for v in kg):
        print(d.material_id, d.formula_pretty, *kg, d.state, d.deprecated,
              depr[str(d.material_id)])

Output

Retrieving ElasticityDoc documents: 100%|██████████████████████████████████████████████████████████████████| 15/15 [00:00<00:00, 172368.66it/s]
Retrieving SummaryDoc documents: 100%|█████████████████████████████████████████████████████████████████████| 15/15 [00:00<00:00, 393216.00it/s]
mpid formula K_vrh G_vrh state elas_depr summ_depr
mp-1974 CeB4 -391264.248 60061.749 failed True False
mp-2396 HoCo2 -321.678 29.35 failed True False
mp-11261 YAu 83.993 -8.518 failed True False
mp-13132 LaN 128.447 -41.288 failed True False
mp-631345 KZr2Nb 66.328 -9.647 failed True False
mp-631467 BeInSi2 63.285 -225.567 failed True False
mp-672229 Mn3ZnC None None failed True False
mp-672356 MnSbPt 93.999 -10.592 failed True False
mp-961671 TiGePt 123.324 -3.699 failed True False
mp-972237 Tc3H 238.733 -20.12 failed True False
mp-978497 Si3H 99.012 -30.69 failed True False

In 2nd-last column, all of them are deprecated in elasticity collection. In last column, they are … not deprecated in summary collection?

Also, mp-672229 seems to have null moduli, despite being in elasticity collection.

API mismatching website

more, some of this data mismatches what is on the website(s) in a very inconsistent way.

Example 1: YAu

For example, mp-11261 YAu has failed state via API with shear modulus -8.5, yet on legacy website it shows 33GPa.

On next-gen it shows nothing.

Example 2: mp-13132, LaN

mp-13132 has the same problem: deprecated, failed, negative shear modulus (-41GPa) via mp api, but websites show different

legacy shows a different (??!) negative shear modulus

next-gen shows nothing?

Hi Alex,
see footer with a few topics + external links that have related details*

Some quick answers:

  1. Deprecation meaning in summary and property collections: The deprecated field for both the summary and materials collections reflects whether or not the material is deprecated, deprecated in the property collections (like elasticity) reflect whether that property is deprecated.
    • property documents are typically not even built for deprecated materials, so none of the property collections outside of elasticity even have deprecated entries. elasticity is “special” only because we could not outright remove data (without having a replacement dataset ready) that had been valid up until the sanity checks that were implemented in database versions v2025.02.12.post & v2025.02.12.post1
  2. Differences between the legacy website & next-gen: All data shown on the legacy website was essentially frozen at the time of the next-gen switch. Some static data products might have been migrated, but in general the data on the legacy website and the next-gen website (+ mp-api responses) should be considered disparate data sets, so the legacy elasticity data has no relation to the data shown on the current website. The workflows that produced the data are even different (very different if I remember correctly).
  3. next-gen showing nothing for those two materials: The website does not show deprecated entries in any of the interfaces/apps but they are available via mp-api.

*links
25 elasticity entries with unphysical tensor components …
Nine unflagged materials with impossible elastic moduli … emmet #1499
Unreasonable elastic moduli
Related topics 2024 - Sept 12th
v2025.02.12.post changelog
v2025.02.12.post1 changelog

Thanks for the explanation @tsmathis I believe that explains it.

In general though, there was no real warnings or attention grabbing indication that the elasticity collection has some of these problems. That was somewhat the surprising thing to me.

Would it be reasonable to add some sort of temporary warning (perhaps to mp api) until someone fixes the collection in earnest?

… add some sort of temporary warning (perhaps to mp api) until someone fixes the collection in earnest?

Of course, that’s completely reasonable. We’ll likely put up a dedicated docs page that the website and mp-api can refer to. Will put that on the todos.