While using the elasticity dataset for an inverse-design project, we found 25 entries whose stiffness tensors contain components far above any physical value. We retrieved the full elasticity set via mp-api and screened for any tensor component with |C_ij| > 2000 GPa (diamond’s largest is ~1080).
The worst cases:
| material_id | formula | max abs. tensor component (GPa) | K_VRH (GPa) |
| mp-1761 | LuIr2 | 7.16e12 | 365.6 |
| mp-1383 | UCo2 | 1.16e8 | 6.63e7 |
| mp-2358 | SmAl2 | 9.07e7 | 2.01e7 |
| mp-757233 | Gd2Zr2O7 | 4.77e7 | 2.65e6 |
| mp-570436 | CaIr2 | 1.30e7 | 7.21e5 |
Full list of 25: mp-1761, mp-1383, mp-2358, mp-757233, mp-570436, mp-10846, mp-1014993, mp-637771, mp-1030, mp-5050, mp-13434, mp-23253, mp-1513, mp-1234, mp-7851, mp-21019, mp-10692, mp-12609, mp-22290, mp-23471, mp-22418, mp-4194, mp-3830, mp-21199, mp-1808.
Two observations that may be useful for curation:
1. **Aggregate-moduli sanity checks don’t catch all of these.** The v2025.02.12.post1 release notes deprecated documents with bulk or shear moduli outside −100 to 800 GPa. But mp-1761 reports K_VRH = 365.6 GPa — inside that range — while its tensor contains 7.16e12 GPa components. Component-level corruption can hide behind plausible aggregate values.
2. **The deprecation flag is set on all 25, but bulk pulls still return them.** Re-checking against the live API on the morning of posting: every one of the 25 is still returned by material-ID lookup with values unchanged, and all 25 elasticity documents carry `deprecated = True` (the parent materials do not). Property-range searches appear to exclude deprecated documents — a K_VRH window around mp-1761’s 365.6 GPa does not return it — but an unfiltered `mpr.materials.elasticity.search()` pull, which is how a training set typically gets built, returns deprecated documents interleaved with current ones (399 of the first 3,000 retrieved in our check), and the search method exposes no parameter to exclude them. Is filtering on the per-document `deprecated` field the intended contract for bulk consumers?
These 25 all pass a positive-definiteness check, so an SPD filter alone does not catch them; a bound on component magnitude (or on eigenvalues) does. Separately, our earlier audit found 2,018 entries in the elasticity set that fail positive-definiteness outright; the full ID list and scripts are archived under CC-BY at Reproducibility companion: Certified-complete inverse design of elastic stiffness tensors | Zenodo.
Is there a preferred channel for reporting entries like these? Happy to share the screening script.