6 July 2026 · Ibtisam Ahmed Khan

Properties belong to structures, not formulas

Diamond and graphite share a formula and agree on almost nothing else. Why polymorphism breaks naive materials data, and how to handle it.


Ask a database for “the band gap of carbon” and you have already made a mistake, not in the code, but in the question. This article explains polymorphism, the single most common way materials data gets misused, through one clean example.

One formula, two materials

Diamond and graphite are both pure carbon. Same formula, same atoms. They differ only in how the atoms are arranged, and that difference changes nearly everything:

Property Graphite Diamond
Band gap ~0 eV (conducts) ~5.5 eV (insulates)
Hardness soft, used in pencils the hardness benchmark
Density ~2.27 g/cm3 ~3.51 g/cm3
Stability the ground state metastable

Structures like these, same composition, different arrangement, are called polymorphs. Carbon is the dramatic example, but polymorphism is the norm, not the exception: TiO2 has rutile, anatase, and brookite; SiO2 has over a dozen forms; a typical formula in the Materials Project has several entries, often with band gaps spanning more than an electronvolt.

The consequence: formula-level questions have no answer

“The band gap of TiO2” is ambiguous by about half an electronvolt depending on which polymorph you mean. “The density of carbon” is ambiguous by 50 percent. Any property quoted without specifying the structure, in a database, by an identifier like mp-149, or at least by phase name, is a value with an invisible error bar the size of the polymorph spread.

This bites hardest in three places:

  1. Casual lookups. Databases return all entries for a formula. If your code takes the first result, you get whichever polymorph the sort order happened to surface, which may be a high-energy structure that has never existed outside a simulation.
  2. Machine learning datasets. Models that predict properties “from composition” are structurally blind: they receive one formula and must output one value, for materials where several true values exist. That places a hard ceiling on accuracy that no model architecture can fix, and it is one reason structure-aware models (graph networks over atomic positions) outperform composition-only ones.
  3. Validation rules. Even quality checks inherit the trap. Consider a sensible-sounding rule: “flag any famous semiconductor whose recorded gap is zero, it is probably a calculation artifact.” Apply it to carbon with the textbook value of 5.5 eV as reference, and it will confidently flag graphite’s genuine zero-gap as an error. The rule assumed a formula has one true gap. It does not. The rule itself was structurally blind.

That last example is worth dwelling on: it means data-quality logic, not just data, can carry the formula-level assumption, and a wrong validation rule is worse than none, because it stamps errors with the authority of a check that “passed.”

How to handle polymorphism properly

Four habits cover most situations:

The general lesson

Chemical formulas are spellings; structures are the words. Most materials data infrastructure, file names, database queries, ML featurisations, quietly treats the spelling as the word, and it works just often enough to be dangerous. The fix costs one extra column: carry the structure identifier everywhere the property goes.


Found a mistake? Good, tell me. This publication flags its own suspect values. Reach me on LinkedIn.