LAMMPS and VASP Workflow Management: What Works and What Doesn't

If your lab runs LAMMPS molecular dynamics or VASP density functional theory calculations on an HPC cluster, you have a workflow management problem whether or not you've named it yet. Jobs fan out across hundreds of cores, parameters iterate across system classes, and the reasoning behind each configuration choice accumulates entirely in the heads of whoever ran the jobs. The tools available to manage this fall into two broad categories: those that help you run calculations, and those that help you remember what you learned from them. Most labs have the first. Almost none have the second.

The Tools That Exist

Here is an honest assessment of the main options computational materials and chemistry labs reach for, what they actually solve, and where they stop.

What None of These Tools Capture

Every tool above addresses a real problem. The gap they share is the same one. None of them capture the scientific reasoning behind workflow decisions — and that reasoning is the knowledge that actually walks out the door when a graduate student or postdoc leaves your lab.

Concretely: when your lab has been running LAMMPS with the ReaxFF potential for a particular system for three years, the following knowledge exists somewhere in your group:

• Which timestep was chosen and why it was halved from the default for this system class
• What the failure mode is when the neighbor list skin distance is too small for high-temperature runs
• Why you switched from LAMMPS' built-in minimizer to a custom Python wrapper for geometry optimization
• What the three ENCUT values you tested looked like and which system classes each applies to
• Why the cluster's recommended MPI topology doesn't work well for VASP jobs above a certain system size

None of that knowledge is in AiiDA, Fireworks, ASE, Pyiron, or SLURM. It is in the head of whoever ran those jobs — typically a PhD student in year 3 or 4, with 2 or 3 years left before they graduate and take it with them.

The compute stack is well-managed. The knowledge layer above it almost never is.

What Actually Works for the Knowledge Layer

The workflow tools above are worth using. AiiDA genuinely improves DFT provenance. Pyiron genuinely improves reproducibility for LAMMPS workflows. The problem is treating them as knowledge management systems when they are execution management systems.

The knowledge layer — the reasoning behind parameter choices, the failure modes your lab has mapped for specific system classes, the accumulated judgment of researchers who have since graduated — requires a different kind of system. One that is active during research rather than visited after publication. One that connects to your actual workflows rather than sitting in a separate documentation tool. One that grows more useful over time as more people contribute knowledge, rather than decaying as the person who set it up graduates.

This is what we built ResearchOS to do. It is not a replacement for AiiDA or SLURM — it connects to them. It builds a queryable institutional memory layer above your existing compute stack. When a new student joins and asks "what ENCUT has the lab used for transition metal oxide surface calculations?" the answer comes from the lab's actual decision history, not a wiki nobody has touched in two years.