Skip to content

MD Workflow Generator

Set up a whole GROMACS run, every .mdp file explained and checked, index groups and the job script, or a whole LAMMPS run, every input line explained and checked, for SLURM, PBS, LSF or Grid Engine, or a PLUMED input for enhanced sampling.

Cluster

Directives use #SBATCH; submit with sbatch submit.sh.

Partition or queue
Job array
Email when the job ends

Force field and system

GROMACS 2025

Files for the newest release. gmx --version says which one a cluster has.

Thermostat and barostat

Barostat and thermostat guide

Thermostats

V-rescale recommended
Stochastic velocity rescaling (Bussi, Donadio and Parrinello 2007). It relaxes the temperature like a first-order coupling, so it is safe from the first step of NVT, and its random term gives the correct canonical distribution, so it is just as good in production. tau-t 0.1 ps (1 ps for Martini).
Nose-Hoover
An extended system with the correct ensemble and no random numbers. The temperature oscillates around the target, strongly if it starts far from it, so use it after equilibration. Its tau-t is the period of those oscillations: 4 to 5 times a first-order constant, 0.5 ps here (4 ps for Martini).
Berendsen deprecated
Suppresses the natural fluctuations of the kinetic energy, so the ensemble is wrong. Kept in GROMACS to reproduce old runs; grompp warns, so the job script adds -maxwarn.
tc-grps
Couple separately the parts that exchange heat slowly (solute and solvent, a bilayer and the water), but give every group hundreds of atoms at least, or its temperature is noise. Never a group per ion or per small ligand. Every atom must be in exactly one group.

Barostats

C-rescale recommended
Stochastic cell rescaling (Bernetti and Bussi 2020). It relaxes the pressure exponentially, so it is stable far from equilibrium, and its random term gives the correct volume fluctuations: the manual says it can be used for both equilibration and production. tau-p 1 ps (4 ps for Martini). In GROMACS 2025 it scales isotropically, semi-isotropically or with a surface tension, not anisotropically.
Parrinello-Rahman
The box vectors get an equation of motion. Correct fluctuations and any box shape, but it oscillates, very strongly if started away from the target pressure, and grompp notes that it is unstable with position restraints. So when you choose it, NPT equilibration here uses C-rescale and Parrinello-Rahman takes over in production, except with anisotropic scaling, which C-rescale cannot do. Its tau-p is a period: 5 ps (12 ps for Martini).
Berendsen deprecated
Wrong volume fluctuations; the manual recommends against it for new simulations and grompp warns.
tau-p and compressibility
tau-p is how quickly the box answers a pressure difference; too short and the box rings. The compressibility says how much the volume changes per bar (water at 300 K: 4.5e-5 bar−1). Together they set how hard the barostat pushes; the equilibrium density does not depend on them, so an approximate compressibility is fine.

Box scaling

Isotropic
x, y and z scale together and the box keeps its shape: liquids, solutions, proteins in water. One value each for ref-p and compressibility.
Semi-isotropic
The membrane plane (x/y) and the normal (z) scale separately, so the area per lipid and the thickness relax independently. Use it for bilayers and flat interfaces. Two values each: x/y, then z.
Anisotropic
All six box components scale on their own: crystals and solids under stress. The manual warns it can deform the box drastically. C-rescale cannot do it in GROMACS 2025, so the page uses Parrinello-Rahman instead (Berendsen can too, but is deprecated). Six values each; the off-diagonal compressibilities are 0, so the box angles stay fixed and the box must be rectangular: a rhombic dodecahedron or other triclinic box becomes too skewed as it shrinks, and mdrun stops.

Position restraints under pressure

A restrained atom is pulled towards a reference position. When the box scales, that reference has to move with it, or the restraints fight the barostat: grompp warns about absolute restraints with pressure coupling. refcoord-scaling = com scales the centre of mass of the references with the box and keeps their shape, so every restrained stage with a barostat gets it. The coordinates grompp reads with -r (here the start of that stage) are the references.

From the GROMACS 2025.1 manual: temperature coupling, pressure coupling and the reference manual on coupling algorithms.

Time step and bonds

Hydrogen mass repartitioning, 4 fs

Makes hydrogens three times heavier, taking the mass from the atom each is bonded to, so a 4 fs step stays stable. Needs GROMACS 2024 or newer.

What it does, and its limits

The fastest motions left once the bonds to hydrogen are rigid are the angles that move a hydrogen; they set the 2 fs limit. mass-repartition-factor = 3 makes grompp find the lightest atom (hydrogen, 1.008 u), raise every atom lighter than three times that to 3.024 u, and take the difference from the one atom it is bonded to. The total mass is unchanged, so densities and equilibrium properties are too, while those vibrations slow down enough for 4 fs.

  • 4 fs is the limit. The manual: with constraints = h-bonds, a factor of 3 "will usually enable a time step of 4 fs". Go beyond it and other motions become unstable; the page warns above 4 fs.
  • GROMACS 2024 or newer. The option arrived in 2024 (release notes). An older grompp does not know it and warns, so without -maxwarn it stops (the script passes none for this); with -maxwarn it would run without repartitioning, which at 4 fs crashes. So with GROMACS 2023 or 2022 chosen under GROMACS version, the switch is off and the files keep 2 fs: for 4 fs, repartition the topology itself (for example with ParmEd's HMassRepartition, factor 3) and type 4 as the time step.
  • Dynamics run a little slower. The manual: it "does not affect equilibrium distributions, but makes dynamics slightly slower", so rates and diffusion from an HMR run need care.
  • grompp stops when a light atom has more than one bond, when the atom it is bonded to would become too light, or with perturbed masses in a free-energy run; it warns about light atoms with no bond, which cannot be repartitioned. It also notes that bonds such as C=O now oscillate in fewer than ten time steps, when the molecules have them (water and ions do not): expected at 4 fs with only the bonds to hydrogen rigid.
  • Water hydrogens are repartitioned too, which is harmless: rigid water has no internal motion.

Topology header

Combination rule and 1‑4 fudge factors are set automatically to match the force field. Why?

Advanced override

submit.sh SLURM

topol.top header

How-to guide

How to build an MD workflow

Each tab below has its own video and steps. The files are written as you type, checked the way the engine checks them and explained line by line, and the page remembers your settings between visits.

Choose your engine, then follow its steps:

1

System: the physics every stage shares

Choose the force field (AMBER, CHARMM36, GROMOS 54A7, OPLS-AA or Martini 3), which sets the cut-offs, dispersion correction and time step it was parametrised with, and what you simulate: a solute in water, a membrane (semi-isotropic pressure coupling) or a liquid. Then the temperature and pressure, the thermostat and barostat (the guide next to them explains each), the rigid bonds and the time step, with hydrogen mass repartitioning for 4 fs.

2

Stages: what runs, and for how long

Switch stages on or off and give each a length in ps or ns, its output intervals, and whether the solute is held by position restraints. Velocities are handled for you: new ones for the first dynamics stage, carried over through the checkpoint after it. The panel at the top shows the workflow at a glance, with the steps, frames and file sizes.

3

Index groups, when you need them

Drop the .gro or .pdb grompp will read: you get the groups gmx make_ndx makes, suggestions for the ligand, the complex, the pocket, the membrane and the solvent, the temperature groups this system should use (applied to the .mdp files), and a builder for groups of your own. index.ndx goes into the zip and the script passes it with -n.

4

Job, then download all

Set the scheduler (SLURM, PBS Pro / OpenPBS, LSF or Grid Engine), resources, GPU offload and an optional PLUMED file. Every file is on the right with a tab of its own, and Download all gives submit.sh, the .mdp files, index.ndx and a README in one zip. Put your coordinates and topology next to them and submit with the command shown: sbatch, qsub, or bsub < submit.sh for LSF.

Two more tools sit beside the files. All options lists every .mdp option of GROMACS 2025.1 by section, with its default, values and the manual's text; set a value there and it goes into the file you choose. Check a file reads an .mdp you already have, says whether grompp will stop, explains every line, and opens it in the builder to continue from it.
1

System: force field and data file

Choose a force field (CHARMM36, CHARMM22/27, AMBER, OPLS-AA, COMPASS/PCFF, a water model, EAM, Tersoff, Stillinger-Weber, ReaxFF or a Lennard-Jones fluid) and the page fills in the units, styles, cut-offs and time step of that model. Drop in your data file: it is read in your browser, as read_data reads it, and the page reports the atoms and molecules, the net charge, the density and the water model it recognises. in.system makes the system; in.settings holds what every stage reads again, because a restart file does not keep the long-range solver or the neighbour-list settings.

2

Stages: lengths become steps

Four cards, for minimisation, NVT, NPT and production, each with a switch. Give each a length in fs, ps or ns and the page turns it into steps at the time step. Every stage is its own file, chained by restart files: the variable rstep is −1 for a fresh start and holds the step to carry on from after a stop, run … upto finishes at the same step however often a stage restarted, and timer timeout ends the run cleanly before the wall time. The job script runs the stages in order, skips one that finished and continues a stopped one from its newest restart file.

3

Groups, when you need them

Under Groups the page suggests sets of atoms from your data file, such as the water and the hydrogens, with their atom counts. Make your own with a name, how to select (by atom type, molecule ID or atom ID) and the values, numbers or a range such as 1:20; it becomes a group line in in.settings.

4

Job, then download all

On the Job step the Cluster card sets the resources; its wall-time margin makes LAMMPS stop a few minutes (ten by default) before the wall time, so nothing since the last restart file is lost. The card starts with one GPU, so with no accelerator the page warns you: set GPUs per node to zero for a CPU-only run. Pick an accelerator package (GPU, KOKKOS, INTEL, OPENMP or OPT) and the page lists which styles in your files have that variant. Download all gives one zip with every input and submit.sh, but not your data file: put it next to them. Couple PLUMED adds a fix plumed line and puts the PLUMED file in the zip. Already have an input? Choose My own input and only the job script is written.

Three views sit beside the files. Run files: click any line to see what it does, with its units, and why the page chose it, or choose Explained to read the whole file as a list; a green tick on a file tab means the check found no problems. All commands lists every command and style of the LAMMPS 29 Aug 2024 manual: search for one (pppm, say) to see its package, its accelerated variants and where your files use it, or tick Only those in the files. Check a file reads a LAMMPS input you already have the way LAMMPS does, says whether LAMMPS would stop and on which line, and explains every command; paste what lmp -h prints and the check knows which packages your build has.
A clean check is not a run: a short run with your data file is the final word.
1

Variables and atoms

Add a collective variable from its category (a distance, an angle or torsion, an order parameter, or your own line under Custom). Each shows PLUMED’s own keywords, and every variable needs atoms. Drop in a .gro or .pdb file, or press Load a sample; the file stays in your browser. Pick atoms by name with a query (residue name, residue numbers, atom name) and press Use. Atom numbers count from one in the order of the file, as GROMACS passes them; under LAMMPS, PLUMED uses atom IDs. Give each variable a short label: the bias refers to it by name.

2

Bias: the method and its numbers

Well-tempered metadynamics is the default; the menu also offers standard metadynamics, OPES, restraints, walls and none. Height is the size of each hill, pace the steps between hills, and a higher bias factor lets the run explore higher barriers; What these numbers mean turns the settings into energies in kT. Some methods need a module (OPES, for one), and the page warns when a default build leaves it out. Set the PLUMED version to what plumed info --version prints on your cluster: keywords are checked against that release.

3

Grid, walkers and restarts

Keep Store the bias on a grid ticked; without it every step re-sums all hills and the run slows down as it proceeds. Several walkers can share one bias: in shared-directory mode each needs its own walker ID, so you save one copy of the file for each. Continue an earlier run adds a restart line; switch it on only for a continuation, with the files of the first part in place. PLUMED writes an input file, not a job, so this tab has no Job step.

4

Widths from a trial run, then read the result

Run a short trial with the method set to None, open Analyse a run and pick its COLVAR file: you get the mean, standard deviation and range of each variable, sigma as half the standard deviation, and a grid wider than the range seen. Use puts them into the builder. For a finished metadynamics run, load its COLVAR and HILLS files and open Free energy, Convergence, Hill heights and Re-weighted. A biased run spreads wider than one basin would, so the page declines to suggest widths from it.

Check a file reads any plumed.dat the way PLUMED does, lists each error with its line number and explains every action and keyword under Line by line; Open in the builder loads it as editable cards. The checker sees only the file: the final word is plumed driver --plumed plumed.dat --natoms N --parse-only on the machine that runs the job. Figures export as PDF, PNG or SVG, or as a Python script that redraws them with matplotlib.
1

Describe the job once

On the Job step the Cluster card takes the job name, wall time, nodes, CPUs, GPUs and memory; hover a ? for advice. The summary counts cores, GPUs and core hours: eight cores for 24 hours is 192 core hours. Under LAMMPS the card asks for MPI tasks per node instead of CPUs per task.

2

Switch scheduler, keep the request

Choose SLURM, PBS Pro / OpenPBS, LSF or Grid Engine and the same request becomes that scheduler’s directives, with memory converted (32G becomes 32gb). LSF reads its directives only from standard input, so you submit with bsub < submit.sh. Grid Engine adds a parallel-environment field, because those names are specific to each site, and has no standard GPU request, so a commented placeholder and a warning ask for your site’s name.

3

Arrays and warnings

Turn on Job array for many tasks, with how many run at once; memory is per task, so the summary counts every task. The page warns when multi-node GPU runs scale poorly and that plain gmx is the thread-MPI build, which stays on one node. A wall time that is not a time is replaced by 24:00:00, and you are told.

4

Save, share, then submit

Export settings writes everything you set to a small JSON file and Import settings reads it back, so a group can share one cluster set-up; Reset to defaults puts every field back. The page also remembers your choices in this browser. Before you submit, note that the SLURM submit line starts with mkdir -p logs (SLURM opens its log file before the script runs), and that module names, partitions and GPU resource names are placeholders to adjust.

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 sections below. Anything the vendor leaves to the site (a GPU resource name, a parallel-environment name, a memory unit) is marked as site-specific in a comment inside the script.

What the generator does, and why

Every .mdp file checked like grompp

The .mdp files are written from the GROMACS 2025.1 option table, generated from grompp's own reader and the manual, and each one is checked against grompp's consistency rules as you type. Choose GROMACS 2024, 2023 or 2022 under System and the files use only the options that release reads, checked as its grompp checks them. The page says, before you submit, whether grompp would stop, which warnings to expect and why, and adds -maxwarn only where a warning cannot be avoided.

Index groups numbered as GROMACS numbers them

The default groups follow gmx make_ndx exactly, quirks included, and the structure is read with GROMACS's own column rules, so a group name offered here is one grompp will find, holding the atoms it expects. One change is deliberate: the group make_ndx leaves nameless, for a blank residue name, is called Group, because GROMACS cannot read its own [  ] back. The temperature groups are checked to cover every atom exactly once, as grompp requires.

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.

One request, four schedulers

Explicit memory, wall-time validation, #!/bin/bash -e and per-job or per-array logs under logs/ follow published cluster best-practice guides so jobs fail loudly instead of silently. The same request becomes #SBATCH, #PBS, #BSUB or #$ directives, with the matching job-id, array-index and launch conventions.

Hybrid CPU/GPU threading

Under SLURM OMP_NUM_THREADS is tied to SLURM_CPUS_PER_TASK, and SRUN_CPUS_PER_TASK is exported for Slurm > 22.05; PBS sets NCPUS from ompthreads, which the script reads with the requested count as the fallback; LSF and Grid Engine expose only slot counts, so for them the requested thread count is written next to the directive it matches. gmx mdrun runs with -ntomp and -pin auto, which pins threads when mdrun uses every CPU it can see (on a cluster that binds jobs to their CPUs, its own allocation), so jobs sharing a node do not land on the same cores; the thread-MPI gmx gets -ntmpi too, so that it keeps to the CPUs the job was given, and a job without GPUs gets -nb cpu, so that it leaves alone a GPU the node shows but the job did not ask for.

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. The checks here cover what the .mdp file alone decides; your topology decides the rest, so read grompp's own output (the page lists what to expect), and confirm module names, partitions and GPU flags against your own cluster's documentation.
Method and 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.

How the .mdp files are written

Each .mdp file is complete and commented: every line says what it does, and the Explained view and the pointer over a line give the manual's meaning with a link to the option in the GROMACS 2025.1 manual. The option names, kinds, defaults and allowed values come from a table generated from the GROMACS 2025.1 source, grompp's own reader (readir.cpp) and the manual page (mdp-options.rst).

What each force field sets, from its GROMACS port or the GROMACS manual's force-field page:

Force fieldElectrostaticsLennard-JonesDispersion correctionTime steptau-t / tau-p
AMBERPME, 1.0 nm1.0 nm, potential-shiftEnerPres2 fs, h-bonds0.1 / 1.0 ps (5.0 Parrinello-Rahman)
CHARMM36PME, 1.2 nmforce-switch 1.0–1.2 nmno2 fs, h-bonds0.1 / 1.0 ps (5.0)
GROMOS 54A7PME, 1.4 nm1.4 nm, potential-shiftno2 fs, all-bonds0.1 / 1.0 ps (5.0)
OPLS-AAPME, 1.0 nm1.0 nm, potential-shiftEnerPres2 fs, h-bonds0.1 / 1.0 ps (5.0)
Martini 3reaction field, εr 15, 1.1 nm1.1 nm, potential-shiftno20 fs, none1.0 / 4.0 ps (12.0)
  • Stages. Minimisation uses steepest descent with flexible bonds and stops below the force you set; conjugate gradient, when chosen, runs after a steepest-descent stage of its own, which relieves the clashes of a freshly solvated system faster, and with flexible water (define = -DFLEXIBLE), because GROMACS cannot use SETTLE in conjugate gradient. NVT and NPT equilibration hold the solute with the topology's position restraints (define = -DPOSRES, and grompp -r with the stage's start coordinates); production releases them. Lengths in ps or ns become nsteps at the time step, output intervals become nstxout-compressed, nstenergy and nstlog, and nstcalcenergy is the largest divisor of nstenergy up to 100.
  • Velocities. The first dynamics stage draws new velocities (gen-vel = yes, continuation = no); every later one carries them over (gen-vel = no, continuation = yes), and grompp reads the previous stage's checkpoint with -t. Each stage can override this.
  • Thermostat and barostat. V-rescale and C-rescale are the defaults, as the GROMACS manual recommends. When Parrinello-Rahman is chosen, NPT equilibration uses C-rescale, because Parrinello-Rahman oscillates when the box starts away from equilibrium; when the box must scale anisotropically, which C-rescale does not support in GROMACS 2025, Parrinello-Rahman is used instead of C-rescale, and the box must be rectangular. A Berendsen barostat, when chosen, is kept in every stage, with -maxwarn. Restrained stages under pressure get refcoord-scaling = com. A membrane couples semi-isotropically.
  • Hydrogen mass repartitioning adds mass-repartition-factor = 3 and a 4 fs time step to every dynamics stage. grompp makes the lightest atoms three times heavier, taking the mass from the atom each is bonded to; the option exists since GROMACS 2024.
  • What grompp will say. Each file is checked against grompp's consistency rules; the tab of every file shows the verdict. The job script passes -maxwarn only to a grompp call whose file draws warnings that cannot be avoided, with a comment naming them: every GROMOS topology draws one (its twin-range parametrisation), and a Berendsen thermostat or barostat, when chosen, draws one each.
  • Restarts. With Skip stages that already finished on (the default), each stage runs only while its final .gro is missing, and mdrun -cpi continues from its checkpoint, so a job that reaches its wall time can be submitted again and carries on; off, every stage runs from its start each time and no checkpoint is read. With a job array the .mdp files and an index built on the page stay in the submission directory and every task reads them there, so every run directory must hold the system that index was built from, atom for atom.
  • Index groups. The default groups port analyse() from GROMACS's index.cpp and match gmx make_ndx byte for byte, except that a nameless group is written as [ Group ]. make_ndx writes [  ] for a blank residue name, which GROMACS cannot read back: it takes the brackets for atom numbers and adds the group's atoms to the group before it. The suggested temperature groups couple solute and solvent (or membrane and solvent) separately when each is large enough, and are checked to cover every atom once, as grompp's do_numbering requires.

Zips downloaded from this page were run with GROMACS 2025 (grompp and a short mdrun for every stage) on an AMBER protein with C-rescale, a CHARMM bilayer with semi-isotropic coupling, a GROMOS system as a job array with -maxwarn, a 4 fs run with hydrogen mass repartitioning, simulated annealing with OPLS-AA, steered pulling between groups built on the page with Parrinello-Rahman in production, and a coarse-grained system with Martini settings. Every preset was also passed through grompp 2022.6, 2023.5 and 2024.6, written for each of those releases.

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
GROMOS 54A71no1.01.0
Martini 32no1.01.0

Because grompp reads whichever [ defaults ] line the topology supplies 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. grompp also accepts only one [ defaults ] directive, and each force field's forcefield.itp already contains it, so the header includes that file and shows its values as a comment rather than writing a second copy. An override is written as instructions for editing a local copy of the force field, with a warning that it departs from the canonical values. AMBER99SB-ILDN, GROMOS 54A7 and OPLS-AA ship with GROMACS (amber99sb-ildn.ff, gromos54a7.ff, oplsaa.ff); CHARMM36 is a separate download from the MacKerell lab, and Martini 3 from cgmartini.nl, whose martini_v3.0.0.itp carries the [ defaults ] line. GROMOS lists its 1‑4 pairs explicitly, so it generates none. The topology header is not in the zip, so it cannot overwrite the topology you already have.

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.
  • PME and bonded forces run on the GPU only in dynamics. mdrun refuses -pme gpu and -bonded gpu for energy minimisation, and -pme gpu for a file without PME electrostatics (Martini’s reaction field), so the script leaves them out of those stages, with a comment above the mdrun line.
  • Thread-MPI or MPI. The thread-MPI gmx gets -ntmpi (1 unless you set it), with or without GPUs: given -ntomp alone, a thread-MPI mdrun starts ranks until they fill every core the node shows, beyond the CPUs the job was given, and with a GPU in use it stops. The MPI build gmx_mpi rejects -ntmpi; it takes its ranks from srun or mpirun, which the script uses when you ask for more than one node. Double-precision builds have no GPU support, so they get no GPU flags.
  • -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) cannot constrain all bonds of a protein (choose bonds to hydrogen), and mdrun refuses it with Nose-Hoover, virtual sites (a TIP4P water) and in minimisation, so the script leaves it out of every stage that has one of those and says why. It 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. GROMOS is the exception: it was parametrised with every bond rigid, so the page writes all-bonds for it, and mdrun then refuses -update gpu for a protein.
  • 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. The toggles default to -nb gpu -pme gpu, with -ntmpi 1 for the thread-MPI gmx; energy minimisation keeps only -nb gpu, and a stage without PME drops -pme gpu. Tick -bonded gpu and -update gpu to get the full example.

How the LAMMPS inputs are written

The LAMMPS tab writes an input for every stage, the two files they share and the job script that runs them in order. Every line that holds a choice carries the reason for it, and a click on a line under Run files (or the Explained view) says what it does in plain words, with its units and a link to its page in the LAMMPS manual. The command and style names, the packages, accelerated variants, syntax skeletons, keywords and defaults come from a table generated from the LAMMPS 29 Aug 2024 source and documentation; the explanations are STEMKit's own words, and the full text is on docs.lammps.org.

What each force field sets, from the LAMMPS manual's pages for its styles and the force field's own papers:

Force fieldUnitsPair styleLong-rangeTime stepRigid bonds
CHARMM36reallj/charmmfsw/coul/long, switched 10–12 ÅPPPM, 10−62 fsSHAKE
CHARMM22/27reallj/charmm/coul/long, switched 10–12 ÅPPPM, 10−62 fsSHAKE
AMBERreallj/cut/coul/long 10 Å, tail correctionPPPM, 10−52 fsSHAKE
OPLS-AAreallj/cut/coul/long 11 Å, geometric mixingPPPM, 10−52 fsSHAKE
COMPASS / PCFFreallj/class2/coul/long 9.5 ÅPPPM, 10−51 fsnone
TIP3P, SPC/E waterreallj/cut/coul/long 10 ÅPPPM, 10−52 fsSHAKE
TIP4P/2005 waterreallj/cut/tip4p/long 8.5 Åpppm/tip4p, 10−52 fsSHAKE
EAM, EAM alloy, Finnis-Sinclairmetaleam, eam/alloy, eam/fs with your potential filenone1 fsnone
Tersoff, Stillinger-Webermetaltersoff, sw with your potential filenone1 fsnone
ReaxFFrealreaxff, with fix qeq/reaxffnone0.25 fsnone
Lennard-Jones fluidljlj/cut 2.5 σnone0.005 τnone
  • The files. in.system makes the system (units, atom style, the styles, then read_data or a crystal built with lattice and create_atoms); only the first stage reads it. in.settings holds what a restart file does not keep (the long-range solver, neighbour lists, groups, the time step, and the coefficients of pair styles such as eam or reaxff that write no restart data), and every stage reads it. in.min, in.nvt, in.npt and in.prod are the stages, chained by restart files: min.restart, then nvt.restart.<step>, npt.restart.<step> and production's restart.<step>.
  • Stages. Minimisation (conjugate gradient by default) stops at the energy and force tolerances or the iteration limit. NVT equilibration draws new velocities at the temperature; NPT equilibration lets the density settle; production runs with the restraints released. Lengths in fs, ps or ns (τ in lj units) become steps at the time step, and output intervals become thermo, dump and restart intervals. Restrained stages hold the solute's heavy atoms, or the group you name, with fix spring/self at 1000 kJ/(mol·nm²), the strength of GROMACS's posre.itp.
  • Thermostats and barostats. Nosé-Hoover chains (fix nvt, fix npt) by default, with Tdamp 100 time steps and Pdamp 1000, as the LAMMPS manual suggests; stochastic velocity rescaling (fix temp/csvr) and Langevin are offered, and Berendsen for equilibration only, since it does not sample the right ensemble. The guide under the thermostat and barostat explains each.
  • Wall time and restarts. Each stage file takes two variables from submit.sh: rstep, the step of the restart file to carry on from (−1 starts the stage), and time_limit, the wall time LAMMPS may use. timer timeout ends the run cleanly before the job is killed, a restart file is written, and run ... upto finishes the same number of steps when the job is submitted again. submit.sh skips the stages whose last restart file exists, carries on the one that was stopped, and keeps the three newest restart files of each stage.
  • Checked as LAMMPS reads it. Each input is read the way LAMMPS reads a script: # comments, & at the end of a line, single, double and triple quotes, and $x, ${name} and $(formula) substitutions. It is then followed from top to bottom, with each stage read together with the files it includes, and the page reports what LAMMPS would stop on (a style used before the box exists, a coefficient missing for a type, a group or fix that was never defined, a style the build lacks), what it warns about, and what could be better. The tab of every file shows the result, and the warnings LAMMPS will print on purpose (the wall-time stop, for one) are listed with the reason they are fine.
  • The data file stays in your browser. A data file dropped under System is read as read_data reads it: the header, every section and its line count, the atom style from the Atoms line or its columns. The masses give the elements, the charges and geometry of the water give its model, and the summary gives the net charge and the density. The files then use it: SHAKE on the hydrogen masses and the water's angle type, the solute's heavy atoms for the restraints, the groups under Groups, the atom count for the output sizes.

Zips downloaded from this page were run with LAMMPS 29 Aug 2024 on two MPI ranks, every stage from minimisation to production with a job script that was stopped and submitted again: the solvated peptide of the LAMMPS examples with the CHARMM22/27 settings, and a copper crystal with the Cu_u3.eam embedded-atom potential.

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-per-node (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, 2.10 or 2.11, chosen in the header of the System and setup panel, and checks its keywords, defaults and modules against that release. An action the chosen release lacks stays in the CV list but is marked (“needs PLUMED ≥ 2.10”, or “not in PLUMED 2.10”) and cannot be added; where the chosen release has a replacement, the page names it. 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, well-tempered (adding BIASFACTOR and TEMP) and parallel-bias (PBMETAD) metadynamics, OPES (OPES_METAD), a harmonic RESTRAINT for umbrella windows, a MOVINGRESTRAINT for steered MD, UPPER_WALLS and LOWER_WALLS, and ABMD.

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 the switching function of every multicolvar (COORDINATIONNUMBER, the Steinhardt Q3/Q4/Q6 and their LOCAL_ forms, TETRAHEDRAL). These sum over every pair of atoms; with D_MAX set, PLUMED finds the pairs closer than it with linked cells instead of scanning them all, which the developers call 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.
  • A neighbour list for COORDINATION. COORDINATION is not a multicolvar and has no linked cells: it visits every pair on its list at every step, with or without D_MAX, which only brings the switching function to zero there. What speeds up a large COORDINATION is NLIST: PLUMED rebuilds the list of pairs closer than NL_CUTOFF every NL_STRIDE steps and computes only those in between, and for a small group against a large one (a ligand in water) it asks the MD code for the nearby atoms only. Set NL_CUTOFF well beyond where the switch has decayed, and NL_STRIDE short enough that no atom comes into range between two updates. The tool warns if NLIST is set without both, or with NL_CUTOFF under twice R_0.
  • 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: set the version to what plumed info --version prints on the machine that runs the job, and read an action's keywords there with plumed manual --action=<NAME>. The file's header names the target release and the command that checks the file before the run, plumed driver --natoms N --parse-only --plumed plumed.dat, with N the number of atoms. 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 scheduler side

The batch script follows widely published cluster best-practice guides, whichever scheduler is selected.

  • #!/bin/bash -e, a failing command aborts the job immediately, so failures surface as FAILED in sacct (or the equivalent) instead of continuing with a corrupt state. Whether the -e on that first line reaches bash depends on how the scheduler starts the script: Grid Engine's default shell_start_mode ignores the shebang line and runs the script through the -S shell, and LSF's documentation does not say whether the options on it survive, so the PBS, LSF and Grid Engine scripts repeat it as an explicit set -e.
  • Explicit memory, without it, many sites apply a small default (often ~1 GB/CPU) that quietly kills MD jobs. The request is translated into each scheduler's own unit: --mem=32G, mem=32gb in a PBS chunk, rusage[mem=32768] in MB for LSF, h_vmem=32G for Grid Engine.
  • OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK (plus SRUN_CPUS_PER_TASK for Slurm > 22.05), prevents thread over-subscription in hybrid runs. PBS sets NCPUS from ompthreads for rank 0, so the script reads it with the requested count as the fallback; LSF and Grid Engine expose only slot counts, so the requested value is written in, next to the directive it matches.
  • 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 or queue 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).

How the request maps onto each scheduler

RequestSLURMPBS Pro / OpenPBSLSFGrid Engine
Threaded (GROMACS)--nodes=N --ntasks-per-node=1 --cpus-per-task=Cselect=N:ncpus=C:mpiprocs=1:ompthreads=C-n N×C -R "span[ptile=C]"-pe <pe> N×C
MPI (LAMMPS)--ntasks-per-node=M --cpus-per-task=Tncpus=M×T:mpiprocs=M:ompthreads=T-n N×M×T -R "span[ptile=M×T]"-pe <pe> N×M×T
GPUs per node--gres=gpu:G:ngpus=G (site-specific name)-gpu "num=G"commented placeholder, site-specific
Memory per node--mem=32G:mem=32gbrusage[mem=32768] (MB by default)-l h_vmem=32G (often per slot)
Wall time--time=D-HH:MM:SS-l walltime=HH:MM:SS-W HH:MM (seconds rounded up)-l h_rt=HH:MM:SS
Job array--array=1-10%2, $SLURM_ARRAY_TASK_ID-J 1-10%2, $PBS_ARRAY_INDEX-J "name[1-10]%2", $LSB_JOBINDEX-t 1-10 -tc 2 (1-based), $SGE_TASK_ID
Launchsrunmpirun -np $(wc -l < "$PBS_NODEFILE")mpirun -np $LSB_DJOB_NUMPROCmpirun -np $NSLOTS
Submitsbatch submit.shqsub submit.shbsub < submit.shqsub submit.sh

N nodes, C threads per task, M MPI tasks per node, T threads per task. LSF and Grid Engine count slots (cores on most sites) rather than tasks, so a hybrid run divides the slot count by the thread count at launch. SLURM and Grid Engine open the log file as the job starts, so logs/ must exist before submission; the submit hint under the script includes the mkdir. PBS and LSF spool the streams and copy them back when the job ends, so the script's own mkdir -p logs is in time there.

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 2025.1 user guide. Molecular dynamics parameters (.mdp options), every option the page writes, lists and links to, and Force fields (the cut-off conventions of each). mdp-options, force-fields.
  5. GROMACS 2025.1 reference manual. Molecular dynamics: temperature coupling, pressure coupling and position restraints under pressure. molecular-dynamics. GROMACS 2024 release notes, Flexible hydrogen mass repartitioning using grompp. release notes. gmx make_ndx: gmx make_ndx.
  6. Bussi, G., Donadio, D., & Parrinello, M. (2007). Canonical sampling through velocity rescaling. J. Chem. Phys., 126, 014101. (V-rescale.)
  7. Bernetti, M., & Bussi, G. (2020). Pressure control using stochastic cell rescaling. J. Chem. Phys., 153, 114107. (C-rescale.)
  8. Parrinello, M., & Rahman, A. (1981). Polymorphic transitions in single crystals: A new molecular dynamics method. J. Appl. Phys., 52, 7182–7190.
  9. Hopkins, C. W., Le Grand, S., Walker, R. C., & Roitberg, A. E. (2015). Long-time-step molecular dynamics through hydrogen mass repartitioning. J. Chem. Theory Comput., 11, 1864–1874.
  10. Force-field forcefield.itp files, the [ defaults ] lines used for the table above: amber99sb-ildn.ff and oplsaa.ff as distributed with GROMACS, and the MacKerell lab's GROMACS port of CHARMM36, which is not distributed with GROMACS.
  11. LAMMPS documentation. Accelerator packages (GPU, KOKKOS, INTEL, OPENMP, OPT; suffixes gpu/kk/intel/omp/opt) and command-line options. Speed_packages, Run_options.
  12. LAMMPS documentation (29 Aug 2024). Commands, every command and style the LAMMPS tab writes, lists and links to; read_data, read_restart and write_restart (what a restart file keeps), fix nvt/npt/nph (damping times), fix shake, timer (stopping before the wall time) and units. Commands_all, read_data, read_restart, fix_nh, fix_shake, timer, units.
  13. Thompson, A. P., et al. (2022). LAMMPS: a flexible simulation tool for particle-based materials modeling at the atomic, meso, and continuum scales. Comp. Phys. Comm., 271, 108171.
  14. Martyna, G. J., Tobias, D. J., & Klein, M. L. (1994). Constant pressure molecular dynamics algorithms. J. Chem. Phys., 101, 4177–4189. (The barostat of fix npt.)
  15. Ryckaert, J.-P., Ciccotti, G., & Berendsen, H. J. C. (1977). Numerical integration of the cartesian equations of motion of a system with constraints: molecular dynamics of n-alkanes. J. Comput. Phys., 23, 327–341. (SHAKE.)
  16. 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.
  17. SchedMD. Slurm sbatch documentation and Quick Start User Guide. slurm.schedmd.com/sbatch, quickstart.
  18. Altair Engineering. PBS Professional 2021.1 User's Guide (submitting jobs, select and place, job arrays, environment variables), and the OpenPBS qsub(1B) and pbs_resources(7B) man pages (mpiprocs, ompthreads, place). PBS Professional User's Guide, qsub.1B, pbs_resources.7B.
  19. IBM. IBM Spectrum LSF 10.1 command reference: bsub (-n, -R "span[ptile]", -R "rusage[mem]", -gpu, -W, job arrays, %J/%I) and the lsf.conf reference (LSF_UNIT_FOR_LIMITS, LSB_GPU_NEW_SYNTAX, LSB_BSUB_PARSE_SCRIPT). bsub, LSB_GPU_NEW_SYNTAX, LSB_BSUB_PARSE_SCRIPT.
  20. Open Grid Scheduler. qsub(1) (-pe, -l h_rt, -t/-tc, -o with a directory, -S, -cwd, environment variables), sge_types(1) (memory specifiers) and queue_conf(5) (shell_start_mode) man pages. qsub, sge_types, queue_conf.
  21. EuroCC Spain. SLURM Best Practice Guide for HPC Users (bash -e, memory, parallelism, job arrays).
  22. NASA NCCS. Slurm Best Practices on Discover (minimal partition specification; time/memory/node requirements). nccs.nasa.gov.
  23. 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.
  24. PLUMED consortium. CV documentation and METAD reference (PLUMED v2.9). colvar list, METAD. CV keywords verified against the colvar module source.
  25. 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).
  26. Barducci, A., Bussi, G., & Parrinello, M. (2008). Well-tempered metadynamics. Phys. Rev. Lett., 100, 020603.
  27. 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.)
  28. Abraham, M. J., et al. (2015). GROMACS: High performance molecular simulations. SoftwareX, 1–2, 19–25.

Frequently asked questions

GROMACS

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. -pme gpu, -bonded gpu and -update gpu run only in dynamics, so energy minimisation keeps -nb gpu alone; -pme gpu needs PME electrostatics, so a Martini (reaction-field) stage leaves it out; and -update gpu (GPU-resident mode) cannot constrain all bonds of a protein and is refused with Nose-Hoover or virtual sites such as TIP4P’s, so stages with those leave it out. The script says above each mdrun line what it left out and why. The thread-MPI gmx also gets -ntmpi 1, which a GPU run given -ntomp needs and which keeps a run without GPUs to the CPUs the job was given, and the MPI build gmx_mpi never gets -ntmpi, which it rejects.
How are the GROMACS stages chained together?
Each stage's grompp reads the previous stage's .gro via -c, and, when velocities carry over, its checkpoint via -t (NVT → NPT → Production); the .mdp file then says continuation = yes and gen-vel = no. Energy minimisation writes no checkpoint, so the first dynamics stage draws new velocities instead. When a stage has position restraints, -r is added pointing at the same coordinate file. Production has restraints switched off by default, and a warning appears if you tick them. With Skip stages that already finished on (the default), each stage is skipped once its final .gro exists, so a resubmitted job carries on where it stopped; off, every stage runs from its start each time.
Which thermostat and barostat should I use?
V-rescale and C-rescale, unless you have a reason not to. Both relax like the old Berendsen methods, so they are stable from the first step, and both have a random term that gives the correct ensemble, so the GROMACS manual recommends C-rescale for equilibration and production alike. Parrinello-Rahman is a sound alternative in production (the page then equilibrates with C-rescale, because Parrinello-Rahman oscillates far from equilibrium), and of the barostats that are not deprecated, the only one that scales anisotropically, so the page uses it for anisotropic scaling in every stage, with a rectangular box. Berendsen gives wrong fluctuations and is kept only to reproduce old runs; grompp warns. The guide under the thermostat and barostat on the System view explains each, with tau-t, tau-p, the compressibility and semi-isotropic coupling for membranes.
What does hydrogen mass repartitioning do, and which GROMACS do I need?
With mass-repartition-factor = 3, grompp makes every hydrogen three times heavier and takes the extra mass from the atom it is bonded to, so the total mass, and with it the equilibrium properties, do not change, while the fast angle vibrations of hydrogens slow down enough for a 4 fs time step with the bonds to hydrogen constrained. The dynamics run slightly slower, which matters for rates and diffusion. The option exists since GROMACS 2024, so with 2023 or 2022 chosen under GROMACS version the switch is off; for those, repartition the topology itself and set the time step to 4 fs. grompp notes that bonds such as C=O then oscillate in fewer than ten steps, which is expected (a box of water and ions has no such bonds, and no note).
Why does submit.sh pass -maxwarn for GROMOS?
grompp warns for every GROMOS topology, because the force field was parametrised with a twin-range cut-off GROMACS no longer has, and without -maxwarn a single warning stops it. The page counts the warnings each .mdp file will draw and passes exactly that many, with a comment above the call naming each one; files that draw none get no -maxwarn, so an unexpected warning still stops the job.
Where do the temperature groups come from, and when do I need an index file?
From what you simulate: Protein Non-Protein for a solute in water, which GROMACS makes by itself, System for a liquid, and SOLU MEMB SOLV for a membrane, as CHARMM-GUI names them in its index file. Load your structure under Index groups and the page recommends groups for it, builds index.ndx, checks that the groups cover every atom exactly once, and passes the file with -n. Any name GROMACS does not make itself needs an index file.
Can I check, or continue from, an .mdp file I already have?
Yes: paste or drop it under Check a file. It is read the way grompp reads it, and you get the verdict (will grompp stop, and at how many warnings), every problem with its line and a link to the manual, and the file explained line by line. Open in the builder then fills the form from it and keeps every option the builder would write differently as one you set, so the files you download say the same as yours.
Can I set an option the builder has no field for?
Yes, under All options: every .mdp option of GROMACS 2025.1, by section, with its default, unit, allowed values and the manual's text. Set a value for one file or for all of them; the file then shows it with a comment, and Reset to generated puts back what the builder writes.
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, OPLS-AA uses rule 3 with 0.5/0.5, and GROMOS 54A7 rule 1 with no generated pairs. Mixing them produces a silently wrong topology. The same choice sets the cut-offs and time step of the .mdp files.
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.

LAMMPS

Why does LAMMPS use tasks instead of CPUs per task?
LAMMPS parallelises with MPI, so you request --ntasks-per-node (MPI ranks per node), 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 per 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.
What files does the LAMMPS tab write?
Download all gives submit.sh, an input for every stage switched on (in.min, in.nvt, in.npt, in.prod), in.system, which makes the system and is read by the first stage only, in.settings, which every stage reads because a restart file does not keep what it sets, and a README that says what each file is for and how to run them by hand. With PLUMED coupled, the PLUMED tab's plumed.dat and the files its INCLUDE lines read go in too. Your data file, or the potential file of a metal, goes next to them; submit.sh stops before the first stage if one is missing.
How does a LAMMPS job carry on after its wall time?
LAMMPS is told how much of the wall time it may use (the wall time less the margin under Job), and timer timeout ends the run cleanly before the scheduler kills the job, after a restart file is written. Submit the same submit.sh again: stages whose last restart file exists are skipped, the stopped one reads its newest restart file (-var rstep) and finishes the same number of steps (run ... upto), and its log and trajectory are appended to, with no frame written twice. LAMMPS prints "Wall time limit reached" when that happens; it is expected.
Can I check a LAMMPS input I already have?
Yes: paste, drop or open it under Check a file in the LAMMPS tab. It is read the way LAMMPS reads it (comments, & continuation lines, quotes and $ variables) and followed from top to bottom, loops and if included, and you get what LAMMPS would stop on, what it warns about and what could be better, each with its line and a link to the command's page in the manual, then every line explained in plain words with its units. Paste what lmp -h prints on your cluster and the check knows which packages your build has; drop a data file and it is summarised (atoms, types and their elements, water, charge, density) and checked as read_data reads it. From the builder checks the file shown under Run files.
What does All commands list in the LAMMPS tab?
Every command and style of LAMMPS 29 Aug 2024 (pair, bond, angle, dihedral, improper and kspace styles, fixes, computes, dumps, regions, minimisers and the plain commands), searchable by name or by what it does and filtered by kind. Each opens to its syntax, keywords and their units, defaults, the package that provides it and its accelerated variants (/gpu, /kk, /omp, /intel, /opt), with a link to its page on docs.lammps.org. The ones your run files use are marked, with the lines that use them.

PLUMED

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 or parallel-bias MetaD, OPES, a harmonic or moving restraint, upper or lower walls, or ABMD), and toggle speed options. The output targets PLUMED 2.9, 2.10 or 2.11, whichever you pick in the header of the System and setup panel, and its keywords are checked against that release.
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.

Schedulers and job scripts

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/.
Which schedulers are supported, and what changes between them?
SLURM, PBS Professional / OpenPBS, IBM Spectrum LSF and Grid Engine (SGE, UGE). Pick one in the cluster card and the same request is written as #SBATCH, #PBS, #BSUB or #$ directives, with the matching job-id and array-index variables, the launch command (srun or mpirun with the task count taken from the allocation) and the submit command under the script. The mapping table in the method section lists every directive. The SLURM output is unchanged from earlier versions of this tool.
Why does LSF need bsub < submit.sh rather than bsub submit.sh?
bsub reads the #BSUB lines only when the script arrives on standard input. Given as an argument, the file runs as a plain command and every directive is ignored, so the job would be submitted with the queue defaults.
What does "site-specific" mean in the generated script?
A value the vendor documentation leaves to each installation: the GPU resource name under PBS (ngpus on most sites) or Grid Engine (no standard at all, so the script carries a commented placeholder), the Grid Engine parallel-environment name (qconf -spl lists them), the memory resource and its unit, and whether an LSF slot is a core. Check each against your cluster's documentation before submitting; the comment sits next to the line it concerns.
Why does the submit hint start with mkdir -p logs?
SLURM and Grid Engine open the output file as the job starts; if logs/ does not exist yet, the job fails before the script's own mkdir can run. PBS and LSF spool the output and copy it back when the job ends, so for them the mkdir inside the script is in time.

This page

Where are my settings kept, and how do I share them?
In your browser's local storage, written a moment after each change and restored when you return; nothing leaves your device. Export settings downloads the same data as a JSON file so a group can share one cluster configuration, Import settings reads it back (unknown keys are ignored), and Reset to defaults forgets the saved state.
Is this a validated production input?
No. It is a correct, best-practice starting point: the .mdp files pass grompp's rules as the page reproduces them, and zips from the page have been run with GROMACS 2025, but your topology and system decide the rest. Read grompp's own output (the page lists what to expect), check the temperature, pressure and density of the equilibration before production, 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 .mdp options GROMACS topology docs LAMMPS commands Slurm sbatch LSF bsub Grid Engine qsub NCCS best practices

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