GFN2-xTB and CREST: browser implementation and performance evolution

Mol2Mat brings GFN2-xTB electronic calculations, ASE geometry optimization and CREST conformer searches into the browser. Revision 1 establishes numerical agreement with native calculations and measures concurrency scaling; Revision 2 measures the performance of complete tasks. On the same device and with the same sampling protocol, median times for ethanol, n-butane and n-hexane quick searches decrease by 27.3–45.5 % relative to Revision 1. The accompanying data retain individual timings, statistics and conformer outputs.

Dates and conditions of the two measurement rounds

Native and Revision 1 measurements were completed on 8 October 2026; Revision 2 was measured on 9 October. The three-version figure uses these historical references, while local optimizations have separate warmed, interleaved paired experiments. GFN2 single-point and ASE-optimization scaling remains the Revision 1 dataset; complete Revision 2 tasks cover ethanol, n-butane and n-hexane.

Scientific parameters and execution conditions

All runs use the same Apple M1 Pro (8 performance cores, 2 efficiency cores, 32 GiB RAM) and identical explicit-hydrogen coordinates prepared by browser RDKit ETKDGv3/MMFF94. GFN2 uses tblite 0.7.0 and original ASE 3.29.0, with gas-phase neutral closed-shell inputs, double precision, accuracy 1.0, 300 K electronic temperature and a 0.05 eV Å⁻¹ BFGS threshold. Every optimization converges before the 1000-step cap.

Each configuration has three repetitions; figures show medians and minimum-to-maximum ranges. Settings 1/2/4 and the additional 8/10 are run in separate batches with rotating within-batch order and sequential scientific jobs. Background services remain active and host load is recorded per run. Native GFN2 sets OpenMP/BLAS thread environments; browser setting 1 is the serial parent path, while 2/4/8/10 count orbital-pair child-pool concurrency.

Native and browser CREST calculations use matched versions and random sequences, retaining the complete quick stages, durations, precision and convergence criteria. Trajectory-state protocols are identified separately for native and browser calculations; speedups therefore use configurations with the same browser protocol as their baseline. Public records retain fixed coordinates, individual results and asset checksums.

GFN2 numerical agreement

Native tblite independently evaluates every browser single-point and optimization result at its full-precision final coordinates. Maximum differences are 1.124 × 10⁻⁷ Ha in energy (7.050 × 10⁻⁵ kcal mol⁻¹), 3.736 × 10⁻⁶ Ha bohr⁻¹ in gradient components, 1.823 × 10⁻⁹ e in charges and 7.631 × 10⁻⁹ D in dipole vectors. All four meet the established port-consistency criteria.

Original ASE BFGS optimization from identical starting coordinates produces matching convergence status and step counts in every native/browser pair. The maximum coordinate difference across recorded optimization frames is 7.500 × 10⁻⁵ Å. Agreement in energy, forces and optimization paths demonstrates retention of native numerical behavior for these molecules. Frames are recorded to six decimal places; final-property verification uses full-precision coordinates.

Single-point and geometry-optimization performance

Median browser single-Worker geometry-optimization compute times are 0.090 s for ethanol, 1.226 s for aspirin, 0.414 s for caffeine, 0.704 s for n-eicosane and 6.038 s for n-tetracontane. Original GFN2 and ASE computation is therefore in the subsecond-to-second range for the tested small molecules.

n-Tetracontane optimization took 5.475 s with a four-Worker pool, improving on the serial browser path by 9.3 %. Parallel work covers orbital-pair integrals; ASE control, SCC and matrix operations retain serial costs. Small tasks favour serial execution, while larger structures can benefit from moderate concurrency. The native single-threaded path was faster for this task set.

Concurrency scaling

Complete curves for settings 1, 2, 4, 8 and 10 show that optimal concurrency depends on task structure. n-Tetracontane optimization takes 5.626 and 5.563 s at 8 and 10, with 4 fastest on this machine. CREST’s multiple trajectories gain most at 8–10. Task-level parallelism offers greater scaling potential than parallelism within an individual electronic calculation.

Measured optimised geometries

Aspirin, caffeine and n-tetracontane represent a multifunctional aromatic molecule, a nitrogen heterocycle and a long-chain system. Browser execution of original ASE BFGS optimization converges in 56, 12 and 18 steps for these 21-, 24- and 122-atom structures. The models use measured final coordinates and retain energy, maximum force and optimization step counts.

Parallel complete CREST searches

Browser CREST distributes complete MTD/MD trajectories and optimization batches while retaining the iMTD-GC quick workflow: trial and production metadynamics, molecular dynamics, optimization, genetic crossing and CREGEN processing. Trajectories use independent electronic states and fixed random streams, with results joined in logical order at stage boundaries.

At concurrency 8, ethanol falls from 27.52 s to 6.77 s (4.07×), and n-butane from 70.18 s to 14.15 s (4.96×). At concurrency 10, n-hexane falls from 244.88 s to 44.98 s (5.44×). Times are medians of three repetitions and include complete search and result processing.

All 15 browser searches for each molecule produce byte-identical complete ensemble XYZ files, matching call counts and actual seed sequences. The 45 searches execute 690,735 search-stage GFN2 energy/gradient calls. Parallel gains result from concurrent execution of the same scientific work. The native control uses CREST 3.0.2, a matched random stream and one thread, retaining its SCC cache chain; every browser setting uses the same independent-trajectory protocol. Native timings provide implementation context; speedups compare browser concurrency settings.

Candidate ensembles and native recalculation

Browser searches yield 3, 2 and 26 CREGEN candidates for ethanol, n-butane and n-hexane. Minimum electronic energies differ from the native searches by 1.00 × 10⁻⁸, 2.80 × 10⁻⁷ and 2.70 × 10⁻⁷ Ha. Each spectrum is referenced to its runtime’s minimum and displays the complete candidate set.

All 31 browser candidates undergo independent native tblite evaluation at identical coordinates, with a maximum energy difference of 5.137 × 10⁻⁹ Ha and maximum forces no greater than 0.01781 eV Å⁻¹. Dynamic sampling is sensitive to electronic-state continuation and small numerical differences, producing different candidate sets across runtimes; the complete set remains identical across browser concurrency settings.

Resources and timing boundaries

Independent trajectory Workers each hold scientific runtime state, enabling multicore execution with an increased memory requirement. Chrome process-tree RSS for CREST at 8–10 is approximately 4.7–5.7 GiB, making available device memory relevant to concurrency selection. Browser values sum process-tree RSS sampled every 250 ms; native values are peak RSS for one process. Their accounting boundaries are retained separately.

Timing starts after engine assets are preloaded, with a fresh parent Worker and child pool for each run. GFN2 compute time includes ASE, electronic properties and initial child-pool startup; whole-task time adds RDKit and parent-module preparation. Initialization is recorded separately, with 169.3 MiB of deduplicated preloaded assets. CSV records also retain CPU seconds, memory and host load.

Conditions for version comparison

Both versions use the same scientific parameters, random sequences, numerical precision and result-comparison criteria. Complete tasks include conformer search, result validation and property recalculation for final conformers. Individual measurements retain version and environment identities.

Complete-task comparison across three versions

The comparison uses the native single-threaded path and both browser revisions with ten child Workers. Each group has $n=3$, shown as the median and minimum–maximum range. Native and Revision 1 records are dated 8 October; Revision 2 records are dated 9 October. R2 medians for ethanol, n-butane and n-hexane are 4.99, 8.76 and 24.53 s, reductions of 27.3 %, 40.2 % and 45.5 % from R1.

R1/R2 median-time ratios are 1.38, 1.67 and 1.83; native/R2 ratios are 1.58, 2.40 and 2.81. The browser revisions share a task boundary and sampling protocol. The native reference reports complete wall time for its own execution path.

Native timing covers process startup through complete search-file output. Browser timing begins after resources and the parent Worker are ready, covering search, result validation and property recalculation for up to ten conformers. Native execution uses an SCC state-cache chain; the browser uses independent trajectories initialized at stage entry. [8, 3, 4] Each implementation’s candidate set is retained as produced.

These timing ratios are sample statistics for the stated device, versions and three inputs. Each range describes the spread of three observations. Estimating performance across devices or statistical confidence intervals requires a separate repeated-measurement design with fixed task boundaries.

Subtask performance comparisons

Captured n-hexane molecular-dynamics and conformer-optimization tasks are measured in interleaved order after warm-up in a single Node instance. Each of three versions has two MD and eight optimization measurements. The final version reduces median times by approximately 11.7 % and 9.0 % relative to baseline, with bitwise-identical numerical results and electronic states. Subtasks and complete searches retain their respective timing boundaries.

Numerical and execution verification

All nine full browser tasks terminated normally. Starting geometries, complete conformer XYZ files, random-seed sequences, E/G evaluation counts, and full-precision retained coordinates and electronic properties matched the corresponding Revision 1 results. The E/G counts remained 10,593, 13,071 and 22,385 for ethanol, n-butane and n-hexane, respectively. Same-coordinate native validation retained the Revision 1 candidate-conformer evidence and confirmed that the new results matched the corresponding coordinates, energies and properties.

Local integral validation covered 25 shell-pair combinations from s through g for both values and gradients. Maximum absolute differences were $2.78\times 10^{-16}$ and $7.77\times 10^{-16}$, respectively, below the $10^{-12}$ component tolerance. Butane, hexane and caffeine were also used to validate cold starts, state reuse, geometry updates, property requests and electronic-state restoration, covering seven phases per system. Caffeine served as a kernel numerical control; the CREST parallel measurements remained limited to the three benchmark systems.

Execution records bind the measured kernel, task assets and numerical controls. Task lifecycle handling is described in the shared execution section.

Each calculation retains its inputs, version, execution configuration and results, supporting progress viewing, cancellation, saving and recovery. Performance comparisons report warmed short tasks, complete searches in fresh computation instances, single-instance subtasks and native processes separately.

Task time includes numerical computation, progress handling and result delivery. Each article specifies initialization boundaries, inputs, repetitions and output agreement. Reproduction uses the same timing entry points and stopping conditions.

Public Revision 1 records contain 354 executions; Revision 2 contains nine complete tasks and 18 native/R1 references. Per-revision raw-results.json.gzip and summary.csv files, candidate recalculations and provenance records support reproduction of timing summaries and saved-output comparisons. Runs are grouped by molecule, version, concurrency and repetition, with the documented initialization or warmup intervals excluded, to recompute medians, minima, maxima and R1/R2 timing ratios.

Calculations can be repeated with the recorded explicit-hydrogen coordinates, GFN2/ASE/CREST versions, quick protocol, random streams and numerical settings. Performance reproduction also fixes hardware, thread/Worker settings and timing boundaries. Subsequent work is reported in the GFN2/CREST caffeine study.