You are browsing as a guest. Sign up (or log in) to start making projects!

yaasshh

@yaasshh

Joined June 1st, 2026

  • 20Devlogs
  • 8Projects
  • 3Ships
  • 58Votes
Open comments for this post

8h 36m 35s logged

Devlog #2

Two things this stretch, and both started as “that’s odd” rather than “that’s broken.”

First, the solver was crawling. Every step up in voltage cost more than the last, and past a point it just gave up. I traced it back to the starting guess, which was asking what makes glass electrically neutral. That question has no answer, because glass has no charges to balance in the first place. The solver was grinding away at something stupid before it ever got to the real problem. I gave it a proper starting answer instead, and the slowdown disappeared entirely.

Second, I stopped trusting my tests and went to check them. I broke my own code ten different ways on purpose, one at a time, and watched to see which breakages the suite would catch. 9/10 failed, which is what I wanted. 1 slipped through clean, and that is the interesting one, because a test that cannot fail is not a test.

Chasing the one that got away turned up a real bug hiding underneath it. Setting the voltage on the bottom contact was silently doing nothing at all. The code ran, reported success, and ignored the value. One line to fix, and it would have been very hard to find any other way, since nothing about the output looked wrong.

Heads up! Light AI usage to debug the tests and break code to find errors

0
0
34
Open comments for this post

10h 22m 57s logged

This is a 6-key macropad arranged in a 2x3 matrix, with a rotary encoder for analog-style control and a 0.91” OLED for live feedback. It is built on a custom PCB, with the Seeeduino XIAO RP2040 socketed on top. It runs QMK, so every key, layer, and encoder action is fully remappable, and you get access to the entire QMK feature set (layers, tap-dance, macros, combos.The whole thing is housed in a 3D printed case designed to hold the PCB, switches, encoder, OLED, and XIAO board in place.

Features

  • 6 mechanical switches wired in a 2x3 matrix
    Rotary encoder with push-button.
  • 0.91” OLED display for layer and status readout
    Seeeduino XIAO RP2040 microcontroller.
  • Runs QMK firmware with full layer and macro support.
  • Custom designed PCB with socketed XIAO RP20403D printed three-part case.
0
0
7
Ship

AtomSim is a website I built that lets you actually see what an atom looks like.

You pick an element, or hydrogen, and pick which electron shell you want to look at. Then it draws it. Not a cartoon of dots going around a circle like the diagrams in school, the real shape, the cloud where the electron actually is. Some of them look like spheres, some look like dumbbells, some look like weird four leaf clovers. All of that is real, it just falls out of the math.

You can spin it around, slice it in half, look at it as a graph instead, or look at the colored lines of light the atom gives off when it gets hot. That last one is how we know what stars are made of, and you can watch it happen.

The part I care about most is that it never fakes anything. Every single number on the screen carries a label saying how it was made. Some are exact, straight from the equations. Some are computed numerically with an error bar attached. Some are approximations, and it says which physical effects it left out. And a few are deliberate “what if” experiments, like turning off the rule that stops two electrons sitting in the same place, just to see the atom collapse. Those are labeled too.

So if a picture is pretty rather than true, the app tells you. I wanted something a curious fifteen year old could poke at for an hour and come away with a correct picture in their head, not a comfortable wrong one.

It runs in a browser, works on a phone, and every view has its own link you can share.

PS: It also has mobile view now!

  • 2 devlogs
  • 12h
  • 13.80x multiplier
  • 163 Stardust
Try project → See source code →
Open comments for this post

5h 0m 53s logged

DEVLOG : 7?

Since that last update, the cleanup turned into actual features.

I finished the frontend narrator pass. Every disclosure string, every physics note, every view intro is now plain prose instead of the app talking about itself in first person.

Then I went after the parts of the app that were just annoying to use.

Plots are zoomable now. Wheel to zoom, drag to pan, on all five analytic views. I also built a small notation layer so the ASCII the engine emits gets typeset properly at render time, subscripts and superscripts where they belong, without dragging in a whole math library.

The big one was mobile. The app used to just refuse to render below a certain width. Now it works down to 320px: a proper mobile shell, view tabs instead of a sidebar list, controls that collapse, and per-view width floors so nothing spills sideways. That took a lot of small fixes I did not expect, a fixed SVG viewBox that hid fixed-width text, and an overflow rule that was already scrolling the page sideways before I touched anything.

After that, the URL got a real history. Back and Forward actually work now, and moving between orbitals pushes a history entry while flipping a display toggle just replaces one. Added a copy-link button and keyboard shortcuts for stepping through n, l, m and switching views.

Last thing, the title is now just AtomSim. The tagline was doing nothing for anyone.

0
0
20
Open comments for this post

6h 49m 37s logged

Devlog #5 or 6???

Since the site went live, most of the work has been cleanup rather than new physics.

The whole app used to talk in first person. Every explanation said “I compute this” or “what I’m showing you.” It read like the code was narrating itself, which was odd. So I went through the entire Python engine module by module and rewrote it in plain technical prose. That’s done.

Then I started on the frontend, which had way more of it. The disclosure text, the physics notes under each equation, the view intros. That’s still in progress.

there were 2 things I had to be extra careful about. Some of those strings are checked word-for-word by tests, so rewording one has potential to break complete the build by itself.

In addition, I also tidied the repo layout for public viewing, fixed a deploy pipeline failure, and added privacy-safe visitor counting.

Right now i’m cutting padding, and pitching it so a high schooler can follow it without boring a physics grad.

0
0
20
Open comments for this post

40m 21s logged

Devlog #2

I think everything is ready to ship. I changed up a lot of things but i couldn’t record around 3 hours of it but that’s alright cause there were some recent hackatime issues.

Changed up the CAD and the whole BOM. I also added a 0-36V buck-boost converter for a variable voltage/current supply which I am pretty sure will be incredibly helpful with my bionic projects

0
0
12
Open comments for this post

7h 56m 44s logged

Devlog #1

Sourcing the CAD Files & Building the BOM

This stage was mostly about getting the physical side of RePSU figured out before moving further into the build.

I started by sourcing the CAD files for the enclosure and checking the different views to understand how everything would fit together. Having the enclosure laid out made it much easier to plan where the displays, banana sockets, buttons and other components would go.

Once the enclosure was taking shape, I started putting together the Bill of Materials (BOM). I went through each component needed for the build, recorded the quantity, found suitable parts, and added the approximate prices and purchase links. The current BOM includes the displays, banana sockets, fuses, buttons, fans, MOSFETs, and the 85W USB charger.

The estimated cost is around $35 USD, excluding the original ATX PSU and miscellaneous hardware.

This gives me a much clearer idea of what I actually need to source before starting the physical assembly.

0
0
18
Open comments for this post

9h 26m 46s logged

DDSim Devlog

I’m building a chip simulator from scratch. Today I got it to simulate a MOS capacitor, a silicon slab with a thin glass layer and a metal plate on top. It’s the heart of every transistor ever made.

What I built:

I stacked two grids together: a fine one near the silicon surface where all the action is, and a coarse one for the glass where nothing happens. Then I wrote one function that builds the whole sandwich.

I wrote every test before the code. This kind of maths loves to give you wrong answers that look perfectly reasonable, so I only trust it when it matches something I can work out on paper.

I’m happy that the “flatband” voltage came out exact to 15 decimal places. The threshold voltage matched the textbook to 0.13 millivolts, 50 times better than I needed.

I also identified a few problems; the solver was getting slower and slower at high voltage, then giving up. The starting guess was asking “what makes glass electrically neutral?”, a meaningless question, since glass has no charges. I gave it a proper answer instead and the slowdown vanished completely.

Then I deliberately broke my own code ten ways to check the tests would catch it. Nine got caught. One didn’t. Chasing that turned up a real bug: the bottom-contact voltage setting was silently doing nothing. One line to fix.

Current Position: 1339 tests passing, everything clean, C-V curve working across all three regimes.

0
0
39
Open comments for this post

6h 58m 23s logged

Decided to build my own custom RP2040 board to learn hardware design. The RP2040 is awesome for this because it has incredible documentation.

I started by blocking out the schematic into logical chunks. The power supply needs to deliver both 3.3V and 1.1V, so I used an MCP1700 regulator and stacked up a dense bank of 0.1uF and 1uF decoupling capacitors to keep the power rails stable. For storage, I connected a 128Mb flash chip. I also integrated a USB-C connector and wired up a standard 12MHz crystal oscillator circuit to handle the clocking.

Moving from the schematic to the layout sort of tricky but we got there.

Hopefully everything runs

0
0
6
Ship

PartSourcer

Find the cheapest in-stock part for your PCB in one search.

Live at “part-sourcer.vercel.app”

Search any electronic component and get its stock, price, footprint and datasheet in one place. Every number is stamped with the moment it was read, so you always know how new it is.

The useful bit: for a part you searched, it looks for one cheaper drop-in that is actually in stock, and tells you why it counts as a match. Same package, matching specs, real stock, and both prices re-read the same way before any saving gets claimed. If it cannot find a genuine match, it elaborates so.

Right now that works for resistors and capacitors. Everything else gets an “no match found”. (Perhaps later implementation)

Rules it sticks to:

  • No made-up stock or prices. If the data is stale, you get an error, not a number pretending to be fresh.
  • A part with no published price says “no price”, never $0.00. A zero would read as free and win every comparison.
  • Missing fields are left out rather than filled with a placeholder.

Built with FastAPI and React, both on Vercel, with Postgres behind the price history. Part data comes from Mouser in real time, plus an open snapshot of the LCSC catalogue that refreshes about once a day. There is a DigiKey adapter too, and it switches on once credentials are set.

Free, open source, no login, no paywall. MIT licensed.

  • 4 devlogs
  • 29h
  • 18.84x multiplier
  • 515 Stardust
Try project → See source code →
Open comments for this post

1h 0m 50s logged

Dev log #5??

Ran a 20-item polish checklist over the site. Ten things were already fine: links all work, buttons all do something, the 404 page is real, errors show up properly.

Six items from the checklist were missing, so I built them.

Fixed the page titles. Every page was showing the same title because nothing reloads in a single-page app. Now a part page names the part, a search names what you searched.

Put a year in the footer, read live so it never goes stale. Dropped the “404 demo” link, that was a leftover dev thing sitting next to real links.

Then two actual bugs I only found by measuring in a browser at phone size. The home page really was scrolling sideways: a card grid was asking for 400px inside a 319px space. About had the same thing at 340px. Fixed both.

The header was the other one. It needed 390px of room for the logo and five links on a 375px phone. It had been wrapping onto three rows and leaving Contact stranded alone. Now the links tuck behind a menu button below 640px. Header went from 281px tall to 69px.

Last thing: the pages were too narrow and floated in empty space. Widened them a lot, 1600px for the main shell and 1400px for the text pages. Width alone would’ve just made long ugly lines, so the card grids reshaped too. FAQ goes two across, the three how-it-works steps share a row, the four-card grids go four across and step down cleanly.

Plus a few more minor changes, The project is built enough to be shipped!

0
0
11
Open comments for this post

7h 3m 2s logged

Dev log #3 or #4??

After the site went multi-distributor, I kept going.

I added a contact page with my email, Instagram and GitHub, dropped GitHub out of the header, gave the footer real columns with links that work, moved the data source note over to the About page and wrote more there. The front page got more to read too, and the About cards now sit in a clean 2x2 grid.

Then I did a proper security pass. I added a middleware that stamps security headers on every API response, including CSP, frame options and HSTS. Wrote a rate limiter that reads the client IP from headers the platform actually writes, never the one a caller can fake, and capped its key table so the limiter itself cannot be turned into the attack. Added input caps: query at 200 characters, page at 50, part key at 128, all refused early so nobody can burn my distributor quota. Added a body size ceiling and tightened CORS.

The static site got its own CSP through vercel.json, checked against the real built bundle.

I also wrote guard tests: they fail if a stray .env gets committed, if a credential literal shows up in source, if SQL starts joining values instead of using placeholders, or if a Set-Cookie ever appears. Then I documented the whole posture in the backend README, including what I deliberately left out and why.

0
0
14
Open comments for this post

11h 28m 32s logged

PartSourcer devlog #2

Started with a simple annoyance: finding a part that is actually in stock means opening six distributor tabs per line of a BOM. Wrote a throwaway script to poke at the free jlcsearch API and see what the data really looked like. Turned out it has no brand and no datasheet. Decided early to show that as blank rather than show wrong results.

Also built the backend. FastAPI, a swappable data source so the real LCSC API can drop in later.

Also tweaked the frontend a bit. React, inline styles, a loud yellow-and-black look. Then deploy configs, and the site went live on Render.

Implemented a price history recorder, so the data is there later even if nothing reads it yet.

The big addition. The site finally became multi-distributor: Mouser and DigiKey alongside LCSC. Every part now carries a list of offers, one per distributor, and a per-source status so a partial failure shows as a partial answer rather than an error.

0
0
10
Ship

Atom Sim is a browser app that solves atoms from scratch and shows you the result. Hydrogen comes out of closed-form math, real atoms like carbon and argon come out of a Hartree-Fock solver I wrote, and you can look at any of them as a 3D electron cloud, a 2D slice, a radial plot, an energy-level diagram or an emission spectrum. You can also break physics on purpose: switch off the Pauli exclusion principle, switch off electron exchange, or type in your own potential V(r) and see what kind of atom falls out.

The rule I built everything around is that the model never quietly lies. Every number carries a tag saying how it was made: exact, numerical, approximation, counterfactual, or just a visual choice. That tag follows the number from the solver all the way to the label on screen.

What was challenging

Hartree-Fock was brutal. The angular coefficients in the Fock operator are easy to get slightly wrong, and when you do, the solver still converges and hands you smooth, beautiful, completely wrong orbitals. Nothing crashes, nothing warns you. I had to re-derive the algebra instead of nudging numbers until a benchmark matched.

Error bars were the other trap. Mine looked great for a while and were simply lying, because the real error was coming from the box size, not the grid spacing I was measuring. Argon also took about an hour on a uniform grid until I moved to an exponential mesh, which cut it to seconds.

What I’m proud of

That it’s honest. Plenty of simulators draw a pretty orbital and say nothing about where it came from. Mine tells you, and the tests enforce it. The spectra are checked against real NIST data inside the test suite, so a physics regression fails CI rather than shipping quietly.

How to test it

It’s live at https://atomsim.fly.dev. The server sleeps when nobody is using it, so the very first load can take around 15 seconds. After that it’s quick.

Good things to try: pick n=3, l=1 and rotate the cloud, then flip to Plane view for the cross-section. Switch the element to argon. Open a guided tour if you want the short version. Every view is a shareable URL, so you can link someone to an exact state.

  • 4 devlogs
  • 58h
  • 18.43x multiplier
  • 684 Stardust
Try project → See source code →
Open comments for this post

7h 16m 22s logged

Devlog: Phase 30 to now

Phase 30, Instrument frontend. Redesigned the UI to read like a physics instrument. Bundled the fonts, dropped four fields nothing actually measured, and learned that text-transform: uppercase turns 3d into 3D and α² into A², so uppercase is now confined to section headings only.

Phase 31, Guided tours. Added walkthroughs that drive the app for you. Nearly shipped a tour that quoted the wrong hydrogen energy because it skipped reduced mass, and fixed two spotlight rings that measured their target before layout settled.

Absorption band cleanup. Abutting sub-pixel SVG rects were drawing lines that weren’t in the data. Settled the mean vs deepest-per-column question and fixed decade ticks that failed at both ends of the axis.

Housekeeping. Moved specs and plans out to docs/specs and docs/plans. Personal ignores went into .git/info/exclude so no tracked file carries tooling names.

Rate limiting. Sized the burst from the app’s real fan-out per action rather than from click counts. The n=6 row plus an auto-refetch was quietly doubling the load.

Web hosting. Containerized and deployed to Fly.io as a single process. Cold start from a snapshot is about 1.6s, occasionally up to 22s if the snapshot gets discarded. Argon solves in 2.8s on the deployed box against 1.4s locally. Suspended machines cost nothing, so occasional use stays near a dollar or two a month.

Also added rate-limiter logging that identifies refused clients, and confirmed the proxy overwrites forged IP headers, so spoofing doesn’t get you past the limit.

0
0
13
Open comments for this post
Reposted by @yaasshh

10h 51m 46s logged

DevLog #3: New Frontend, Plus Small Bits

Phase 22 to now.

P22, distinguishable electrons. Turned off exchange in Hartree-Fock. Electrons still repel, they just stop being identical. Marked COUNTERFACTUAL. Helium came back exactly zero, so it was gone.

P24, Pauli off. Dropped the occupancy cap and everything falls into the 1s. Argon becomes 1s^18 and the periodic table stops existing. P22’s slow convergence was shells, not exchange.

P25, isosurfaces. Never size a box on the grid you draw on. The fraction error bar is blind to the box. A 90% p orbital is one piece, not two lobes.

P26, HF in 3D. Now in Cloud, Plane, Radial and Surface. Whole-atom and one-orbital radii move opposite ways. Fidelity tiers were literals under the solve.

P27, total density. Added D(r), the shape both models describe. A uniform grid steps over the 1s peak, so the test asserts convergence rate, not tolerance.

P28, screened density. GSZ gets its own D(r). A density needs its own box. A log axis quietly breaks area = electron count.

P29, comparison. Both models on one axis, gap measured. Caught a noise floor, a real number printing as zero, and a wrong caption.

Sulfur, chlorine. Split ATOM_KEYS into identity and capability. Derive flags, never pass them. A client check exposed a deep-link race.

P30, instrument frontend. Fonts bundled for offline. –edge is a border colour, never a fill. Dropped four fields with no engine behind them. Uppercase turned 3d into 3D, so headings only now.

Plot polish. Zoomed line profile labels offsets from window centre, since absolute wavelengths printed the same string six times. Drew xyz axes through the cloud.

Absorption, curve of growth. Stopped a zero equivalent width stretching the axis 300 decades. The band drew anti-aliasing seams as absorption lines where transmission was really 0.98 to 1.00. It now bins one column per unit and draws the deepest sample, beside what a real detector pixel would see.

0
1
18
Open comments for this post

10h 51m 46s logged

DevLog #3: New Frontend, Plus Small Bits

Phase 22 to now.

P22, distinguishable electrons. Turned off exchange in Hartree-Fock. Electrons still repel, they just stop being identical. Marked COUNTERFACTUAL. Helium came back exactly zero, so it was gone.

P24, Pauli off. Dropped the occupancy cap and everything falls into the 1s. Argon becomes 1s^18 and the periodic table stops existing. P22’s slow convergence was shells, not exchange.

P25, isosurfaces. Never size a box on the grid you draw on. The fraction error bar is blind to the box. A 90% p orbital is one piece, not two lobes.

P26, HF in 3D. Now in Cloud, Plane, Radial and Surface. Whole-atom and one-orbital radii move opposite ways. Fidelity tiers were literals under the solve.

P27, total density. Added D(r), the shape both models describe. A uniform grid steps over the 1s peak, so the test asserts convergence rate, not tolerance.

P28, screened density. GSZ gets its own D(r). A density needs its own box. A log axis quietly breaks area = electron count.

P29, comparison. Both models on one axis, gap measured. Caught a noise floor, a real number printing as zero, and a wrong caption.

Sulfur, chlorine. Split ATOM_KEYS into identity and capability. Derive flags, never pass them. A client check exposed a deep-link race.

P30, instrument frontend. Fonts bundled for offline. –edge is a border colour, never a fill. Dropped four fields with no engine behind them. Uppercase turned 3d into 3D, so headings only now.

Plot polish. Zoomed line profile labels offsets from window centre, since absolute wavelengths printed the same string six times. Drew xyz axes through the cloud.

Absorption, curve of growth. Stopped a zero equivalent width stretching the axis 300 decades. The band drew anti-aliasing seams as absorption lines where transmission was really 0.98 to 1.00. It now bins one column per unit and draws the deepest sample, beside what a real detector pixel would see.

0
1
18
Open comments for this post

11h 56m 25s logged

DevLog: Phase 18 to now

P18, line shapes. Real lines are not infinitely thin spikes. Atoms move (Doppler) and get jostled by neighbours (pressure), so each line spreads into a bell shape, a Voigt profile. I added that, plus a zoom so you can look at one line up close. The useful trick was a flux-closure check: whatever area a line has before broadening, it has to still have after. That caught two grid bugs that were invisible on screen.

P19, optical depth. Until now every line acted as if light escaped freely. In a thick gas strong lines saturate, so doubling the atoms stops doubling the brightness. That is the curve of growth. Lesson: decide which regime a line sits in from the physics, not by eyeballing the slope. Also the wavelength window has to widen as the column thickens, or you clip the wings you are trying to measure.

P20, absorption. The mirror of emission. Shine a continuum through the gas, look at what is missing. The trap was that 14 hydrogen lines land on only 6 distinct wavelengths, so matching a profile to its source line by wavelength quietly pairs the wrong ones. I key on the transition instead.

P21, Hartree-Fock. The big one. Instead of a fitted screening formula, each electron feels a potential built from all the others, solved over and over until it stops changing. That gets me sulfur and chlorine, which the old model could not touch, plus ions with no preset. Two things worth remembering: the solver’s own error bar was lying to me and needed re-deriving, and what made convergence fast was not a clever algorithm, it was the right mixing constant.

P22, cleanup. Made features honest about where they apply. The classical ghost and the force-law lab only make sense for one-electron atoms, so they explain themselves now instead of erroring on a screened atom. Fixed He+ breaking every API call, because the “+” was never URL-encoded. Unknown systems say so instead of spinning. Right now I am fixing hint text that escapes its panel on narrow screens.

0
0
12
Open comments for this post
Reposted by @yaasshh

27h 52m 6s logged

Atom_Sim: Physics Simulator Dev Log

An atom simulator built on one rule: Every number has a label (exact, numerical, approximation, counterfactual, or visual_liberty). Unlabeled numbers are treated as bugs.

Stack: Python physics engine -> React + Three.js frontend.

Phase Logs

Phases 1–3: The Hydrogen Foundation

  • Hydrogen Core: Uses exact math for energies and wavefunctions. Validates its electron clouds using statistical KS tests.
  • Numerical Solver: Solves the Schrödinger equation for custom shapes. It calculates its own accuracy by halving the grid spacing.
  • Constants Lab: Allows changing fundamental constants (hbar, e, c). It proves that changing individual units changes nothing if the ratio between them stays the same.
  • Classical Ghost: Shows old Bohr orbits collapsing, proving why classical physics cannot explain atoms.

Phases 4–6: Altered Potential & Real Atoms

  • Fake Physics: Simulates universes with non-standard forces (like Yukawa or power laws) under a clear warning banner.
  • Screened Atoms: Models elements from Helium to Argon using historic 1974 data. If an element (like Sulfur or Chlorine) lacks clean data, it is left out entirely rather than guessed.

Phases 7–12: Fields, Relativity & Nuance

  • Dirac Math: Tracks exact relativistic shifts and highlights what the math misses (the Lamb shift).
  • External Fields: Simulates atoms splitting under magnetic fields (Zeeman effect) and electric fields (Stark effect).
  • Hyperfine: Models the 21 cm hydrogen line using the precise electron-to-proton mass ratio.

Phases 13–17: Light, Speed & Thermodynamics

  • Fast Math: Uses a custom integration trick to calculate atomic lifetimes exactly and 13x faster.
  • Doublet Ratios: Proves via quantum math (Wigner 6j) why certain spectral lines are twice as bright as others.
  • Heat Sliders: Combines Saha and Boltzmann equations to turn raw rates into actual visible light. Dragging the temperature slider smoothly hands Lyman lines over to Balmer lines.

Phase 18: Line Profiles (Current Work)

Replaces infinitely sharp lines with realistic Voigt profiles using three combined factors:

  1. Natural Width: A Lorentzian shape caused by how fast an excited state decays.
  2. Doppler Width: A Gaussian shape caused by thermal motion. Works perfectly for normal hydrogen, positronium, and muonic hydrogen.
  3. Instrumental Width: A Gaussian blur based on the user’s chosen telescope or sensor resolution.

Note on Missing Physics: Collision/pressure broadening is not simulated. Instead of a text disclaimer, the app calculates how large that missing effect would be and prints the raw margin of error right next to the chart.

Core Development Rules

  • No Smoke Tests: Every physics feature must pass an automated math test.
  • No Live Fetches: All reference data is saved locally with a hard citation.
  • No Silent Approximations: If the code cannot calculate something honestly, it stops and prints exactly what data is missing.
0
1
84
Open comments for this post

27h 52m 6s logged

Atom_Sim: Physics Simulator Dev Log

An atom simulator built on one rule: Every number has a label (exact, numerical, approximation, counterfactual, or visual_liberty). Unlabeled numbers are treated as bugs.

Stack: Python physics engine -> React + Three.js frontend.

Phase Logs

Phases 1–3: The Hydrogen Foundation

  • Hydrogen Core: Uses exact math for energies and wavefunctions. Validates its electron clouds using statistical KS tests.
  • Numerical Solver: Solves the Schrödinger equation for custom shapes. It calculates its own accuracy by halving the grid spacing.
  • Constants Lab: Allows changing fundamental constants (hbar, e, c). It proves that changing individual units changes nothing if the ratio between them stays the same.
  • Classical Ghost: Shows old Bohr orbits collapsing, proving why classical physics cannot explain atoms.

Phases 4–6: Altered Potential & Real Atoms

  • Fake Physics: Simulates universes with non-standard forces (like Yukawa or power laws) under a clear warning banner.
  • Screened Atoms: Models elements from Helium to Argon using historic 1974 data. If an element (like Sulfur or Chlorine) lacks clean data, it is left out entirely rather than guessed.

Phases 7–12: Fields, Relativity & Nuance

  • Dirac Math: Tracks exact relativistic shifts and highlights what the math misses (the Lamb shift).
  • External Fields: Simulates atoms splitting under magnetic fields (Zeeman effect) and electric fields (Stark effect).
  • Hyperfine: Models the 21 cm hydrogen line using the precise electron-to-proton mass ratio.

Phases 13–17: Light, Speed & Thermodynamics

  • Fast Math: Uses a custom integration trick to calculate atomic lifetimes exactly and 13x faster.
  • Doublet Ratios: Proves via quantum math (Wigner 6j) why certain spectral lines are twice as bright as others.
  • Heat Sliders: Combines Saha and Boltzmann equations to turn raw rates into actual visible light. Dragging the temperature slider smoothly hands Lyman lines over to Balmer lines.

Phase 18: Line Profiles (Current Work)

Replaces infinitely sharp lines with realistic Voigt profiles using three combined factors:

  1. Natural Width: A Lorentzian shape caused by how fast an excited state decays.
  2. Doppler Width: A Gaussian shape caused by thermal motion. Works perfectly for normal hydrogen, positronium, and muonic hydrogen.
  3. Instrumental Width: A Gaussian blur based on the user’s chosen telescope or sensor resolution.

Note on Missing Physics: Collision/pressure broadening is not simulated. Instead of a text disclaimer, the app calculates how large that missing effect would be and prints the raw margin of error right next to the chart.

Core Development Rules

  • No Smoke Tests: Every physics feature must pass an automated math test.
  • No Live Fetches: All reference data is saved locally with a hard citation.
  • No Silent Approximations: If the code cannot calculate something honestly, it stops and prints exactly what data is missing.
0
1
84
Loading more…

Followers

Loading…