Drop a PDF and the parser maps its reported quantities onto the map, every value backed by a verbatim, page-located quote you accept or reject. Runs through a cost-contained relay on openmaterials infrastructure; no account or API key needed. The relay has a small daily budget shared by all visitors, so a run may ask you to come back tomorrow.
A parsed paper reports quantities; the map knows how each is produced. Load a proposal (or paste one) and its method dataflow draws below, with the same lineage lit on the map.
or paste a proposal JSON:
Type a method or quantity in plain language. The semantic resolver grounds it to typed map nodes, live. Fuzzy language in, checkable identity out.
Pick a source and a target quantity; the canvas draws the derivation path the map knows between them.
A sub-map is a list of edges plus the map version they came from. Paste that JSON to render it, or build one on the canvas and Share it: the link carries the edges in its fragment, no server. Node symbols and formulas are pulled live from the map by id.
the map, as code:
The hash answers same or different; the distance layer answers how far. Named, versioned metrics over atomic configurations, one default, no silent fallbacks: everything below is read live from the published registry, computed by the same build that writes the map data.
Pick two committed sources: every quantity and material
they share compares with curve@1 (symmetric relative L2 on
the shared temperature range, computed in this page by the same rule as
omdc), and their materials compare with comp@1 (Element
Mover's Distance on the Pettifor scale) where a material name is a
parseable formula (a-Si parses to Si; SWCNT honestly refuses). Single
shared points list side by side without a distance; nothing is
inferred.
Type any two formulas: comp@1 (the
Element Mover's Distance on the Pettifor scale, the registry's
chemistry channel) answers instantly, in this page. Zero means the
same chemistry in any structure: diamond and graphite are both C.
vs
Try: salt vs sylvite · diamond vs graphite · Si vs Ge · GaAs vs GaP · quartz vs its Ge twin · iron vs gold · Si vs rubbing alcohol
A lineage is a data container: the X-to-Y path from inputs to a result, and the whole record travels in the link, no server.
A lineage record is a data container: light, and identified by its
lineage, the X-to-Y path from inputs to a result (a map node when known, else a template with its
hyperparameters and setup values) plus optional pointers to heavy
artifacts hosted on
MaterialsCodeGraph. Paste a
record, or drop a .json file (an MCG-served record pastes
straight in), to open a plain data view of it, then Copy link: the
whole record rides in the #x= fragment, no server, and
replays here as the same view. Nothing is stored or uploaded, it is a
client-side view. The data view shows what the container holds as plain
information: what the record is, every field of the lineage, what the
output node means on the map, and where the data lives, plus a plain link
to run this lineage as a simulation on MaterialsCodeGraph. One link can
also carry a whole set of lineages from one paper (a bundle envelope with
the publication metadata stated once): it opens as a plain paper view
listing each lineage, one click from its full datasheet. Dashboards and compute live on
MaterialsCodeGraph, not here.
the lineage, as a record: