A Personal Lab Database for Experimental Alloys stage 1

Background

Why this project

As a materials researcher working on novel alloys, my experimental results were scattered across spreadsheets, Origin project files, raw instrument output, and — if I'm honest — a genuinely messy desktop folder accumulated over years. Two things motivated building a proper system, in roughly equal measure.

Workflow

The researcher's routine

The system was built to directly support this routine — not to replace it.

Engineering

What was planned vs. what was built

The original design sketch was considerably more ambitious than what actually shipped — a full Docker Compose stack with MinIO/S3 object storage, Redis caching, a Jupyter analysis environment, and a file-watcher service auto-ingesting instrument output. Real use quickly showed that a leaner system — Postgres, a Python API layer, and a proper desktop interface — covered everything actually needed, without the operational overhead of running five services to enter one sample.

Knowing what to cut turned out to matter more than the original breadth of the plan. Every sample's full story — composition, how it was made, and what it measured — still stays connected, just through a considerably simpler path than first imagined.

Screenshot: Docker containers running

alloy_lab
├── samples            composition (JSONB), lineage, VEC/δ/ΔH_mix
├── synthesis          method, temperature, atmosphere, duration
├── characterization   one row per XRD/VSM/SEM measurement
├── properties         extracted numeric results per measurement
├── literature_checks  deduped matches from 3 external databases
└── material_classes

Tooling

From formula to grams

Type a formula. Get exactly what to weigh.

This was, by a wide margin, the most-iterated part of the whole project. Every feature that looked simple at first revealed a real edge case once tested against actual formulas — most memorably, distinguishing a genuine typo from valid chemistry: Cp looks like a mistake, but is actually two real, valid one-letter elements (C and P) run together. There's no purely syntactic way to know which was intended, so the parser now requires an explicit number after every element and raises a clear error on anything ambiguous, rather than silently guessing.

• Accepts natural formula notation, atomic % or weight %
• Supports pre-alloys (master alloys) as building blocks, not just pure elements
• Compensates for evaporation losses during melting with an adjustable excess %, without altering the recorded target composition
• Also handles the reverse case: already have 13 g of a master alloy on the bench and just want to know how much of the remaining elements to add — solves for the total from the fixed pre-alloy mass instead of the other way around

Fe65Nd30Co5 → 10 g target

Fe   4.40 g
Nd   5.24 g
Co   0.36 g

Screenshot: Updated New Entry tab, with options to calculate from a pre-alloy, synthesis feasibility check and skip literature checks

Physics

A cheap first filter

Before any melting: four composition-only numbers, computed instantly, no lab work required.

The insight behind the fourth check: melting-point spread alone isn't the right signal. What actually matters is whether homogenizing the melt requires heating past the boiling point of the most volatile constituent — at that point, the element doesn't just risk some evaporation, it boils away before the alloy can homogenize. Three tiers, deliberately not collapsed into one confidence level: a hard physical block (suggests mechanical alloying or sintering instead), a flagged "genuinely uncertain" zone (pure composition data isn't sufficient — check literature or run a small test melt), and a comfortable "no concern" case.

Cross-Validation

Is this already known?

Every composition is checked against three independent public materials databases.

Databases used: Materials Project · OQMD · Alexandria

A fourth database (AFLOW) was evaluated and deliberately dropped after hitting an unmaintained client library, a dead API endpoint, and unresolved query-semantics ambiguity — three independent reasons was enough to redirect effort toward Alexandria instead, which turned out to be the stronger choice regardless.

Instruments

From data to discovery

Real characterization data now flows directly into the database — no manual transcription.

The VSM pipeline caught a genuine data-quality problem, not just a code bug: the instrument's own recorded sample mass was an obviously wrong placeholder value, with the real mass only available encoded in the filename. Normalizing by the wrong mass would have silently corrupted every derived magnetic property — the fix was parsing mass from the filename convention instead of trusting the instrument's own metadata field.

Screenshot: XRD pattern and VSM hysteresis loop rendered in the Data Viewer

Interface

A real desktop application

Everything above, in one application — not a collection of scripts.

• Real-time formula validation as you type
• Material classes loaded live from the database
• One click: screen, cross-check all three literature databases, calculate, submit
• A per-database relevance slider — each database remembers its own cutoff, no re-querying when switching views
• A Data Viewer tab rendering XRD patterns, VSM loops, and SEM images directly, without leaving the app

Screenshot: New Entry tab, and the three literature database selectors with common cutoff slider

Screenshot: Data import interface — XRD, VSM, and SEM characterization data imported directly into the database

Screenshot: SEM image viewer — fast visualization of SEM images directly in the application

Screenshot: Metabase dashboard — browsing the database without writing SQL

Retrospective

What this project taught

Status

Where things stand

Resources

Additional Resources

Here you can download the presentation of the project in pdf format :

• 📓 Presentation: Alloy Lab Database Stage 1
• 📓 Repository: Alloy Lab Database
• 📜 Manifesto: on the role of AI/ML in this project