Molecular dynamics
AMBER MD Setup
Run a full AMBER molecular dynamics setup for lysozyme 1AKI with LEaP, sander, and cpptraj. Horus routes the ARM64-incompatible AmberTools stages to a Docker executor.
What this workflow does
This workflow runs a complete molecular dynamics setup and analysis for hen egg-white lysozyme (PDB: 1AKI). It uses the AMBER toolchain: LEaP, sander, and cpptraj. The force field is ff14SB with TIP3P water.
The workflow builds an AMBER topology from the raw PDB. It minimizes the hydrogens in vacuo, then the full system in vacuo. It solvates the structure in a TIP3P box and adds neutralizing ions plus 0.15 M NaCl. It minimizes the solvated system, heats it from 0 to 300 K, and runs NVT and NPT equilibration. A free production MD simulation follows.
Four cpptraj stages then analyse the trajectory. They compute the RMSd against the first snapshot, the RMSd against the experimental structure, and the radius of gyration. The last one images the trajectory and strips the solvent.
The compute problem
This workflow has three hardware profiles in one graph.
The LEaP and pdb4amber stages are structure preparation. They run in seconds on one CPU core.
The sander stages are the cost. There are six of them: two vacuum minimizations, one solvated minimization, one heating run, and two equilibration runs, plus the free production run. Each one integrates the equations of motion over a solvated box. They want many cores or a GPU. The heating stage alone covers 2 ns.
The cpptraj stages read the trajectory and write small .dat files. They are
I/O bound, not compute bound. They want to sit next to the trajectory, not next to
the GPU.
There is also a platform problem. The biobb_amber package has no osx-arm64
conda package. On Apple Silicon you cannot install it with conda at all.
How Horus solves it
Horus supports several executors inside one workflow. Each stage picks one with a
single executor: field.
This workflow uses a mixed strategy on Apple Silicon. The stages that call
AmberTools run inside the quay.io/biocontainers/biobb_amber linux/amd64 image.
Docker pulls the image on the first run and emulates it. The stages that call
ARM64-compatible packages, such as biobb_io and biobb_analysis, run natively
in the conda environment.
The runtime.command string never changes between the two. This is the point:
you get workflow portability without a rewrite. To move the six sander stages to a
GPU node or to an HPC scheduler, change the same one field.
The alternative is a hand-built AmberTools install per machine, plus manual
scp of the topology and the trajectory at every boundary. That work does not
transfer between machines. A Horus workflow does.
Pipeline
fetch_pdb Download 1AKI from the PDB
│
pdb4amber Prepare PDB for AMBER (rename residues, strip waters)
│
gen_top Build AMBER topology and coordinates (LEaP, ff14SB)
│ → structure.leap.pdb / .top / .crd
├──► sander_h_min ──► process_h_min Minimize hydrogens in vacuo; extract energy
│
sander_n_min ──► process_n_min Minimize full system in vacuo; extract energy
│
amber_to_pdb Convert minimized structure to PDB (ambpdb)
│
leap_solvate Solvate in TIP3P water box (LEaP)
│
leap_add_ions Neutralize and add 0.15 M NaCl (LEaP)
│
sander_min ──► process_min Energy minimize solvated system
│
sander_heat ──► process_heat Heat 0 → 300 K (NVT, 2 ns)
│
sander_nvt ──► process_nvt NVT equilibration at 300 K
│
sander_npt ──► process_npt NPT equilibration (pressure coupling)
│
sander_free Free production MD simulation
│
├──► cpptraj_rms_first RMSd vs. first trajectory snapshot
├──► cpptraj_rms_exp RMSd vs. experimental crystal structure
├──► cpptraj_rgyr Radius of gyration over trajectory
└──► cpptraj_image Image trajectory, strip solvent → .trr
Inputs and outputs
Inputs
This workflow has no file inputs. It fetches 1AKI from the RCSB PDB.
Outputs land in workflow_results/results/:
downloaded.pdb: the raw PDB from the RCSB.structure.leap.top,structure.leap.crd: the AMBER topology and coordinates.structure.ions.parmtop,structure.ions.crd: the solvated and ionized system.sander.free.netcdf: the production MD trajectory.1aki_rms_first.dat: the per-frame RMSd against the first snapshot.1aki_rms_exp.dat: the per-frame RMSd against the experimental structure.1aki_rgyr.dat: the per-frame radius of gyration.1aki_imaged_traj.trr: the imaged, solvent-stripped trajectory.
The files in configs/ control the sander mdin parameters and the cpptraj
analysis options.
Run the workflow
Install the horus-runtime and the plugins one time:
uv sync
If you do not have uv, install it first:
curl -LsSf https://astral.sh/uv/install.sh | sh
You can also install the packages with pip:
pip install horus-runtime horus-environments
Then run the workflow:
uv run horus run workflow.yaml
On Apple Silicon, start Docker before you run the workflow. Horus pulls the
biobb_amber image on the first run.
References
Run this workflow
The workflow is open source. Clone the pantheon repository and run it with the horus-runtime engine. To run it on managed compute without a cluster of your own, join the Temple Compute OS waitlist.