Data Support

Orbitron’s io/pipelines crate provides a unified loader (load_scene, load_trajectory, load_frequency_data) that automatically selects the correct parser.

Support tiers

A tier states what a reader has been tested against. It is not a promise. Every format is fuzzed, and every file in the test corpus is checked against the physical invariants the test suite asserts (normal modes in the frame of their geometry, thermochemistry that adds up, normalised orbitals, occupations that sum to the electron count, and others).

  • Supported: real output from at least two versions of the program that wrote it, or a large external set of structures, plus a golden fingerprint of the parsed result or a check against the program’s own reading of the same file.
  • Tested: real output, but from one program version or a narrow sample. Other versions probably work; a file that does not is a bug worth reporting.
  • Experimental: a handful of files, or generated test files only.
Tier Formats Tested against
Supported XYZ 411 test files; the 108,541 complexes of tmQM
Supported CIF, PDB/mmCIF, SDF/MOL, GROMACS GRO 15 to 27 test files each, with golden fingerprints
Supported Gaussian .log/.fchk Gaussian 03 C.02, 09 D.01, 16 A.03 and C.02
Supported NWChem 7.0.2, 7.2.2, 7.2.3
Supported Molpro 2025.2, 2026.1
Supported OpenMolcas v25.02, v26.02
Supported DIRAC DIRAC25, DIRAC26
Supported ORCA 4.2.1, 5.0.4 and 6.1.1: the same inputs run under each read alike run by run (tasks, energies, orbitals, populations, excited states, frequencies, scans, IRC and NEB paths), with a golden fingerprint
Supported VASP 4.4, 4.6, 6.4.3
Supported Quantum ESPRESSO 7.2, 7.5 and 7.6: the whole corpus run under each, read alike run by run
Supported CP2K 2024.2, 2025.1 and 2026.2: the same inputs run under each, read alike run by run
Supported GROMACS XTC 2024.5 and 2026.3: every frame read as gmx trjconv reads it, positions, box, time and step
Supported XSF pp.x from QE 7.2 and 7.6: each data grid checked point for point against the cube pp.x writes of the same data, and the two versions’ grids read alike
Supported TREXIO CP2K 2026.1 and 2026.2, all-electron and GTH: each orbital drawn point for point as CP2K’s MOLDEN file of the same run draws it, and as the other version’s file does; files in PySCF’s convention against PySCF’s own orbital values
Supported NBO NBO 7.0.9 and 7.0.10, and NBO 3.1 inside Gaussian 16, with a golden fingerprint of each summary’s own tables
Supported MOLDEN written by OpenMolcas v25.02 and v26.02, CP2K 2026.1 and 2026.2, Molpro, NWChem, ORCA 4.2.1, 5.0.4 and 6.1.1 and PySCF; each ORCA version’s orbitals checked against its own orca_plot’s, CP2K’s against its TREXIO file of the same run, and every file’s frontier orbitals integrate to one electron
Supported Gaussian cube written by Gaussian 16 A.03 and C.02, QE 7.2 and 7.6, NWChem, ORCA and DIRAC; cubegen, orca_plot and dplot cubes match the orbitals drawn from the same runs, and pp.x cubes the XSF of the same data
Supported QMCPACK 4.3.0 and 4.4.0: the same decks run under each read alike (series, estimators, verdicts, density-matrix traces and density grids), with a golden fingerprint; force estimators from 4.4.0 only
Supported MRC2014/CCP4 238 EMDB maps released 2002 to 2026, from RELION, cryoSPARC, EMAN, IMOD, SPIDER and a dozen other packages, each read point for point as mrcfile reads it and placed as gemmi places it; maps written by mrcfile and gemmi in signed 8-bit, signed and unsigned 16-bit, float32 and float16 storage, both byte orders and all six axis orders (packed 4-bit, mode 101, is untested); seven EMDB maps against EMDB’s own record of each

Formats

The table summarises what each reader takes from a file:

Format Extensions Highlights
XYZ .xyz Multi-frame trajectories, streamed via canonical helpers, attaches final-frame structure plus optional positions attachment
GROMACS GRO / XTC .gro, .xtc GRO reads fixed-width structures and concatenated short trajectories and writes one structure. XTC reads positions, time/step, precision, and orthorhombic or triclinic boxes lazily; it requires an explicit topology-bearing structure and is read-only. Coordinates are converted from nm to Å once. TPR, TRR, TOP, and ITP are not supported. Use gmx editconf -f topol.tpr -o topol.gro for a coordinate-only TPR conversion; it does not preserve force-field topology.
Gaussian LOG/FCHK/CUBE .log (or a log named .out, recognised by content), .fchk, .fch, .cube, .cub, .gjf, .com, .inp (a Gaussian input is recognised by its # route line, since .inp is also CP2K’s extension) Optimization trajectories, vibrational modes, orbital/NBO metadata, stage summaries + boundary loaders, canonical bundles capture MO and vibrational attachments. An IRC opens as a reaction path on its transition state, with that structure’s own charges and dipole. This includes an IRC-only job read from a checkpoint (geom=allcheck), placed from the structure the log echoes, and a terse # IRC that prints the profile but no per-point geometries. With #p output, each SCF cycle’s energy is read from its E= line, so orbitron plot scf draws a Gaussian run’s SCFs; default output prints only SCF Done, and its SCFs stay counts. A frequency job’s .fchk carries its harmonic analysis: frequencies, IR intensities and displacements from Vib-E2 and Vib-Modes, the same as the log prints and in the checkpoint’s own orientation, so plot spectrum and analyze vibrations work from the checkpoint alone. A freq=raman job’s Raman activities are read from the log and, when the checkpoint holds the polarizability derivatives they are made from, from the .fchk; plot spectrum --raman draws them. A Freq=Anharm job’s anharmonic fundamentals and their IR intensities are read from the log’s Fundamental Bands tables (Gaussian 09 and 16) and kept on the harmonic modes they belong to, matched by harmonic frequency because those tables number the modes differently; analyze vibrations reports them and plot spectrum --anharmonic draws them. A relaxed scan (Opt=ModRedundant with one S coordinate) keeps every optimisation step as a frame; each point’s converged step is tagged with its value on the scanned bond, angle or dihedral, measured from its geometry, and orbitron plot opt draws those points against it. A point that did not converge is not drawn, and a scan that stopped partway is drawn as far as it got
NWChem OUT/NW + companions .out, .nw, .movecs, .hess, .civecs, .cube, .bxyz/.fxyz Multi-task support (OPT/FREQ/SP), a task ... saddle labelled as the saddle-point search it is (its banner is an optimisation’s; the driver’s modsad line tells them apart), byte-ranged loaders, canonical extras summarise tasks and attach MO coefficients/trajectory shards. Sources tab also loads .movecs (Fortran-binary MO coefficients) for full nbf × nmo coverage and .hess (Cartesian Hessian) for follow-up frequency synthesis when the .out doesn’t already carry the freq block. NWChem .out extracts the basis-set definition into a GaussianBasisSet, so .out + .movecs together render molecular orbitals as 3D isosurfaces in the Surfaces tab. Sources also loads a TDDFT .civecs (excited-state amplitudes) and generates natural transition orbitals from it. A mepgs minimum-energy path is read from the .bxyz/.fxyz files the input asked for and opens as a reaction path.
ORCA OUT/HESS .out, .hess Geometry and geometry-optimisation trajectories with per-cycle energies; vibrational modes with IR intensities and animated displacements; thermochemistry (ZPE, enthalpy, Gibbs, entropy components). Detected by ORCA’s own banner, so it coexists with the other programs that use .out. All 3N modes are kept, including the six near-zero translations and rotations, because ORCA’s IR table indexes into that numbering. Orbital energies and occupations, spin-resolved for unrestricted references, and Mulliken charges with spin populations are taken from the last SCF. Full orbital coefficients load from ORCA’s converted .molden.input companion, described below. IRC reaction paths are read from the IRC PATH SUMMARY table and the _IRC_Full_trj.xyz companion. A relaxed surface scan of one bond, angle or dihedral (%geom Scan) tags each frame with its point on the scanned coordinate, and orbitron plot opt draws the energy against that coordinate rather than the frame number. TD-DFT/TDA excited states include orbital transitions and oscillator strengths in both gauges. EOM-CCSD includes signed single and double excitation amplitudes and uses the left-right spectrum for intensities. CASSCF and MRCI states retain their printed configuration occupation patterns and weights; MRCI also retains each state’s reference-space weight. ORCA’s .hess opens on its own, with its geometry and vibrational modes; it is told apart from NWChem’s .hess by content.
Molpro OUT (+ XML) .out, .xml, .xml-sidecar, .molden Task summaries (SCF/OPT/FREQ/CASPT2/CI/MRCC/MP2), correlated-energy capture, canonical extras seeded from XML manifests. The .xml and its binary .xml-sidecar beside an output are recorded as its inputs. A Kohn-Sham task reports its functional (B3LYP, PBE) as its method, read from Molpro’s Density functional group line. A CI or MRCI task keeps the Davidson and Pople cluster-corrected energies it prints, each with its state and its fixed or relaxed reference, beside its own variational energy. Symmetry indices (a CASSCF reference’s space symmetry, a CASPT2 reference symmetry) are named by the point group’s irreps, 1 (Ag), in the order the run’s integral listing gives them, which is the order its XML states. XML orbitals: the .xml and .xml-sidecar Molpro writes beside every run carry the basis and the orbitals through i shells, where its MOLDEN stops at g; they are paired with the output by its atoms, the CLI picks them up on its own, --movecs names one, and the Sources tab lists it. The coefficients are single precision, over Cartesian functions, and only the occupied orbitals unless the input asks for the rest with {put,xml;orbital,2100.2} (2200.2 for UHF, 2140.2 after MCSCF). RHF, ROHF, UHF, MCSCF natural orbitals, pseudopotentials, Cartesian bases, Pople bases (Molpro writes their sp shells as separate s and p groups) and optimisations (the last geometry) are covered. A UHF run also writes the natural orbitals of its total density beside its alpha and beta sets; --natural on orbital, cube and plot slice draws from those, as one set with fractional occupations. Their density equals the alpha and beta sets’ to single precision, which is the check.
Molcas/OpenMolcas OUT + companions .out, .molden, .scf.h5, .rasscf.h5 Canonical documents expose module tasks (extras.molcas.tasks), optimisation energy profiles, frequency mode counts, RASSCF/CASPT2 diagnostics. Sources tab loads .molden siblings (SCF / RASSCF / Guess / MP2 flavors) and renders MOs as 3D isosurfaces in the Surfaces tab — the MOLDEN file ships geometry, basis, and coefficients in one file so no extra companion is needed. Sibling matching auto-detects Molcas-style task suffixes (acrolein.scf.molden matches acrolein.out). HDF5 orbitals: a <project>.scf.h5 or .rasscf.h5 beside the output (OpenMolcas built with HDF5) carries the basis and orbitals through i shells, symmetry undone, and is paired by its atoms; the CLI picks it up on its own, --movecs names one, and the Sources tab lists it. The .h5 also opens by itself, with no output beside it: it holds the atoms as well, so orbitron cube nh3.scf.h5 --mo homo and the desktop work from the one file. An &SLAPAF IRC opens as a reaction path, with its geometries taken from the .irc.molden/.mep.molden files beside the output. A frequency run’s thermochemistry is read from its 298.15 K table: zero-point energy, the thermal corrections to E, H and G in kcal/mol, and the entropy by component in cal/mol-K (the column is headed kcal/mol*K, but G = H − TS holds only in cal), so orbitron analyze vibrations reports it, and the desktop’s task panel shows it on the MCLR card. A &SINGLE_ANISO analysis of a spin-orbit run is read: the pseudospin multiplets’ g tensors and axes, the ground multiplet’s crystal-field parameters and M_J decomposition, and the powder χT and magnetization (orbitron analyze magnetism, Analysis → Magnetism).
MOLDEN .molden, .molden.input Self-contained geometry, Gaussian basis, MO energies, occupations, spin channels, and coefficients. A coefficient a file leaves out is a zero, as CP2K writes them. Opens directly or enriches an ORCA/Molcas scene through Sources.
TREXIO (HDF5 backend) .h5, .trexio.h5 Content-detected HDF5 wavefunction container. Reads geometry, electron counts, optional periodic cell, ECP-aware atomic identity, Gaussian basis, and MO energies/occupations/coefficients. Coordinates and cells are converted from bohr to Å. Per-function ao_normalization, as CP2K and PySCF write it, is applied; a pseudopotential atom with no ecp group takes its element from its label. Cartesian AOs, non-Gaussian bases, determinants, RDMs, CSFs, amplitudes, and integral groups are refused or outside the current reader.
DIRAC .out (+ HDF5 checkpoint), .mol Relativistic QC output — geometry and run/energy summary; MO coefficients load from the companion HDF5 checkpoint via Analysis → Sources for orbital isosurfaces. Content-detected (no fixed extension). The .mol molecule input opens as a structure; it is told apart from a Molfile by content, and its coordinates are read in Å or bohr as its control line says.
Quantum ESPRESSO .out, .in, .xml, .xsf, .dos, .pdos_*, .bands, .UPF Periodic structures from .out text output, .in input decks, structured data-file-schema.xml (eigenvalues, occupations, fermi level), Cube-formatted .xsf densities (pp.x output_format=6) and proper XSF, DOS/PDOS/bands plot summaries under extras.qe, orbital projections from a projwfc.x run’s filproj output (projected “fat” bands), relax energy profiles, inline band samples. A pw.x output picks up the projwfc.x PDOS written beside it (<prefix>.pdos_tot and <prefix>.pdos_atm#…, matched by the prefix of the run’s save directory and checked against its atoms), so plot dos and plot pdos draw from the output, per element and shell (s, p, d, f; semicore and valence of one shell summed) and per spin. The stress tensor and pressure printed with tstress are kept in kbar under stress:tensor_kbar and stress:pressure_kbar, the keys the VASP and CP2K readers fill too: on every step of a relaxation, and on the structure for the last geometry
VASP Open directly: vasprun.xml, POSCAR, CONTCAR, XDATCAR, CHGCAR/CHG/PARCHG. Read beside an open run: OUTCAR, INCAR, KPOINTS, POTCAR, DOSCAR, EIGENVAL, PROCAR, DYNMAT, ACF.dat Open any of the first group by its canonical filename (no extension required); auto-switches to Analysis → Sources showing the rest of the directory. The second group is not a scene on its own; those files are picked up from the directory next to the opened run and hydrate it. Periodic geometry + DOS/band/forces/magmom/Bader, band gap (value, direct/indirect, and the k-points it occurs at), orbital projections from PROCAR (projected “fat” bands), site- and shell-resolved DOS from a LORBIT >= 10 DOSCAR, and high-symmetry corner labels read from KPOINTS. CHGCAR exposes total + spin-density isosurfaces. XDATCAR loads as multi-frame trajectory. POSCAR ↔︎ CONTCAR Compare overlay shows relaxation. Sources retired the old .zip/.tar archive-import flow. A dynamics run’s steps carry their kinetic, thermostat and conserved energies from either file, and the temperature VASP prints from the OUTCAR (see plot md). Each ionic step’s stress tensor and pressure (from OUTCAR’s in kB row, or each <calculation>’s stress in vasprun.xml, the two agreeing) are kept in kbar under stress:tensor_kbar and stress:pressure_kbar, the pressure being the tensor’s mean diagonal (VASP’s external pressure plus its Pulay stress), with the final structure carrying the last step’s. Each ionic step’s electronic loop is read iteration by iteration, from the <scstep>s of vasprun.xml or the free energy TOTEN lines of the OUTCAR (the two agree to the digits both print), so orbitron plot scf draws a VASP run; an OUTCAR opened by itself is a task as a vasprun.xml is, its kind from the INCAR it echoes. The OUTCAR’s last magnetization (x) and total charge tables become an atomic-sphere population: each site’s charge, with the core ZVAL leaves out added back, and its moment as the spin. It is read alike from the OUTCAR and from the vasprun.xml beside it when the two are one run (the same final geometry), so orbitron analyze populations and Python’s analyze_populations list it. A noncollinear run’s moments are vectors, so only its charges are kept.
CP2K .inp, .restart, .out, -pos-N.xyz, -N.ener, -N.cell, .bs, .pdos, .cube, -VIBRATIONS-1.mol, .metadynLog, -pos-Replica_nr_N-1.xyz, -centroid-pos-1.xyz The input deck and the restart file both open as scenes, cell included, so a run is periodic from the first file you touch — the trajectory .xyz carries no cell of its own. A deck that reads its coordinates from a file (&TOPOLOGY COORD_FILE_NAME with COORD_FILE_FORMAT CIF, PDB, XYZ, XTL, G96 or CP2K) reads that file from beside it and takes the cell from its own &CELL, as CP2K does: an XTL’s atoms through the XTL’s own cell with its SYM MAT images added (their translations in bohr, as CP2K 2025.1 applies them), a G96 POSITION block in nm, and a CP2K-format file with the deck’s &COORD UNIT and SCALED. Atom names become elements as CP2K makes them: cut at an underscore and stripped of trailing digits (O_w, H12), or named by a &KIND with an ELEMENT. A name only CP2K’s force-field name tables resolve (OW with no &KIND), and any name without a &KIND when the deck names a connectivity file, is refused by name, since Orbitron does not carry those tables. CRD files, whose atoms are named by an AMBER topology’s atom types, are refused for the same reason. A log printed at PRINT_LEVEL LOW holds no coordinates, so it opens on the files beside it: an optimisation’s <project>-1.restart, used only when it holds the atom count and final cell the log states, as the converged geometry (or the last one, when the optimisation stopped short), and otherwise the input deck or coordinate file the log names, as the starting geometry. .out gives geometry, cell, run type, method, functional, charge, multiplicity, total energy per step, SCF convergence, MD ensemble, three population analyses (Mulliken, Löwdin, Hirshfeld), and orbital eigenvalues with occupations. The eigenvalues come from either printing: the MO| table a diagonalisation writes (&PRINT &MO), or the occupied/unoccupied subspace blocks an orbital-transformation run writes, where the occupations are not stated and are read from the block labels and the run’s spin-state count. The Fermi level is picked up under all three of its spellings, including the unlabelled Fermi energy: in a smeared run’s SCF energy breakdown, which is in Hartree while the other two are in eV. An MD run’s -N.ener becomes per-frame time, temperature, potential and conserved quantity, and -N.cell a per-frame box for NPT and CELL_OPT; without a -N.cell a cell optimisation’s frames take their cells from the log, each the cell of the last geometry its step evaluated, which is what the .cell file records. A CG optimisation’s trajectory ends at the frame its restart holds: CG writes one more. .bs is a band structure with named high-symmetry corners, already in eV. .pdos holds discrete projected states rather than a curve: orbitron plot dos and plot pdos draw them broadened at 0.1 eV FWHM and say so, one curve per kind and shell, and orbitron analyze dos broadens them at any width (§4.1.1 of the CLI guide). Vibrations come from the -VIBRATIONS-1.mol Molden file, which is content-detected despite the .mol extension. Wannier centres load as ghost X sites. A metadynamics run’s -COLVAR.metadynLog and -HILLS.metadynLog give per-frame collective-variable values on the trajectory and a free-energy profile through orbitron analyze metadynamics. A RUN_TYPE BAND (NEB) log opens as a reaction path, its replica files found by the project the log names: the chain of replicas at the last band step every one of them reached, with the climbing image as the transition state and forward/reverse barriers, the same presentation ORCA, NWChem and Gaussian IRC paths get. A QM/MM run loads the whole system rather than the quantum part of it — the log’s MODULE FIST table is everything and the MODULE QUICKSTEP one only the QM region — and marks the quantum atoms with a cp2k:qm_region property, so property("cp2k:qm_region") > 0.5 selects them and --group draws them differently from their environment. Forcefield kinds take their element from the mass column rather than the kind name, since CA is calcium to a symbol table and an alpha carbon to the input that wrote it. A path-integral (RUN_TYPE PINT) log opens as the centroid trajectory, and each nucleus carries its ring-polymer radius of gyration as a cp2k:ring_polymer_radius_angstrom property — the quantum delocalisation, large for hydrogen and near zero for heavy nuclei, so property("cp2k:ring_polymer_radius_angstrom") > 0.05 selects the nuclei that need quantum treatment. It is computed from the bead trajectories rather than read from -centroid-gyr-1.dat, whose unit comes from an input keyword the output never states. A real-time propagation (RUN_TYPE RT_PROPAGATION) has its dipole read from the log, one block per step, and orbitron analyze spectrum turns it into an absorption spectrum; the timestep comes from the input deck beside the log, which is the only place it appears. A CELL_OPT log’s final structure carries the internal pressure printed for its last geometry, in kbar, under stress:pressure_kbar, and each frame of its -pos-1.xyz trajectory its own step’s pressure, with the tensor in stress:tensor_kbar when the run printed one (&MOTION &PRINT &STRESS writes a -1.stress file; &FORCE_EVAL &PRINT &STRESS_TENSOR puts it in the log). A deck whose &CELL names a cell file (CELL_FILE_NAME, in CP2K’s own .cell format, CIF or XSC) takes its cell from that file, as CP2K does.
QMCPACK the input deck (.xml), with <project>.sNNN.stat.h5 and the included particleset beside it Open the deck, not the results. A stat.h5 carries no attributes at all — no units, no geometry, no grid shape — so a SpinDensity on a 24×24×24 grid arrives as a flat 13,824-vector per block with nothing to say it is a cube or where it sits. The deck holds the grid, the cell, the geometry and which method wrote which series. One series is one task, so a deck that ran VMC then DMC is two tasks of one calculation. A run that diverged or was killed is marked with the numbers behind the verdict: QMCPACK exits 0 and writes a file either way, and a diverged DMC can be majority NaN while qmca reports nan +/- nan. A periodic density is attached per spin with a per-voxel standard error over the blocks — the grid is stored once per block, so an error bar per voxel comes for free — and only after two checks: each channel must sum to its own electron count, and the density must occupy more voxels than one row of its grid. An open-boundary molecule fails the second: QMCPACK bins in the particleset’s lattice, which an open system does not have, so it writes a grid that sums correctly with every electron in one voxel. That grid is refused and the reason is said out loud. Each series’ card in the viewer’s Tasks tab carries its traces — every scalar with its blocked error and correlation factor, the trace itself with that error band drawn across it, and the blocking curve with the level that was taken marked on it. The same numbers come from orbitron analyze qmc (§4.1.5 of the CLI guide), which draws them as a PNG. A blocked error bar is what a QMC number is quoted with: the naive one over the stored blocks is too small, because the walk is correlated. A OneBodyDensityMatrices estimator additionally gives natural occupations per spin, as the eigenvalues of the block-averaged 1RDM in whichever SPO basis the deck named; the check that the matrix means anything is its trace against that channel’s electron count, and the normalisation has to be recovered from the integrator the deck asked for because the file does not record it. Ionic forces come from the run’s .scalar.dat and not from the stat.h5, which holds one scalar per block rather than per-atom components. Both settings that make those components a force are off by QMCPACK’s default, and either omission produces numbers that look like forces and are not, so Orbitron refuses them unless the ion-ion Coulomb term carries forces="yes" and the estimator spacewarp="yes" — and says which was missing. Each atom’s force is kept as its per-block series, because the four Assaraf-Caffarel terms are strongly anticorrelated and adding their separate errors in quadrature inflates the bar enough to hide a real disagreement.
CIF .cif Symmetry + periodic unit cells with provenance tags, plus mmCIF chain/residue identity, declared and unresolved polymer sequence, alternate locations, source connections, biological assemblies, secondary structure, and chemical-component type/name/formula/mass/parent metadata. _struct_conn metalc rows become dative bonds, donor first. _chem_comp_bond is taken as each component’s complete connection table: it sets the order of every bond inside a residue, restores a bond it states that the coordinates stretched past inference, and removes one between two heavy non-metal atoms that it names but does not bond (4HHB had seven, such as a serine’s CA to its OG). The standard residues’ and the commonest ligands’ tables are built in, so a PDB file gets the same. A single-atom ion with no charge of its own takes the one _chem_comp.formula states (Zn 2). _pdbx_struct_mod_residue supplies a modified residue’s parent where _chem_comp leaves it out, so the residue stays in its chain. Assemblies from _pdbx_struct_assembly_gen keep each chain group apart and expand operator products such as (X0)(1-60). The method, resolution, and free R value from _exptl and _refine are tagged pdb:experimental_method, pdb:resolution_angstrom, and pdb:r_free. Multi-model mmCIF files open as a model collection with source model numbers and no invented time steps; reordered rows are aligned by atom identity, while inconsistent models are reported and left first-model-only. The wwPDB 1 Å P1 placeholder used by non-crystallographic structures is not treated as a periodic cell. The asymmetric unit is expanded on load, tagged cif:expanded_asymmetric_unit:<from>:<to>, using the file’s symop loop or, when it has none, the space group it names (tagged cif:space_group_from_table:<number>:<hall>). Where the symbol leaves the origin choice open, the listed coordinates decide it (an expansion that puts atoms impossibly close, or that scatters a site across a lower-symmetry position, is the wrong one), tagged cif:space_group_setting_from_sites:<number>:<choice>:<hall>. If nothing distinguishes them the file is left unexpanded and warns cif:ambiguous_space_group_setting:<number>:<choices>, since the wrong setting moves atoms silently; add :1/:2 or :H/:R to the symbol, or a _space_group_name_Hall line, to say which
PDB .pdb, .ent, .brk, .pdb1 Biomolecular chains/residues, declared sequence and missing residues, alternate locations, source connections and inferred bonds, biological assemblies, and secondary structure. CONECT and LINK records are read as bonds; a LINK or SSBOND to a symmetry copy has no partner in the file and is skipped with a warning (pdb:link_across_symmetry_skipped, pdb:ssbond_across_symmetry_skipped). A metal contact stated by CONECT or LINK becomes a dative bond, donor first (§2.6). A single-atom ion with blank charge columns takes the charge its FORMUL record states (ZN 2+). HELIX and SHEET are read by column, insertion codes included. MODRES names a modified residue’s parent, so a phosphoserine stays an amino acid in its chain. Each REMARK 350 APPLY block is its own biological-assembly chain group. EXPDTA and REMARK 2/3 give pdb:experimental_method, pdb:resolution_angstrom, and pdb:r_free. Where alternate locations model different residue types at one position, each conformer keeps its own residue name. Multi-model ensembles open as a model collection with source MODEL numbers rather than time steps; models with different atom identities cannot be combined and are reported. The wwPDB 1 Å P1 placeholder used by non-crystallographic structures is not treated as a periodic cell
SDF/MOL .sdf, .mol V2000 and V3000 connection tables, bond orders including dative (V3000 type 9, see §2.6), canonical structure + raw-source attachments. A multi-record file loads every record as a trajectory tagged trajectory:kind = "records", so the UI steps it as “Record N of M” and any unreadable record is counted in sdf:unreadable_records:N. The single-scene path takes only the first record and reports the rest as sdf:skipped_records:N in io:warnings
Standalone NBO summaries .nbo + optional .47 (FILE47) Natural population tables and the full natural bond orbital table — bonding (BD), antibonding (BD*), core (CR), lone pair (LP), lone vacancy (LV) and Rydberg (RY), each with its bond order and per-atom contributions. Optional FILE47 geometry/basis metadata for NBO7; canonical documents capture population extras and raw logs. An open-shell run prints one orbital table per spin and only the alpha table is read, reported as nbo:extra_spin_tables_not_parsed:N in io:warnings
Volumetric CUBE files .cube, .cub Single grids with metadata + volumetric attachments
Volumetric directories directory of .cube files Ensures all cubes share a geometry, emits per-grid attachments and dataset metadata
MRC2014 / CCP4 maps .mrc, .map, .ccp4 Scalar experimental-density maps with endian-aware voxel decoding, nonstandard axis permutation, nonzero origins or start indices, skewed crystallographic cells, header statistics, and registered Cartesian placement. Ordinary maps open positive-only at the header-derived contour; signed difference maps can enable a separately colored negative contour. Uncompressed scalar modes are supported. Complex modes and volume stacks are refused, and compressed .map.gz files must be decompressed first.

ORCA orbital isosurfaces need one conversion step. ORCA keeps its basis set and MO coefficients in .gbw, a binary with no published layout whose header carries a build identifier, so Orbitron does not read it. Use ORCA’s converter:

orca_2mkl <basename> -molden

This writes <basename>.molden.input, an ordinary MOLDEN file that Orbitron reads in the desktop, CLI, and Python. Put it beside the output and load it under Sources. Orbitron checks atom identities and coordinates before it attaches the basis and coefficients to the active ORCA scene.

Loaders apply provenance tags, infer covalent bonds (orbitron_backbone::infer_covalent_bonds), and attach task metadata.

Biological identity when exporting

Choose an export by the identity it can carry:

Export Biological identity retained
Orbitron bundle/session The complete scene: stable atom IDs, atom and bond properties, component definitions, and source metadata.
PDB Author chain, residue name and number, insertion code, atom name, alternate location, record kind, element, HELIX and SHEET ranges, and active SSBOND records. Atom serials are local to the written file. Every bond the scene carries is written as a CONECT record, stated and dative metal bonds included, with a remark saying the table is complete, so Orbitron reads back the same bonds; bond orders are not written and are perceived again. No LINK records are written. General mmCIF label identifiers, chemical-component definitions, and _struct_conn rows do not fit PDB.
GRO Residue number/name and atom name/number, within the format’s five-column limits. Chain, insertion-code, alternate-location, mmCIF label, component-definition, and source-connection identity are absent from GRO; Orbitron reports each applicable loss after export.
MOL/SDF Element, formal charge, isotope, stereochemistry, and explicit connectivity. Chain and residue identity are absent.
XYZ Element and coordinates only.

Keep an Orbitron bundle beside a PDB, GRO, MOL/SDF, or XYZ export when the full edited scene must reopen without format loss.

GROMACS GRO structures and short trajectories

Orbitron treats .gro as a coordinate format. A single frame opens as a structure. Concatenated frames open as a trajectory in the desktop, TUI, CLI, and Python bridge. The parser accepts the format’s variable coordinate precision, optional velocity columns, title times, and three- or nine-value box records. Source residue and atom numbers are retained even when their five-column fields wrap.

GRO does not contain bonds, atom charges, isotopes, force-field parameters, chain IDs, insertion codes, alternate locations, mmCIF label identifiers, chemical-component definitions, or source connections. Orbitron may infer bonds for display and analysis, but writing GRO cannot store these fields. The desktop, CLI, and Python bridge exporter report each applicable loss. Use an Orbitron bundle when those fields must survive, or keep the original GROMACS topology beside the coordinate file.

See GROMACS and MD trajectories for frontend examples and the current XTC/topology boundary.

Experimental density maps

Open an MRC2014 or CCP4 map directly to inspect its cell and density, or open the matching PDB/mmCIF model first and use Analysis → Surfaces → Add volume… to place both in the source Cartesian frame. Orbitron applies MAPC, MAPR, and MAPS, the origin or start indices, cell sampling, and cell angles when it builds the grid transform. It does not fit or translate a model to a map by guesswork.

Experimental density starts at the header-derived recommended contour and draws only the positive surface. Expand the row to change the contour, opacity, or color. Enable Negative contour for a signed difference-density map. These choices are stored in sessions and Orbitron bundles, and are replayed by desktop, CLI, and Web View rendering.

MRC volume stacks (ISPG 401 through 630) and complex Fourier modes are not scalar maps, so Orbitron rejects them. Large maps pass through the same resource preflight as CUBE and XSF files; the header contributes exact stored grid dimensions before voxel decoding begins.

When atoms are selected, a volume row offers Clip to selection. Orbitron captures their Cartesian bounds with 4 Å of padding, adjustable from 0 to 20 Å. The captured region stays fixed if the live selection changes; use Update from selection to capture new bounds or Show full map to remove the clip. Cropping runs before the surface memory gate, decimation, and marching-cubes step, including for skewed grids. It lowers mesh-generation work, but it does not lower the cost of parsing or retaining the map. Sessions, bundles, CLI renders, and Web View exports retain the clip.

XTC is a coordinate stream rather than a topology. Its indexed service source keeps topology identity and bonds stable while decoding requested frames into a three-frame cache. Atom count must match on every frame. First-frame coordinate agreement verifies order; otherwise a caller must explicitly confirm order and Orbitron records the pair as unverified.

Construction input: SMILES

SMILES is a builder input rather than a file loader. Use Edit → SMILES, orbitron from-smiles, or Scene.from_smiles(). The supported subset covers atoms, bracket atoms, isotopes, formal charges, aromatic atoms, branches, ring closures, disconnected components, tetrahedral @/@@, and non-ring alkene //\ stereochemistry. Orbitron adds explicit hydrogens and can generate deterministic 3D coordinates.

Stereo requires 3D generation. Wildcards, atom maps, reactions, SMARTS, CXSMILES, ring-alkene stereo, and non-tetrahedral atom configurations are refused. Bracketed metal ions are accepted, but Orbitron’s deterministic 3D embedding is a starting geometry rather than a metal-complex structure prediction. Import MOL or SDF from a chemistry toolkit when unsupported SMILES features matter. See Viewer §3.7.12.

The format table describes what can enter the canonical document. The Analysis Results guide shows where dipoles, computed bond orders, method and basis provenance, implicit solvation, SCF histories, multireference contributions, and periodic electronic structure appear in the desktop, TUI, CLI, and Python bridge.

Interested in adding a new format? See the checklist in the Developer Guide (§6.1 Adding a New Chemistry Format) for a turnkey parser skeleton, naming conventions, and test scaffolding.

2.1 Quantum ESPRESSO support

Orbitron’s QE ingestion handles the full file zoo a typical QE project carries:

  • SCF / relax / nscf outputs (*.out): periodic structures + unit cells, SCF energetics, relax profiles, and task summaries (extras.qe).
  • Input decks (*.in): parses &CONTROL, &SYSTEM, ATOMIC_SPECIES, ATOMIC_POSITIONS, and CELL_PARAMETERS sections; derives the lattice from ibrav (0–14, including centred orthorhombic / monoclinic / triclinic variants) + celldm(1..6), or from explicit CELL_PARAMETERS for ibrav=0. Atom positions handled in alat / bohr / angstrom / crystal units. Open a .in directly to view the structure before running the calculation.
  • Structured XML output (<prefix>.xml / <prefix>.save/data-file-schema.xml): parsed via roxmltree. Surfaces atomic_structure, per-k-point eigenvalues + occupations, Fermi level, total energy, convergence status, exit status, and spin / SOC flags. More reliable than scraping .out because the schema is version-stable.
  • XSF volumetric (*.xsf): handles both proper XSF (CRYSTAL / SLAB / POLYMER / MOLECULE / ATOMS, with DATAGRID_3D grids, as pp.x writes with output_format=5) and QE’s “Cube-as-xsf” flavour (pp.x output_format=6 writes Gaussian Cube content with an .xsf extension). An XSF grid is a general grid whose last point along a periodic axis repeats the first; that point is dropped, so the grid matches a cube of the same data point for point. Either flavour’s grid opens in Surfaces like a .cube and travels in a bundle exported from the file.
  • DOS / PDOS / bands (*.dos, *.pdos_tot, *.pdos_atm#*, *.bands, *.bands.gnu): parsed into canonical-document extras.qe blocks with metadata for atom / WFC / orbital labels. The Sources panel surfaces each file as its own role.
  • Orbital projections (*.projwfc_up, *.projwfc_down / *.projwfc_dw): projwfc.x’s filproj output, read from beside the .out and turned into projected (“fat”) bands. projwfc.x is a separate calculation, so the group is accepted only when its k-point grid matches the band structure it would decorate, and an ambiguous set of companions is ignored rather than guessed at.

Current limitations:

  • QE band structure plots in Analysis → Periodic through the same shared periodic panel VASP uses. A dos.x .dos file carries its density of states (both channels for a spin-polarised run), so orbitron plot dos draws it. Its header calls the run’s level EFermi whatever it is; when a pw.x output beside it reports that level, to the header’s three decimals, as its highest occupied one (fixed occupations), the curve is drawn against E_VBM, and otherwise against E_F. Loading it under Sources beside an open run still only confirms it parses, and does not add it to that panel’s DOS plot. The .pdos_* files projwfc.x writes are read when the pw.x output is opened, found beside it by the prefix it names: the pdos_tot file becomes the DOS and the per-atom files the projected DOS, per element, shell and spin, in Analysis → Periodic and in orbitron plot dos and plot pdos. Loaded alone under Sources, one is parsed for a summary only.
  • .UPF pseudopotentials are surfaced informationally in Sources but not parsed (no viewer feature consumes them today).
  • atomic_proj.xml and the <prefix>.save/ binary checkpoint hierarchy are not parsed. projwfc.x’s other output, the filproj text files, is — see the bullet above.
  • ibrav values are derived to a primitive cell; the ±13 monoclinic centred variants are treated as primitive with a warning that the centring isn’t expanded.

2.2 NBO FILE47 support

Orbitron can enrich standalone .nbo summaries with optional FILE47 (.47) sidecars. When a .47 file is present next to the .nbo log, Orbitron uses it to reconstruct the NBO7 basis/geometry payload so orbital and population views align with the original analysis. If the .47 file is missing or malformed, Orbitron still loads the .nbo summary — the populations and the orbital table both come from the .nbo text itself, so only the geometry falls back to synthetic positions (tagged nbo:synthetic_geometry).

The orbital table is read by the same parser whether it arrives standalone or embedded in a Gaussian log, so analyze_nbo() (Python) and the NBO tab return the same shape for both. Two things about it are worth knowing:

  • Antibonding orbitals are their own kind. BD* is not folded into BD; they are the donor and acceptor halves of a second-order perturbation analysis, and a uranyl .nbo reads as three bonding and three antibonding U–O orbitals per bond.
  • Only the alpha table of an open-shell run is read. NBO prints one table per spin and Orbitron’s orbital records carry no spin, so merging them would double the count with no way to separate them. The file warns nbo:extra_spin_tables_not_parsed:N rather than returning half its orbitals silently.

2.3 Streaming defaults

Orbitron now prefers streaming parsers whenever possible. Gaussian and NWChem log readers walk the file once to build a run summary, then seek straight to the requested stage/task when you load individual geometries, trajectories, or frequency sets. CLI/TUI/GUI all call the same boundary helpers:

  • gaussian_stage_scene_by_boundary / gaussian_stage_trajectory_by_boundary
  • gaussian_stage_frequency_by_boundary
  • nwchem_task_scene_by_boundary / nwchem_task_trajectory_by_boundary

If you script against the Rust API, use these helpers to avoid re-reading the full file.

Note: The orbitron_services::streaming trait (TrajectoryStream / TrajectoryStreamExt) exists and is exported, but no format implements it yet. Frame-at-a-time decoding arrived through a different trait, orbitron_services::TrajectorySource: IndexedXtcSource and IndexedXdatcarSource index the file once and then decode only the requested frames, keeping a small frame cache. Background loaders keep the UI responsive for the formats that still parse the whole file.

2.4 Shared parser behavior

Parsers reuse helpers from io/pipelines/src/parsing_utils/ for finite floats, Fortran D exponents, coordinate triples, unit conversion, section markers, software-version detection, and common token patterns. Adoption varies by format, so parser-specific tests remain the source of truth for malformed input and boundary behavior.

These helpers reject non-finite coordinates and normalize recurring syntax, but they do not make every parser equally permissive. When a file cannot be read, use the reported format, section, and source warning to distinguish an unsupported construct from a damaged file. Large-output behavior is also format-specific: Gaussian and NWChem have byte-ranged stage or task loaders, while several other formats still parse the complete source.

These improvements affect all file formats supported by Orbitron, making the entire I/O pipeline more robust and maintainable. For technical details about the parsing utilities and their adoption, see the Developer Guide (§6.4 Parsing Utilities Reference).

2.5 Per-atom population coverage

The 2026 redesign of the Analysis panel (§3.6) made per-atom charges first-class — every supported format now surfaces them through the same UI (the Charges tab + the Atom Coloring halo overlay). Coverage of the basis-partitioned methods by format (AtomicSphere site moments and Bader basin charges are separate methods and are not in this table):

Format Mulliken Löwdin Hirshfeld Natural (NBO) APT
NWChem (.out) ✓ (modern + property-module headers) ✓ — — —
Gaussian (.log) ✓ — — ✓ (when pop=full / NBO) ✓ (frequency jobs)
Gaussian (.fchk) ✓ — — — —
ORCA (.out) ✓ (with spin populations, from the last SCF) — — — —
Molpro (.out) ✓ — — — —
Molcas / OpenMolcas (.out) ✓ (column-oriented blocks) — — — —
CP2K (.out) ✓ ✓ ✓ — —

Hirshfeld is in the table because CP2K prints it beside the other two and, for a plane-wave run where Mulliken and Löwdin partition a basis that is not atom-centred, it is the charge that means something.

For optimization trajectories (NWChem, Gaussian), each step carries only the populations its own SCF printed. Charges are not copied from the converged step onto earlier ones, because they would describe a different geometry. A step whose SCF printed no population table has no charges, so the Charges tab and halos are not offered there. By default Gaussian, for example, prints a full population analysis on the first step and after convergence only.

For property-module runs (e.g. NWChem task scf property with the mulliken keyword) the parser returns the last Mulliken table emitted in the file — the converged value, not the preliminary atomic-guess Mulliken that some packages print early in the run.

2.6 Dative (coordination) bonds

A metal–ligand donation is a bond that both atoms’ valences have to agree about, and most connection-table formats cannot express one. Orbitron carries it as its own bond order and preserves it on export.

Where it comes from. Bond perception marks a metal–ligand pair as dative when the order search did not already find a multiple bond, and only when the ligand atom is a lone-pair donor (N, O, F, P, S, Cl, Br, I). Carbon is deliberately excluded: a metal–carbon bond is as likely to be covalent, and geometry alone cannot tell. A file that supplies its own bond orders keeps them. A metal contact a structure file states without an order is read as dative too, donor first: a PDB’s CONECT or LINK record between a metal and a lone-pair donor, and an mmCIF _struct_conn row of type metalc. Read as single bonds, as they were before 2026-09-24, they left a zinc’s water one hydrogen short.

What it fixes. Flattening a donation to a single bond costs the donor a hydrogen, because a single bond and a donation imply different valences. Read through a Molfile, a zinc tetraaza macrocycle used to come back as C₁₆H₂₄N₄Zn; it now reads C₁₆H₂₈N₄Zn, matching the geometry.

Export. V2000 has no code for a coordination bond, so a structure containing one is written as V3000 at any size, using bond type 9 with the donor first. The V3000 reader takes type 9 back as dative, so a round trip is lossless.

The limit worth knowing. SMILES and InChI both write a dative bond as a single bond, because that is how those formats express it and a hydrogen count derived from one valence with a string written from another would not describe the same molecule. So a metal complex’s InChI still counts the donor’s valence one too high. That is a limitation of the identifier formats, not something this changes.

A crystal that repeats has no molecular identifier. InChI and SMILES name a finite molecule, so Orbitron declines to write one for a structure whose bonds close through the lattice, and says why rather than reporting a failure:

$ orbitron identify Si/scf.out
Note: bonds repeat through the lattice, so this is an extended solid and
      no molecular identifier describes it
formula:   Si2
inchi:     (none: extended solid)

The formula still stands — it is the cell’s contents, which is a fact about the file even when no molecule is. Before this, silicon identified as disilane and graphene as ethane: at the cell face the atoms look under-coordinated, and the identifier filled the gap with hydrogen that is not there.

The test is whether the bonded network is finite, not whether the file has a cell. A molecule that merely sits inside a box is unaffected, which matters for structural biology: a PDB entry carries a CRYST1 record and legitimately omits its hydrogens, and InChI adding 849 of them to ubiquitin is correct. A molecule broken across a cell face is finite too, so it is joined up first and named whole — urea in its own cell has its second nitrogen in the neighbouring one, and used to read as two species.

This is the rule the Crystallography Open Database’s own workflow for deriving SMILES and InChI from crystallographic data uses, where a structure spanning an unbounded number of cells is marked as such and excluded from identifier generation.1 Identifiers that do describe an extended solid are a different kind of object and out of scope here: Graph ID hashes a structure for deduplication and cross-database linking rather than naming it,2 and MOFid decomposes a framework into metal nodes, organic linkers and a topology symbol.3

2.7 Basis functions up to i (l = 6)

Orbitals and densities are evaluated from the file’s basis set for shells s through i, pure (spherical) or Cartesian: enough for cc-pV6Z, Peterson’s cc-pVQZ-DK3 actinide sets and Dyall’s 4z sets, which reach i. What reaches Orbitron depends on the program that wrote the file, and several cannot hand an h or i shell over at all. Each row below was checked by running the program (C1 NH₃ with cc-pV5Z and cc-pV6Z on N) and comparing Orbitron’s orbital with the program’s own plot of it, point for point: Gaussian’s cubegen, ORCA’s orca_plot, NWChem’s dplot. For h and i that includes virtual orbitals made almost entirely of those functions, since an occupied orbital holds too little of them for a wrong sign to show.

Program File h and i shells Notes
Gaussian 16 .fchk ✓ pure and Cartesian (6D 10F) Matches cubegen to its five significant figures
ORCA 4.2, 5 and 6 .molden via orca_2mkl ✓ pure ORCA’s pure f, g, h and i carry the opposite sign to MOLDEN’s for m = ±3 and ±4 (and only those); Orbitron applies ORCA’s convention when the file says it came from orca_2mkl
NWChem 7 .out + .movecs ✓ spherical and Cartesian
DIRAC CHECKPOINT.h5 ✓ Cartesian Compared with DIRAC’s **VISUAL plots, non-relativistic and four-component. A run with symmetry (D2h and its subgroups) stores its orbitals over symmetry-adapted functions and the shells of the symmetry-independent atoms only; they are put back on every atom. Checked orbital by orbital against the same molecules’ C1 runs, Cs to D2h: N₂ and CO₂ in cc-pV6Z (i functions on both N and on the central C), I₂ in dyall.v4z (g), and UO₂²⁺ in dyall.v4z (h and i on uranium at the inversion centre), the orbitals that are mostly g or higher to 6e-7 of their peak density or better; the relativistic construction (X2C I₂ and UO₂²⁺, four-component CO) by the total occupied density, to 1e-9. A relativistic spinor’s large component spans several irreps, one per quaternion part, and the dominant one is drawn, as the dominant quaternion slice is in C1
OpenMolcas .scf.h5, .rasscf.h5 ✓ pure through i; Cartesian h and i MOLDEN cannot carry it: OpenMolcas refuses above g (“Molden does not know how to handle functions with angular momentum larger than g”) and writes no file. The HDF5 file has the whole basis, with or without symmetry (SCF and RASSCF alike). Checked against GRID_IT plots: NH₃ with aug-cc-pV6Z on N, C2v water, RASSCF. The stock OpenMolcas build has HDF5 off, and asking for Cartesian d through i together can lose orthogonality in the SCF
Molpro .xml + .xml-sidecar ✓ Cartesian through i The XML has the whole basis and the orbitals in single precision (about 1e-7 in a coefficient). Checked against Molpro’s own CUBE plots: water in cc-pV6Z with the HOMO and the virtuals with the most g, h and i character (1e-5 of the peak), and cc-pVQZ; and by the complete orbital set being orthonormal in an independent basis (3e-6, single precision) for cc-pV6Z water and N₂. Ask for the virtuals with {put,xml;orbital,2100.2}
Molpro .molden ✗ Molpro writes the file but leaves the h functions out, stating so only in its .out: the orbitals in that MOLDEN are truncated. Use the XML above for a basis with h functions
Gaussian’s built-in NBO 3.1 FILE47 (.47) ✗ Its archive omits the g and h contraction coefficients, so NBO 7 and Orbitron both refuse it; Cartesian h ends the Gaussian job with an error

A MOLDEN file with a Cartesian h or i shell is refused: the format defines no component order past g, and no program found writes one. A shell above i (k and up) is still left out of an orbital, with a warning naming the shell.

Atoms under an effective core potential. The MOLDEN [Atoms] row’s third column is a nuclear charge, and programs disagree about which one an ECP atom gets. PySCF writes the charge the core leaves (U 1 32 for uranium under a 60-electron ECP, Au 1 19 for gold under def2’s) and adds a [core] section (1 : 60); Molpro 2026.1 writes the charge the core leaves too (AU 1 19), with no [core]; ORCA’s orca_2mkl writes the full atomic number. Orbitron takes the element from the row’s symbol whenever the column is below the symbol’s atomic number and above zero (zero is a ghost centre), and says so once per file:

Row 1 of [Atoms] is U with 32 in its charge column, below U’s atomic number. It was read as U, and the column as the charge an effective core potential leaves (PySCF writes it so).

A [core] count that is not the element less the column (ecp_core_disagrees) is reported too. The electron count comes from the orbital occupations either way, so it was never affected; the element was, and before 2026-10-10 a PySCF uranium loaded as germanium, and a Molpro gold as potassium.

Before 2026-09-28, h shells were skipped with a warning, and an ORCA MOLDEN orbital with any f or g functions was drawn slightly wrong (up to 1% of its peak) because ORCA’s sign convention was not applied. Every DIRAC orbital with d functions or higher was drawn a few percent of its peak off, and a DIRAC run with symmetry was drawn unrecognisably.

Footnotes

  1. A. Vaitkus, A. Merkys, T. Sander, M. Quirós et al., “A workflow for deriving chemical entities from crystallographic data and its application to the Crystallography Open Database”, J. Cheminform. 15 (2023). doi:10.1186/s13321-023-00780-2↩︎

  2. K. Muraoka, Y. Tanimoto, K. Munekata et al., “Universal graph-based identifiers of chemical structures for linking large material databases”, Nat. Commun. 17 (2026). doi:10.1038/s41467-026-74536-5↩︎

  3. B. J. Bucior, A. S. Rosen, M. Haranczyk et al., “Identification Schemes for Metal-Organic Frameworks To Enable Rapid Search and Cheminformatics Analysis”, Cryst. Growth Des. 19, 6682 (2019). doi:10.1021/acs.cgd.9b01050↩︎