Validation & benchmarks
Current release: v1.1.7
The benchmarks below include source-candidate and historical measurements. Each result applies to its stated version, artifact, host, and corpus.
chematic is an open-source, Rust-native cheminformatics engine (MIT OR Apache-2.0) covering SMILES/SMARTS parsing, molecular descriptors, fingerprints, and 2D depiction. This page summarizes how its output is checked against RDKit, what is stable versus experimental, and what its benchmark numbers do and do not mean. Full methodology, corpora, and reproduction steps live in the chematic repository — this page is a summary with sources, not a replacement for it.
Why choose chematic
chematic is built for software that needs molecular operations in the browser, in a Rust application, and in Python without creating a different chemistry layer for each environment. It is a particularly strong starting point for local-first browser tools, native Rust services, and product features that need to share one engine.
What you gain by starting with chematic
- Local browser execution: parsing, descriptors, fingerprints, 2D depiction, and search can run in WebAssembly without sending the molecule to a backend.
- One Rust core: Python, Rust, JavaScript/WASM, and local MCP tools are built around the same engine, so prototypes and production surfaces can stay aligned.
- Direct integration: the standard core workflow is Pure Rust and does not require a C++ toolchain, subprocess, or separate chemistry service.
- Visible boundaries: published packages, named corpora, and known limits are linked below so teams can evaluate the operations they actually intend to ship.
Start with the browser demo or a SMILES validation tutorial. If you have existing RDKit assets, introduce chematic at a browser feature, a new Rust service, or an independent analysis step, then check the required operations on your own corpus.
Feature maturity
| Feature | Status | Notes |
|---|---|---|
| SMILES / SMARTS parsing | stable | — |
| Molecular descriptors (physicochemical core) | stable | — |
| Fingerprints (ECFP, MACCS, etc.) | stable | — |
| 3D conformer generation (distance geometry + MMFF94) | experimental | — |
| pKa / ADMET profiling | experimental | Rule-based screening heuristics, not validated for clinical use. |
| IUPAC name generation | partial | Covers 25+ structural classes; returns empty string outside supported scope. |
| InChI (default pure-Rust engine) | approximate | — |
| InChI (optional native-inchi feature) | stable | Bit-exact standard InChI via the vendored IUPAC C reference implementation. |
What published packages have verified
These records used published artifacts, not a local checkout. An output gate and a timing result for named operations do not establish compatibility or speed for the rest of either library.
| Artifact and comparison | What passed | Boundary |
|---|---|---|
| v1.0.42 CPython 3.13 wheels vs RDKit 2026.09.1 | TPSA, Labute ASA, and chiral Morgan passed 10,000-row output gates. Parse-inclusive 21-block intervals favored chematic on hosted Linux x64 and macOS arm64. | Ring count was 9,994/10,000; prepared Labute ASA lost on macOS, and prepared Morgan crossed parity. |
| v1.0.30 browser package vs official RDKit.js | Morgan outputs matched on 250/250 direct and prepared rows in Chromium, Firefox, and WebKit. The 20-block timing intervals favored chematic in that test. | A separate 10,000-row Chromium run had one typed refusal for iron; this is a Morgan result, not a browser-wide performance claim. |
| v1.0.42 reaction package vs RDKit | 80 of 83 rows had the same graph, atom origins, and atom maps; the other three were mutually invalid. | Reaction support still has residual differences and is not full RDKit reaction compatibility. |
Current-source comparison, not a release claim
Evidence boundary: The current-main records below were built from source against RDKit 2026.09.1. They track development, but they are not evidence for published v1.1.7 packages until those artifacts are rerun.
In the current-main packet, TPSA, Labute ASA, ring count, and chiral Morgan agreed on 10,000 rows. Their parse-inclusive pipelines had favorable intervals in one macOS arm64 run. In the v1.1.3 source candidate, molecular weight, Morgan, and ring count also agreed on 4,072 unusual SMILES; ten CIP differences were classified rather than hidden. These are named test lanes, not a claim that chematic implements the full RDKit surface.
The current release adds charged EEM partial charges, allene and cumulene axial stereochemistry, an opt-in ETKDGv3 path, V3000 enhanced-stereo collections, bounded-memory SDF datasets, and reusable Python force-field objects. Release-wide comparison reruns for those v1.1.7 artifacts are still pending.
Descriptors, stereochemistry, and 3D
Mol.descriptors() returns 194 values, but that number is an API count, not an accuracy score. Validate the descriptor and corpus you intend to use. The published records above cover TPSA and Labute ASA; they do not validate every extended descriptor family.
A published Python audit recorded 200 differing SMARTS cells out of 310,000 and five CIP abstentions. Chematic reports those boundaries rather than guessing. For 3D, v1.0.42 passed 265 geometry, stereochemistry, and clash checks in its published gates; a current-source equal-count comparison placed 258 of 265 conformers within 1 kcal/mol of RDKit. 3D remains experimental and RDKit remains the broader, more established option for production 3D workflows.
Known limitations
Canonical SMILES is not a universal identity key
Use an explicitly documented identity mode for deduplication or caching. Canonicalization has defined scope and fail-closed limits; it is not a substitute for a universal structure identifier.
Source: docs/rdkit-comparison.md