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

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