Materials research
The materials simulation fleet.
Our agents turn the literature into simulation jobs and run them on your cluster day and night, instead of queueing behind the few specialists who can set up a run. They check every result against known physics and re-plan the campaign every week. Your bench only makes what the simulations already favour.
Campaign
Twelve weeks of a hydrogen storage campaign, from 240 branches to three samples.
Each grain in this metal is a branch of the campaign. Its width is its share of the cluster.
-
Week 1
Agents read 1,900 papers, patents and your past campaign reports and open 240 branches. Every parameter range carries its citation.
-
Day and night
About 160 agents write the inputs, submit the jobs and watch every run. Your cluster stays full through nights and weekends.
-
Every Monday
The plan is rewritten from the results database. Branches that stopped improving end at the Monday line.
-
The winners
Branches that keep improving get the computing time the others gave up, and their grains widen. The cost to date is on every plan.
-
Week 12
Three compositions are left. Those are the samples your bench makes this month.
-
Our own program
We run this fleet on our own research into hydrogen in metals: up to 256 agents at once, 12 campaigns and about 120,000 jobs so far.
Campaign cost CHF 46,800 / 60,000
How the plan is rewritten
- Every Monday at 06:00 the planner reads the results database, writes next week's jobs, prices them and checks them against the campaign's budget.
- A branch ends when three weeks of results have moved its best candidate by less than the error of the method.
- A new paper or a bench result can reopen a branch. Its runs stay on file and nothing is computed twice.
- Each campaign's budget cap is in code. The planner cannot spend past it, and the cost of every branch is on the plan.
- Your scientists can open any branch, rerun any job or end a branch at any time. Each such decision becomes a rule the planner applies from then on.
Literature
Every range in a job cites where it came from.
Agents read journals, patents, preprints and your own reports. Where two sources disagree, both are cited and the range covers both.
- why
- Ti speeds up hydrogen sorption in MgH₂ Liang et al., J. Alloys Compd. 292 (1999)
- ti
- 2 to 8 at.% Your report R-2024-07, p. 14
- T
- 450 to 650 K Your ELN, campaign H-2, run 31
- method
- nudged elastic band, PBE Preset mg_h_v3, anchors passed
What the agents read
- Journals, preprints and patents in your field, read as they are published.
- Your internal reports, theses and the notes of past campaigns, including the campaigns that failed.
- Your ELN and LIMS. Ranges start from what your bench has already measured.
- Public databases of computed structures and energies, used as starting points and cross-checks.
- A range without a source is not written into a job.
Runs
A run that crashes at night is running again within minutes.
Rules in code fix the common failures and resume from the last checkpoint. The rest go to an agent that reads the log and writes a corrected job.
Night 9 · SCF did not converge mixing_beta 0.05 · resumed from checkpoint 8
if failure == "scf_not_converged": resume(job, mixing_beta=0.05)if failure == "time_limit": resume(job, checkpoint=last)if failure == "out_of_memory": resume(job, card="48 GB") Every input is checked before it reaches the cluster. A broken job fails in milliseconds, not after an hour on a GPU.
More on runs
- Each job spec is typed and versioned and carries the hash of its inputs, its code release and its container. A job that already ran is recognised and not run again.
- Each job goes to the queue that fits it, GPU or CPU, card size and chunk length, from measured test runs.
- Long runs are cut into 24-hour pieces that each end in a checkpoint, so a lost node costs hours, not the run.
- A stalled job, still running but no longer moving, is caught by its own clock and restarted.
- Wall-clock limits and budgets per job class are set in code.
Anchors
A result counts only when the same settings reproduce known physics.
Before a batch is accepted, its settings recompute measured values such as the lattice constants of magnesium. A share of the results is rerun in a second code. Every number links back to its input, its code release and the paper behind its range.
assert lattice("Mg", preset) == approx((3.209, 5.211), rel=0.01) # Åassert lattice("MgH2", preset) == approx((4.517, 3.021), rel=0.01)assert rerun(barrier, code="qe") == approx(barrier, abs=0.04) # eV Every number traced
- Every preset passes its convergence tests for cutoff, k-points and smearing before a job may use it.
- Each accepted result row holds its job spec, the hashes of its inputs and outputs, the code release, the container and the preset it ran under.
- From the result you can open the citation behind each of its ranges.
- Results that fail an anchor are rerun with corrected settings. They are never written as results.
- Your scientists set the anchors and tolerances. A new anchor reruns against past results, and any result it overturns is flagged.
- 1 in 10 site energies and every new barrier are rerun in the second code.
Memory
A scientist's correction from March is still in every job in September.
# 14 March: Mg slabs need more vacuum (corrected run H-2/118)if cell.is_slab and "Mg" in cell.elements: cell.vacuum = max(cell.vacuum, 15.0) # Å# applied to 18,412 jobs since When a scientist corrects a job, the correction becomes a rule in code with its tests, and every agent applies it from the next job on. It stays when the postdoc who made it moves on.
Every step of every run is kept. By the third quarter that record trains a machine-learned potential on your own chemistry: it screens thousands of candidates in an afternoon, and DFT checks the best.
Architecture
-
Operating Code
Your presets, anchors, failure rules and budgets, written as code with their tests.
- materials/literature
- materials/specs
- materials/presets
- materials/recipes
- materials/anchors
- materials/failures
- materials/ingest
- materials/planner
- materials/budget
- materials/memory
- materials/potential
- materials/release
-
Gate
Each agent has its own identity and reaches only its queue lane and its records.
-
Your infrastructure
On your cluster, on cloud GPUs or in Marbell Cloud in Switzerland.
-
Fleet
Planners, job managers, analysts and reviewers, as many as your cluster can keep busy.
For your computational team
- Operating Code is your computational team's method written as code: tolerances become if statements, the weekly re-plan becomes a while loop over the results, what a campaign has learned becomes typed variables, and every anchor is a test. It grew out of the recursive self-improvement harness our own persistent agents run on.
- A change to a preset or a rule ships when it passes its anchors and reruns on past jobs, at the speed the tests run.
- VASP, Quantum ESPRESSO, GPAW, CP2K and LAMMPS run through tested recipes built on ASE. A new kind of job is a new recipe with its tests.
- Gate grants each agent its queue lane, its storage and its records for as long as you set. A revoked agent is denied on its next request.
- Model calls run with zero data retention. Structures and results stay on your infrastructure or in Marbell Cloud.
Systems
Cluster
- Slurm, PBS or LSF
- Cloud GPUs
- Your containers
Codes
- VASP
- Quantum ESPRESSO
- GPAW and CP2K
- LAMMPS
Records
- Your results database
- ELN and LIMS
- Instrument data
Literature
- Journals and preprints
- Patents
- Your reports
All systems
- Schedulers: Slurm, PBS Pro, LSF, Kubernetes; cloud GPUs on AWS, Azure, Google Cloud and Runpod
- Workflow tools: ASE, pymatgen, quacc, jobflow, AiiDA
- ELN and LIMS: Benchling, Signals Notebook, LabArchives, LabWare, STARLIMS
- Databases: Materials Project, OQMD, AFLOW, ICSD and your own results in PostgreSQL
- Literature: Web of Science, Scopus, arXiv, ChemRxiv, patent offices
- Materials master data in SAP S/4HANA
Start with a job class your team sets up by hand today.
We replay last quarter's runs against your own results, then run that job class live for a quarter. We are paid by how far the time from request to accepted result falls.