Scope and known limits

Orbitron is a multi-format viewer and analysis tool with strong scriptability, but it deliberately does not try to be everything. Specific gaps to be aware of:

Orbitron writes the structure, not the whole input file. A Gaussian .com, an NWChem or Molcas .inp or a Quantum ESPRESSO .pwi is mostly method, basis, convergence and job choices that differ from one study to the next, so Orbitron leaves the input deck to you and writes the part it knows: the geometry. Coordinates export as XYZ (with charge and multiplicity in the comment line), PDB, GROMACS .gro, or an MDL Molfile or SDF when the connection table matters, ready to paste into a template. A scene with a unit cell also exports as a VASP POSCAR, with a Selective dynamics block when some atom is frozen.

No saddle-point search, and no NEB optimizer. Orbitron does not search for a transition state and does not run a nudged-elastic-band optimization. A band that has already been computed is viewable: a CP2K RUN_TYPE BAND log opens as a Reaction Path — 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. An IRC gets the same presentation: the Analysis panel gives it a Reaction Path tab rather than treating it as an optimization, the trajectory readout carries the reaction coordinate and its unit and marks the transition-state frame, orbitron inspect --json emits a reaction_path block, and an .orbpack bundle carries the section. The optimization-trajectory viewer likewise renders existing trajectories but does not run them.

The molecular builder covers main-group organics, metal complexes, and standard amino-acid mutation, not every construction workflow. Edit Mode has grown well past atom/bond manipulation: nine placement geometries, generated C₃–C₈ rings, SMILES construction, conformer search, residue mutation, hydrogen and bond-order perception, coordination-sphere repair, 3D embedding, freezing, UFF relaxation, and a connectivity-driven Clean (see Viewer §3.7). Its current boundaries are:

Avogadro and ChemDraw remain better at freehand 2D sketching. Orbitron’s builder is aimed at getting a chemically sensible 3D starting structure — particularly a coordination compound — into a calculation.

Molecular surfaces are computed on a grid, so their accuracy is the grid spacing. The solvent-accessible surface is extracted from a distance field and the solvent-excluded one by eroding it, rather than by rolling a probe analytically. Near the surface the erosion’s distances are refined with each seed’s own distance to the accessible spheres, so the excluded surface converges as the square of the spacing: measured on two isolated carbons, where the answer is exactly the van der Waals volume, it is off by -3.8%, -0.7%, -0.09% and +0.02% at spacings of 0.5, 0.25, 0.125 and 0.0625 A, against the 1.18% volume error EDTSurf reports at its 128-cubed grid. (Until 2026-10-16 the erosion measured to voxel centres and the excess ran 13.8%, 5.7%, 2.2% and 0.8%.) The accessible and van der Waals areas are integrated over the atoms’ spheres, since a mesh cuts across the creases where spheres meet. The default spacing of 0.125 A is coarsened on a large structure to keep the computation interactive, and every render says when that happened. Orbitron does not produce an analytic Connolly surface and does not decompose the surface into convex, saddle and concave patches.

Van der Waals radii are a choice, not a constant. Two tables are available, Alvarez 2013 and Bondi 1964, and every area and volume scales with the one selected. Orbitron refuses an element the chosen table does not cover rather than substituting a stand-in radius, because a stand-in produces a surface that looks exactly like a correct one. Neither table adjusts a radius for oxidation state, charge, or coordination environment, which matters most for the metals. Where the file states a metal’s charge and coordination number, Orbitron substitutes a Shannon ionic radius by default rather than living with that — --radius-policy ionic-when-known is the default for both orbitron render and orbitron sasa, and each reports the elements it applied it to. Pass --radius-policy vdw when comparing against a published area, because that is what published areas use. A metal whose charge the file does not give still falls back to the neutral table radius.

Limited biology workflows. Orbitron parses PDB/mmCIF chain, residue, alternate-location, connection, and secondary-structure metadata; renders protein/nucleic cartoons; supports linked sequence and 3D selection; and can display biological assemblies. mmCIF chemical-component definitions classify modified peptide and nucleic-acid monomers and expose source names, formulae, masses, and standard parents. Semicolon-delimited multiline component display fields are not retained. Static-structure inspection covers residue shells, ligand and chain-interface contacts, explicit-H hydrogen bonds, named salt bridges, disulfides, mononuclear metal sites, and per-pair steric clashes. Protein-backbone validation uses the six residue-specific Richardson Lab Top8000 Ramachandran distributions and exposes each result as a selectable residue. Side-chain validation evaluates complete rotamer-bearing amino acids against the 17 Richardson Lab Top8000 percentile grids and exposes each visible conformer as a selectable result. A separate panel detects missing side-chain and backbone heavy atoms in supported coordinate-bearing amino acids. The six row-based validation panels export all findings as CSV or JSON with scene and analysis provenance. Supported incomplete standard side chains can be rebuilt with detached fit and clash validation. Orbitron does not assign named rotamers during validation or build missing backbone atoms and loops. PDB export writes coordinates, CRYST1, HELIX, SHEET, SSBOND, assembly remarks and every bond as CONECT, metal coordination included, so the connection table survives it; bond orders are not written (PDB has no aromatic bond), and Orbitron perceives them again on reading. Save an .orbpack or a Molfile when the orders matter. Alternate coordinates are retained and selectable, and edit mode provides explicit retain-only and delete-conformer operations. XTC trajectories use bounded random-access storage and the desktop supplies reversible whole-molecule, no-jump, centering, and reference-fit views. No-jump access still walks from frame 1 to the requested frame, in the background with a Cancel button where the desktop expects it to take over a second. Orbitron now computes RMSD, RMSF, radius of gyration, saved distance/angle/dihedral series, contacts, interfaces, and hydrogen-bond occupancy through the CLI and its cancellable desktop analysis panel. Pairwise sequence alignment exists as the pairing step of structural superposition — global Needleman-Wunsch with affine gaps, or local Smith-Waterman for two structures that share only part of a sequence, selected with orbitron align --pairing sequence or --pairing sequence-local. Multiple-sequence alignment is not implemented.

Spectroscopy coverage is uneven. Interactive IR/Raman spectra and a UV-Vis excitation spectrum are available, each with broadening controls and CSV/PNG export — the latter from Gaussian TD-DFT, NWChem TDDFT, ORCA TD-DFT/TDA and EOM-CCSD, Molcas RASSI (spin-free and spin-orbit) and DIRAC relativistic response. A CP2K real-time propagation reaches the same spectrum by a different route — its dipole trace is transformed by orbitron analyze spectrum rather than read off a state list. NMR is not implemented, and cross-format vibrational coverage still varies with the data each parser extracts.

Crystallographic visualization is functional but basic. Orbitron identifies all 14 Bravais lattice types, renders unit cells, and exports band structures from VASP, Quantum ESPRESSO and CP2K runs and projected (“fat”) bands from VASP and Quantum ESPRESSO. Site- and orbital-resolved DOS comes from VASP, from CP2K’s .pdos files and from the projwfc.x files a Quantum ESPRESSO run has beside it, in the Periodic tab and in orbitron plot pdos. VESTA / CrystalMaker remain stronger for electron density visualization and publication-quality crystal renders.

Large-scene support has separate native and browser limits. Native static viewing is calibrated through one million atoms and two million explicit bonds on an M2 Ultra. Basic scene construction, picking, selection, and one edit/undo transaction were also measured through two million atoms. Larger native scenes are experimental: Orbitron estimates their memory and checks the selected GPU, but it has no level-of-detail renderer and makes no interaction-rate promise. Configured memory caps, integer-shape overflow, and a GPU unable to hold one render instance are hard refusals. A real one-million-atom bundle also opened under an 8 GiB Linux memory limit. On a physical 32 GiB M4 MacBook Air, the same bundle opened at 1,195,032,576 bytes maximum RSS with no swap and remained smooth while orbiting. Native presentation on a discrete GPU still needs a machine with an active graphical session; the RTX 4090 has only been measured through headless offscreen draw.

The browser has a fixed supported ceiling of 100,000 atom and 200,000 bond instances. It refuses larger scenes before constructing renderer data; there is no experimental above-cap browser mode. On the 32 GiB M4 MacBook Air, Chromium hardware WebGPU stayed near the display’s 144 Hz rate at both shipping caps: 100,000 atoms had a 6.94 ms median frame interval, and 100,000 atoms plus 200,000 bonds had a 6.93 ms median. SwiftShader software WebGL2 reached only 1.05 FPS and 0.39 FPS for those two cases, so Orbitron keeps one shared cap until it can identify renderer classes reliably. Source parsing and scene display are separate costs, and a small .orbpack file does not prove that its decoded scene is small. See Bundles §6.11 for the current source-memory estimates, measured renderer cases, and their exclusions.

Oxidation states are a convention, and wrong for about one complex in forty-six. The reported state is right for 97.8% of 64,104 named-state CSD complexes (the ionic model alone for 97.8% of the 64,098 it answers), less for radical and other redox-active ligands, which it recognises in eight classes only. Every site says how far to trust its state, and the ligand-field picture is a σ-only model of the pattern, not a spin-state prediction or a stabilization energy. For the lanthanides and actinides the state is right for 99.1% of 3,212 named-state CSD complexes and the grade is calibrated on them, but there is no f-orbital ligand-field picture (a free-ion ground term instead, approximate for an actinide). Organometallics are right less often: 95.7% of 26,658 d-block and 94.8% of 932 f-block ones, with a trust table of their own. Metal sites: accuracy and limits gives the numbers and what is declined.

Some formats are deliberately not read yet. GROMACS TPR (Orbitron has no typed force-field topology to put it in), TRR and TNG; AlphaFold and other structure-prediction output; and a CP2K run whose coordinates are in a CRD file, whose atom names only CP2K’s force-field tables resolve. Loop modelling, backbone insertion or deletion and building nonstandard residues are not implemented either.

The builder does not bridge metals. A ligand that names one donor for two metal sites is refused rather than built: a shared donor is a topology the stoichiometry leaves open, and Orbitron does not choose one silently.

SMILES and InChI have no coordination bond. A metal–donor bond is written into both as an ordinary single bond, InChI’s own convention, so a metal complex’s identifier counts its donors’ valence as if each were bonded covalently. The scene and an .orbpack keep the bond as dative.

No network access, by design. Orbitron reads local files only. It does not fetch structures from the PDB or any other database and has no remote file access; on an HPC system, run the CLI where the data is and copy the compact bundle back (Bundles).

Platforms, packaging and accessibility. Releases are built for Linux x86_64 (glibc 2.28 or newer), macOS on Apple Silicon and Windows x86_64. There is no Intel macOS or Linux aarch64 build (build from source there), the Windows executables are not code-signed, and the Python wheels are attached to each GitHub release rather than published on PyPI. The desktop viewer exposes nothing to screen readers, has no high-contrast mode, and scales its interface only with the operating system’s display scaling.

Rough edges. Orbitron is younger than most of its competitors; expect occasional UX friction in the GUI compared to tools with 20 years of polish. The CLI and Python API are generally more battle-tested than the desktop viewer.

If any of these gaps blocks your workflow, please open an issue describing the use case — they help prioritize roadmap items.