HPC Environment

MD Workflow Generator | GROMACS, LAMMPS & PLUMED

Build a ready-to-submit SLURM script for GROMACS or LAMMPS, or compose a PLUMED plumed.dat with collective variables and metadynamics. For GROMACS, chain a full staged workflow (EM → NVT → NPT → Production) with restraint and checkpoint wiring and GPU-offload flags; for LAMMPS, pick the right accelerator package; for PLUMED, choose CVs by category and set the bias and speed options, all from source-verified keywords.

100% client-side · See method & references

Cluster Parameters

Best practice: leave unset unless you need specific hardware.

MD Workflow Stages

Use gmx_mpi if your module provides the MPI build (common on HPC). Check with which gmx gmx_mpi after loading the module.

Toggle each stage. Each has its own .mdp and -deffnm; grompp chains automatically (each -c reads the previous stage's .gro, -t its .cpt).

GPU Offload (mdrun)

Applied only when GPUs / Node > 0. Offloads the named calculation to the GPU.

PLUMED (optional)
Topology Header
Combination rule and 1‑4 fudge factors are set automatically to match the force field. Why?
submit.sh 
# SLURM script will appear here...
topol.top 
; Topology header will appear here...
How-To Guide

How to generate a SLURM script and topology header

Set your cluster resources on the left, pick a force field, and copy the two files that appear on the right. The generator keeps the physics consistent so you do not ship a silently broken topology.

1

Pick an engine & resources

Choose GROMACS or LAMMPS at the top, then set nodes, GPUs, wall time and memory. GROMACS uses CPUs/task (threaded); LAMMPS uses MPI tasks/node.

2

Define the workflow

For GROMACS, toggle the stages you need (EM → NVT → NPT → Production), each with its own .mdp and -deffnm. The tool chains grompp → mdrun and wires restraints and checkpoints between stages.

3

Set the force field & GPU flags

The force field auto-sets the combination rule and 1‑4 fudge factors. Choose which calculations to offload to the GPU (-nb, -pme, -bonded, -update). Warnings flag anything inconsistent.

4

Copy and finish

Copy submit.sh (and, for GROMACS, the topol.top header) into your project, then complete the [ molecules ] section with your species and counts.

The generated script uses #!/bin/bash -e, requests memory explicitly, and writes per-job or per-array logs under logs/. These are deliberate HPC best practices, not noise, see the reasons in the next section.

What the generator does, and why

Coupled force-field parameters

The combination rule and 1‑4 fudge factors are not free choices: each force field ships a specific [ defaults ] line. Selecting a force field sets both for you, and any manual override that diverges from the canonical values is flagged.

Resource-safe SLURM defaults

Explicit --mem, --time validation, #!/bin/bash -e, and log files with %x/%j/%A_%a patterns follow published cluster best-practice guides so jobs fail loudly instead of silently.

Hybrid CPU/GPU threading

OMP_NUM_THREADS is tied to SLURM_CPUS_PER_TASK, and SRUN_CPUS_PER_TASK is exported for Slurm > 22.05. gmx mdrun runs with -ntomp and -pin on for reproducible thread placement.

Everything stays local

The whole tool runs in your browser. Nothing you type is uploaded, logged, or sent anywhere, safe for unpublished systems and internal project names.

The generated files are a correct starting point, not a validated production input. Always run gmx grompp and check its warnings, and confirm module names, partitions and GPU flags against your own cluster's documentation.
Method & References

Method & references, by engine

The parameters and best practices below are grouped by tool. Switch tabs to see the details relevant to your workflow.

The parameters behind the topology header

A GROMACS [ defaults ] directive declares the non-bonded function, the combination rule, whether 1‑4 pairs are generated, and the 1‑4 scaling factors fudgeLJ and fudgeQQ. These are properties of the force field and must match it.

The [ defaults ] line has the form:

[ defaults ]
; nbfunc  comb-rule  gen-pairs  fudgeLJ  fudgeQQ

nbfunc selects the non-bonded form (1 = Lennard-Jones). comb-rule selects how pair parameters are combined: rule 2 is Lorentz–Berthelot (arithmetic–geometric), while rules 1 and 3 are geometric. gen-pairs = yes generates missing 1‑4 pairs from the normal LJ parameters scaled by fudgeLJ. fudgeLJ scales 1‑4 Lennard-Jones interactions (used only when gen-pairs is yes); fudgeQQ scales 1‑4 electrostatics and is always applied.

Canonical values shipped by each force field:

Force fieldcomb-rulegen-pairsfudgeLJfudgeQQ
AMBER (e.g. 99SB-ILDN)2yes0.50.8333
CHARMM36 / CHARMM36m2yes1.01.0
OPLS-AA3yes0.50.5

Because grompp reads your [ defaults ] line rather than inferring it from the force field name, an inconsistent combination (for example OPLS atom types with rule 2, or AMBER scaling on a CHARMM field) is accepted silently and yields physically wrong non-bonded and 1‑4 interactions. This tool prevents that by coupling the two, and warns if you deliberately override them.

GPU offload & mdrun performance

The GPU flags follow the GROMACS developers' own performance guidance. mdrun can offload the short-range non-bonded (-nb), long-range PME (-pme), bonded (-bonded) and update/constraints (-update) work to the GPU. The tool enforces the documented rules:

  • PME on GPU allows only one PME rank. When more than one rank is requested with -pme gpu, the tool adds -npme 1 automatically.
  • -bonded gpu requires -nb gpu. Bonded offload is part of the same particle-particle workload, so the short-range non-bonded task must also be on the GPU; the tool warns if it is not.
  • GPU-resident mode (-update gpu) needs constraints = h-bonds, disables dynamic load balancing, and benefits from infrequent temperature/pressure coupling and a larger nstcalcenergy (the developers suggest coupling every ≥ 50–100 steps).
  • Use constraints = h-bonds, not all-bonds, with a 2 fs step: it is faster, required for GPU-resident mode, and is what most force fields were parametrised with.
  • 1–3 MPI ranks per GPU is generally optimal; with GPU-resident mode and direct GPU communication, 1 rank/GPU is usually best.
  • After a run, check ns/day and the PP/PME balance at the end of md.log to see where time is going.

The developers' reference example for a single fast GPU with a weak CPU is gmx mdrun -ntmpi 1 -nb gpu -pme gpu -bonded gpu -update gpu, which is the configuration the toggles produce by default.

LAMMPS accelerator packages & benchmarking

LAMMPS ships five accelerator packages, each appending a suffix to any supported style. The tool emits the correct command-line switches for each:

PackageSuffixHardwareSwitches
GPUgpuNVIDIA / AMD / Intel GPUs-sf gpu -pk gpu N
KOKKOSkkGPUs, Xeon Phi, OpenMP-k on g N -sf kk -pk kokkos
INTELintelIntel CPUs / Xeon Phi-sf intel -pk intel 0
OPENMPompMulticore CPUs (hybrid)-sf omp -pk omp N
OPToptGeneric CPU pair styles-sf opt

LAMMPS parallelises with MPI, so the SLURM request uses --ntasks (ranks), not --cpus-per-task. The OPENMP package is the exception: it is a hybrid MPI × OpenMP scheme, so it uses both, srun -n R -c T lmp -sf omp -pk omp T, where -pk omp T matches --cpus-per-task. For GPU and KOKKOS runs, the number of MPI ranks per node usually matches the number of GPUs per node.

Benchmarking is essential. Acceleration is not automatically faster: the fastest choice depends on your system size, the specific pair/bond styles, and your hardware. Offloading a calculation to the GPU can leave the CPU idle, and adding cores past the optimum can actually slow a run down. Start small, read the Performance and per-section timing lines LAMMPS prints at the end of the run, and only scale up the combination that measurably helps. Not every style has an accelerated variant, check the style's doc page for the available suffixes.

PLUMED collective variables & enhanced sampling

The PLUMED tab builds a plumed.dat file for PLUMED 2.9. Collective variables are grouped by category and each exposes the exact keywords from the PLUMED source, so you get correct syntax without reading the code. Add one or more CVs, give them labels, then choose a bias method.

A CV line has the form label: ACTION KEY=VALUE ..., for example phi: TORSION ATOMS=5,7,9,15. Labels become the ARG list of the bias. The generator supports standard and well-tempered metadynamics (adding BIASFACTOR and TEMP), OPES, and a harmonic RESTRAINT for umbrella windows.

Speed optimisations (from the PLUMED performance guidance):

  • Store the bias on a grid (GRID_MIN/MAX/BIN). Without it, every step re-sums all deposited hills, so a long metadynamics run slows down continuously; with a grid the cost stays flat.
  • CALC_RCT with RCT_USTRIDE>1 computes the time-dependent c(t) reweighting factor on the fly; a larger stride reduces its overhead. It requires the bias to be on a grid.
  • Set D_MAX on every distance switching function (order parameters, coordination). PLUMED then uses linked-cell neighbour search instead of scanning all pairs, the developers describe this as a "colossal speedup". The tool folds R_0/D_0/D_MAX into a single SWITCH={RATIONAL ...} block for you and warns if D_MAX is missing.
  • Neighbour lists or linked cells for COORDINATION. Two-group COORDINATION can use either NLIST (with tuned NL_CUTOFF/NL_STRIDE) or a D_MAX cutoff, which folds into a SWITCH={RATIONAL ...} block and enables linked cells. The tool warns if neither is set, and if NLIST is set without both parameters.
  • WALKERS_MPI runs multiple walkers that share one bias, which fills the free-energy surface faster on an MPI build.
Keyword availability depends on your PLUMED build and version. The output header reminds you to check plumed --version and plumed manual --action=<NAME>. Grid bounds default to the CV range placeholders (e.g. -pi/pi for torsions), set them to your actual CV limits.

Structure / order parameters

The Steinhardt parameters Q3, Q4 and Q6 are bond-orientational order parameters that quantify local crystalline structure, the standard way to follow nucleation, melting and phase changes. They act on a SPECIES group with a switching function (R_0, D_0), and the MEAN flag reduces the per-atom values to one scalar CV suitable for biasing. Q6 is the most widely used; Q4 helps separate cubic (FCC/BCC) environments. A per-atom COORDINATIONNUMBER (local neighbour count) is offered in the same category.

Custom CVs

The Custom category lets you write any PLUMED action line directly, the tool only prepends the label. Use it for CVs outside the catalogue, for optional keywords a preset does not expose, or to combine existing CVs with the CUSTOM/MATHEVAL function action, e.g. diff: CUSTOM ARG=d1,d2 FUNC=x-y PERIODIC=NO. Whatever you type is passed through verbatim, so it is as flexible as writing plumed.dat by hand while keeping the labelling, bias wiring and PRINT list consistent.

The SLURM side

The batch script follows widely published cluster best-practice guides.

  • #!/bin/bash -e, a failing command aborts the job immediately, so failures surface as FAILED in sacct instead of continuing with a corrupt state.
  • Explicit --mem, without it, many sites apply a small default (often ~1 GB/CPU) that quietly kills MD jobs.
  • OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK (plus SRUN_CPUS_PER_TASK for Slurm > 22.05), prevents thread over-subscription in hybrid runs.
  • Only set --cpus-per-task for multithreaded codes and ntasks>1 for MPI codes, gmx mdrun is the hybrid case handled here.
  • Minimal partition specification, leaving the partition unset (unless special hardware is needed) gives the scheduler more freedom and shortens queue time.
  • Request only what you use, over-requesting CPUs, memory or GPUs leaves resources idle (nobody else can use them) and lengthens your own queue time. Get a job working on one GPU and confirm it is actually used before scaling up, and size memory from the job's real peak usage (e.g. the MaxRSS field in sacct).

References & documentation

  1. GROMACS reference manual. Topology file formats ([ defaults ], comb-rule, fudgeLJ/fudgeQQ). manual.gromacs.org.
  2. GROMACS user guide. System preparation (EM → NVT → NPT staging; -r restraints, -t checkpoint continuation). system preparation.
  3. GROMACS user guide. Getting good performance from mdrun (GPU offload rules: PME = 1 rank, -bonded needs -nb gpu, GPU-resident constraints, ranks-per-GPU). mdrun-performance.
  4. GROMACS force-field forcefield.itp files (AMBER, CHARMM36, OPLS-AA), the shipped [ defaults ] lines used for the table above.
  5. LAMMPS documentation. Accelerator packages (GPU, KOKKOS, INTEL, OPENMP, OPT | suffixes gpu/kk/intel/omp/opt) and command-line options. Speed_packages, Run_options.
  6. University of Chicago RCC and NatLab Rockies HPC. LAMMPS on SLURM (OPENMP hybrid -sf omp -pk omp N with srun -n R -c T; INTEL/OPT usage; benchmarking). RCC, NatLabRockies.
  7. SchedMD. Slurm sbatch documentation and Quick Start User Guide. slurm.schedmd.com/sbatch, quickstart.
  8. EuroCC Spain. SLURM Best Practice Guide for HPC Users (bash -e, memory, parallelism, job arrays).
  9. NASA NCCS. Slurm Best Practices on Discover (minimal partition specification; time/memory/node requirements). nccs.nasa.gov.
  10. RIT Research Computing. Slurm Quick Start Tutorial (sbatch options, %x/%j log variables, memory units, requesting only what you use, verifying GPU utilisation). research-computing.git-pages.rit.edu.
  11. PLUMED consortium. CV documentation and METAD reference (PLUMED v2.9). colvar list, METAD. CV keywords verified against the colvar module source.
  12. Tribello, G. A., Bonomi, M., Branduardi, D., Camilloni, C., & Bussi, G. (2014). PLUMED 2: New feathers for an old bird. Comp. Phys. Comm., 185(2), 604–613. See also the PLUMED performance-optimisation guidance (grid, neighbour lists, RCT_USTRIDE).
  13. Barducci, A., Bussi, G., & Parrinello, M. (2008). Well-tempered metadynamics. Phys. Rev. Lett., 100, 020603.
  14. Steinhardt, P. J., Nelson, D. R., & Ronchetti, M. (1983). Bond-orientational order in liquids and glasses. Phys. Rev. B, 28, 784. (Basis of the Q3/Q4/Q6 order parameters; see the PLUMED Q6 action docs.)
  15. Abraham, M. J., et al. (2015). GROMACS: High performance molecular simulations. SoftwareX, 1–2, 19–25.

Frequently asked questions

Why did the tool add -npme 1 or warn about my GPU flags?
These are GROMACS rules. PME on a GPU supports only one PME rank, so -npme 1 is added when you request -pme gpu with more than one rank. -bonded gpu requires -nb gpu because bonded offload is part of the same particle-particle workload. And -update gpu (GPU-resident mode) needs constraints = h-bonds and turns off dynamic load balancing.
How are the GROMACS stages chained together?
Each stage's grompp reads the previous stage's .gro via -c, and its checkpoint via -t for continuation (NVT → NPT → Production). When a stage has position restraints, -r is added pointing at the same coordinate file. Restraints are released automatically for Production.
Why does LAMMPS use tasks instead of CPUs per task?
LAMMPS parallelises with MPI, so you request --ntasks (MPI ranks), whereas GROMACS mdrun is threaded and uses --cpus-per-task. The one exception is the LAMMPS OPENMP package, a hybrid MPI × OpenMP scheme that uses both, the tool then sets -pk omp N to match CPUs/Task. For GPU or KOKKOS runs, MPI ranks per node usually matches GPUs per node.
Which LAMMPS accelerator should I pick?
It depends on your hardware and your input's styles, and there is no universal answer, you must benchmark. GPU/KOKKOS need a GPU; INTEL and OPT speed up CPU-only runs; OPENMP is hybrid and helps on high-core-count nodes. Acceleration is not automatically faster: offloading can leave the CPU idle, and adding cores past the optimum can slow a run down. Read the Performance and timing breakdown LAMMPS prints at the end, and scale up only what measurably helps.
How does the PLUMED builder help me?
It groups the collective variables by category and, for each one, exposes the exact keywords defined in the PLUMED source, atom lists, switching-function parameters, flags like NOPBC or COMPONENTS, so you get correct plumed.dat syntax without reading the code. You add CVs, label them, pick a bias method (standard/well-tempered MetaD, OPES, or a restraint), and toggle speed options. The output targets PLUMED 2.9.
What is the difference between standard and well-tempered metadynamics here?
Standard MetaD deposits Gaussian hills of fixed height. Well-tempered MetaD scales the hill height down over time using a BIASFACTOR (and TEMP), so the bias converges more smoothly. The builder adds those two keywords when you select the well-tempered variant, and OPES is offered as a modern alternative.
Why does the PLUMED tab warn about grids and CALC_RCT?
Metadynamics without a grid re-sums every deposited hill each step, so a long run slows down continuously, storing the bias on a grid keeps the cost flat. And CALC_RCT (on-the-fly c(t) reweighting) only works when the bias is on a grid, so the tool warns if you enable reweighting without it.
Why does choosing a force field change the combination rule and fudge factors?
Because they are physically coupled. Each GROMACS force field ships a specific [ defaults ] line: AMBER uses rule 2 with 0.5/0.8333, CHARMM36 uses rule 2 with 1.0/1.0, and OPLS-AA uses rule 3 with 0.5/0.5. Mixing them produces a silently wrong topology.
What exactly are fudgeLJ and fudgeQQ?
They scale the 1‑4 interactions (between atoms separated by three bonds). fudgeLJ scales the 1‑4 Lennard-Jones term and is applied only when gen-pairs is yes; fudgeQQ scales the 1‑4 electrostatics and is always applied.
Can I override the auto-set parameters?
Yes | enable Advanced override to edit the combination rule and fudge factors directly. Whenever your values differ from the force field's canonical ones, a warning explains the mismatch so you can confirm it is intentional.
Why did the script add things I did not ask for (bash -e, memory, log files)?
They are HPC best practices. #!/bin/bash -e makes the job stop and report FAILED on the first error; explicit --mem stops a small site default from killing the job; and --output/--error capture logs per job or per array task under logs/.
Is this a validated production input?
No. It is a correct, best-practice starting point. Always run gmx grompp and read its warnings, and check module names, partitions, GPU flags and account settings against your own cluster's documentation.
Is my data uploaded anywhere?
No. Everything runs locally in your browser. Nothing you type (job names, project directories, includes) leaves your device.
GROMACS topology docs Slurm sbatch NCCS best practices

The generator runs entirely in your browser, no data leaves your device.