atomic

atomic Devlog #5: breaking physics on purpose, then adding real atoms
Two big landings since last time: the What-If labs (altered constants, custom force laws, classical ghosts) and screened multi-electron atoms all the way from engine to UI. 359 tests green.
You can now break the laws of physics
Five sliders over the raw constants of nature — double the electron charge, quadruple vacuum permittivity, watch alpha, the Bohr radius and binding energy refuse to move. That degeneracy is the whole lesson: only dimensionless combinations are observable. Next to it, force-law presets (power law, Yukawa, harmonic, finite well, Coulomb-plus-core) plus a type-your-own V(r) box with a whitelist parser and a trust gate that flags unconverged levels instead of silently serving them. And the classical ghost: what Newton predicts for hydrogen, a spiral into the nucleus in picoseconds, which quantum mechanics forbids. That refusal is the point.
Real multi-electron atoms
GSZ screened model with honest transcribed parameters for 15 elements, self-consistent-solver-free but validated against ionization data. Monte-Carlo cloud sampling with KS-tested distributions, y=0 plane cross-sections, screened levels and radial endpoints on the API, atom picker entries and an occupancy ladder in the UI. Sulfur and chlorine get a named refusal instead of invented numbers — no fitted parameters exist for them, so the server says exactly that.

atomic Devlog #3: solver, server, and the web instrument
Three phases landed since last time: the numerical solver, the FastAPI backend, and the React + Three.js frontend. 193 backend tests and 48 frontend tests green, everything pushed.
Change 1: numerical radial solver
Built a 3-point finite-difference solver for arbitrary central potentials, plus a grid-halving error estimator. Validated against the exact hydrogen answers: energies match, 1s overlap > 0.99999, convergence measures exactly 2.00 across all cases. Two of my own test assertions were wrong along the way (forgot reduced mass in the expected energy, grid too coarse for the normalization check) — the engine was right both times.
Change 2: FastAPI backend
atomic serve now runs a real server: health, systems, state, levels, radial endpoints, plus background jobs (cloud sampling, plane cross-sections) with websocket progress and binary data channels. Sampling is honest inverse-transform Monte Carlo of |psi|². Also fixed a URL-encoding bug where the he+ key decoded as “he “ and got refused everywhere — verified against the live server.
Change 3: web instrument
Full frontend: orbitable 3D point clouds with density/phase coloring, y=0 plane canvas views, clickable energy ladders, radial R/P plots with node marks and mean-radius markers, shareable URLs for every state, zustand store underneath. Production build splits Three.js into a lazy chunk; the server mounts the built UI directly.

atomic Devlog #2: exact hydrogen engine + systems registry
I had two goals in my mind in this session. One was to build the exact hydrogen-like physics engine and the other is to add a systems registry plus the element tables. Here is what and how I implemented this stuff and the challenges i faced:
Change/Problem 1:
Before I even got started on the new stuff i wanted to add, i faced a big problem. The moment i wired the new physics into last session’s spine, 4 tests instantly failed. My Field type (the container every array result travels in) demanded its grid be strictly increasing, but wavefunction sampling evaluates on scattered, unsorted points, so every single evaluation got rejected with a ValueError.
The fix:
It is important to know what a Field actually is here. It’s not a mesh — it’s just samples of a function on a set of points, plus the provenance saying how they were computed. Sorted-ness is a quadrature concern and belongs to the mesh module, not the container. So i dropped just the ordering rule and kept the finite/shape guards, then added a regression test pinning the decision so nobody re-adds it later and silently breaks everything again.
Change 2: hydrogen engine implementation
I implemented the exact closed-form hydrogen-like solutions, all in Hartree atomic units. The energy is E_n = −mu_ratio · Z² / (2n²), and the trick that makes it powerful is the reduced-mass ratio mu/m_e sitting right in the formula — deuterium, tritium, muonic hydrogen and positronium all fall out of the same code just by changing that one number. The radial functions use the normalized generalized-Laguerre form R_nl = N · exp(−ρ/2) · ρ^l · L(ρ) with ρ = 2Zμ′r/n, and mean radii come from = (3n² − l(l+1)) / (2Zμ′). I checked the 1s case by hand: = 1.5 bohr, exactly like the textbooks say.
Change 3: angular bases + systems + proof
I implemented both angular bases as first-class outputs: complex spherical harmonics (with the Condon-Shortley phase, so Y_1^1 has a negative real part at phi=0) and real chemistry orbitals (p_x, p_y, d_xy and friends with proper orientation). On top of that sits the systems registry — H, D, T, muonic hydrogen, positronium, He+, plus a generic hydrogen_like(Z) — each carrying CODATA-cited reduced masses and honest nuclear radii (positronium gets None instead of a fake zero, because its “nucleus” is a point positron).
The last batch of work was the proof: 139 tests green. Normalization, orthogonality, node counts coming out as exactly n−l−1 every time, angular orthonormality up to l=3 in both bases. Nothing’s shipped anywhere yet though — next is Phase 2, the numerical solver, validated against these exact answers. That’s the first real solver-vs-truth showdown.

atomic Devlog #1: foundation is done, the atom has a spine
i just kick started a new project called atomic, and the aim is kinda crazy: a quantum-mechanical atom model that never quietly lies about its physics. every number that crosses a module boundary carries a record of how it was computed and how far it can be trusted, with tiers going from EXACT (closed-form) all the way to COUNTERFACTUAL (deliberately altered physics, computed rigorously). i’ve got the whole thing mapped out as a 15-phase plan. today was all about Phase 0: the foundation. no physics yet, just the spine everything else will stand on.
Change 1: environment setup (this fought me)
my machine had no conda, no pip, no uv, nothing. just bare python 3.14. i almost gave up and then found out python ships with ensurepip, so i bootstrapped a venv with python3 -m venv .venv and pip-installed numpy, scipy, pytest and ruff into it. worked first try after that. lesson learned: check ensurepip before panicking.
Change 2: the provenance spine + constants + mesh
i scaffolded the actual package: provenance.py (the fidelity tiers plus the Quantity and Field types that carry them), constants.py (CODATA values with a counterfactual-universe hook for the future What-If lab, where you’ll be able to mess with constants like e and watch what breaks), and numerics/mesh.py (uniform + exponential radial meshes with a ghost-node fix at the inner wall, since an exponential mesh can’t reach the origin). getting the discretization right now means every solver later stands on solid ground.
Change 3: evidence-style tests, all green
i wrote 34 tests and they all pass in 0.2 seconds. they’re written as evidence, not coverage: solver checks against the exact hydrogen ground state, mesh guards that refuse bad inputs, constants checked against published CODATA values. the idea is that if i ever break the physics, CI screams at me immediately.