How to audit a materials database entry: a six-check list
A practical checklist for deciding whether a value from the Materials Project deserves your trust, with the reasoning behind each check.
Computed materials databases are extraordinary resources with a dangerous interface: every value looks equally authoritative, whether it is rock-solid or a known artifact. This article is a practical checklist, six checks, each taking under a minute, for auditing any entry before you build on it. The running example is Fe2O3, because it demonstrates the most famous failure.
Check 1: Is the band gap physically believable?
Standard DFT (the simulation method behind most database values) systematically underestimates band gaps, typically by 30 to 50 percent, and for a whole family of materials, strongly correlated oxides, it fails completely. The canonical example: look up Fe2O3, hematite, and the stable entry reports a band gap of 0.00 eV. That is the signature of a metal. Hematite is an experimentally well-characterised semiconductor with a gap near 2.2 eV.
The check: compare the computed gap against an experimental value from literature for anything that matters. Treat computed gaps as lower bounds, treat a zero gap for a known semiconductor as an artifact, and know the risky families: oxides of Fe, Ni, Co, Mn, Cu are the classic DFT failure cases.
Check 2: Which polymorph are you actually looking at?
A single formula usually has many database entries, polymorphs, with genuinely different properties. Query TiO2 and you may get two dozen entries with gaps spanning more than 1.5 eV.
The check: confirm you are using the entry you think you are. Note the material ID (like mp-149), and unless you have a specific reason otherwise, use the stable one: energy_above_hull equal to zero.
Check 3: Could this structure actually exist?
Databases contain vast numbers of computed structures that have never existed physically. The energy_above_hull field tells you how far an entry sits above the most stable option for its composition: near zero is plausible, beyond roughly 0.1 eV/atom is very unlikely to ever be synthesised.
The check: before citing an entry’s properties as a material’s properties, check its hull distance and its theoretical flag (true means no experimental structure match). A structure that exists only in simulation has properties that exist only in simulation.
Check 4: Has anyone ever made it?
Two kinds of evidence, and they must be read together. Text-mined synthesis recipes (extracted automatically from literature) show someone has published a route. Experimental structure matches (the theoretical: false flag, ICSD references) show the structure has been observed.
The subtlety: absence of recipes is not absence of synthesis. Text-mining is incomplete, GaAs, one of the most manufactured semiconductors on earth, shows zero recipes in the mined dataset while carrying dozens of experimental references. The reverse error matters too: a “predicted-only” material has neither kind of evidence.
The check: call an entry experimentally verified if either evidence type exists; call it predicted-only when both are absent; never conclude “never made” from missing recipes alone.
Check 5: What is missing, and what does missing mean?
Most properties are computed for only a fraction of entries. No elastic tensor, no dielectric constant, no phonon data, this is normal, not suspicious.
The check: confirm the absence of a value is treated as “not computed,” never as zero, anywhere in your pipeline. Silent zero-filling of missing scientific data is one of the most common and damaging processing bugs.
Check 6: Do the numbers pass basic physics?
The cheapest check catches real errors: values that cannot exist. Densities outside 0.3 to 25 g/cm3 for solids, negative moduli, gaps above ~16 eV. These sound too obvious to bother with, but public databases do carry such values, a ZnO polymorph entry, for instance, has been recorded with a shear modulus of minus 47 GPa, which is physically impossible.
The check: range-check every value you use against loose physical bounds. One line of code, and it catches the errors that would embarrass you most.
Automating it
Everything above can be done manually against a database’s web interface in a few minutes per material, and for one-off lookups, that is exactly right. For repeated use, the checks are mechanical enough to script, I have built an open-source agent that runs all six automatically against live Materials Project data and writes a trust verdict per property, but the tool matters less than the habit. The habit is the point: computed databases are instruments, and like any instrument, they have known error modes. Read the manual, then trust accordingly.
Found a mistake? Good, tell me. This publication flags its own suspect values. Reach me on LinkedIn.