Mthe lab
← all projects
2025 — presentlive

rhyolite-MELTS Tracker

A single-file HTML app for tracking thermodynamic simulation runs across dozens of samples — and finally seeing the patterns I'd been missing in spreadsheets.

HTMLVanilla JSJSON storagerhyolite-MELTS
22
samples
16
simsets
3
geological units
60.4 – 77.5
SiO₂ range (wt%)

The rhyolite-MELTS Tracker is a small, single-file HTML app that keeps every part of a simulation campaign in one place: the sample whole-rock compositions, the simulation setups ("simsets"), the per-run extraction thresholds, the pressure-calc results, and a journal for the inevitable "why did this run go sideways" notes.

It started because I had forty tabs of a spreadsheet open and knew I was about to lose track of which run corresponded to which sample.

What it tracks

The tracker has seven views, each a tab:

  • Sample Database — whole-rock compositions, lithologic unit, lat/lon
  • Runs — individual rhyolite-MELTS runs with their P-T conditions
  • Batches — groups of runs queued together
  • P Calc Thresholding — melt-extraction threshold logic per simset
  • Pressure Viz — depth interpretations across samples
  • Journal — short notes per day, per run, per anomaly
  • Settings — defaults and import/export

What's actually in it right now

This isn't theoretical — the live database has real campaign data:

  • 22 samples in total, split across Aplite, Granodiorite, and a handful of uncategorized field finds
  • 16 simsets spanning multiple P-T sweeps
  • 3 geological units mapped from the Tuolumne Intrusive Complex:
    • Cathedral Peak Granodiorite (Kcp)
    • Granodiorite of Kuna Crest (Kkc)
    • Half Dome Granodiorite, equigranular (eKhd)
  • 3 batches of queued runs and 3 journal entries of the kind that future-me will thank past-me for writing down
  • whole-rock SiO₂ spans 60.40 – 77.50 wt% — a cleaner range than I'd expected, with the aplites tightly clustered in the high 70s

Why it works

The trick was deciding the data model first and the UI second. Every sample has a stable id; every simset references a sample id; every run references a simset. Nothing depends on file names or sheet positions.

Once everything has a stable id, you can lose any one view and rebuild it. Spreadsheets don't have that property.

The whole tracker is one HTML file with embedded CSS and JS, and it reads/writes a single JSON document. It runs offline. I can email it to a collaborator. I can diff it in git. It is, deliberately, the smallest useful thing.

What's next

A small importer to pull rhyolite-MELTS output text directly into the runs table — right now the fields are entered by hand, which is actually fine for the cadence of this project but would scale poorly with more samples.

I'm also thinking about a thin Tauri wrapper, but only if I can keep the "email a single file" property intact.