All workflows

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.

AMBERAmberToolssandercpptrajBioExcel biobbDockerconda

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.