Estimating molecular dynamics runtime and credits on Neurosnap

A request for “100 ns of molecular dynamics” specifies how much simulated time you want. It does not specify how long the computer will run. The same requested duration can take very different amounts of compute depending on the system you build.

The most useful starting point is simple: run a 1 ns pilot of your exact system before committing to a long simulation or buying a larger credit allocation for it. Keep the engine, structure, force field, ligands, membrane, box settings, timestep, and equilibration settings the same as those intended for the longer run. The pilot tests compatibility and gives you a measurement of your system's cost.

We've benchmarked various simulations for GROMACS, OpenMM, and OpenMM + Martini to develop these guidelines for estimating runtime and compute credits.

These guidelines and estimates are based on historical simulation data. They are not guarantees of runtime or credit consumption. MD simulations can be challenging to estimate, and actual usage may differ substantially with the system, preparation requirements, simulation settings, hardware, and simulation behavior.

The main considerations are:

• Duration: more simulated time requires more integration steps.
• Size: the complete system includes solvent, ions, ligands, and any membrane, as well as the protein or complex.
• Ligands: parameterizing small molecules can add substantial preparation time, and some chemistry is unsupported.
• Geometry: elongated or irregular structures can require far more solvent than compact structures with the same residue count.
• Membranes: lipid composition and box dimensions change the system you actually simulate.
• Engine and representation: GROMACS, all-atom OpenMM, and OpenMM with Martini 3 have different preparation and simulation costs.

Longer simulated time means more production work

For an unchanged system, engine, and timestep, doubling production duration approximately doubles the number of production integration steps. A smaller timestep also means more steps for the same nanosecond of simulated time. Choose scientifically appropriate settings; increasing timestep purely to reduce cost can invalidate a simulation. The OpenMM simulation guide explains these simulation controls.

The total compute duration includes more than production. Structure preparation, ligand parameterization, solvation or membrane construction, energy minimization, equilibration, trajectory processing, and analysis also take time. Those stages can be a substantial fraction of a short pilot.

That is why multiplying the total cost of a 1 ns pilot by 100 can overstate the cost of a 100 ns production request: the longer simulation does not necessarily repeat preparation 100 times. It is still a useful initial allowance when the system and settings remain comparable, but it is not a guaranteed ceiling.

Count the system you simulate

Protein residue count is useful context, but it is an incomplete measure of computational size. Water, ions, lipids, ligands, and other chains all contribute particles and interactions. Chain and molecule counts help describe an assembly, but neither count alone determines its cost. For Martini, use the constructed bead count rather than the uploaded all-atom count.

For 100 ns GROMACS simulations, our benchmarks illustrate how constructed system size affects runtime:

These benchmarks reflect different inputs and settings and include preparation and analysis overhead. The ranges describe observed runtimes, rather than prediction intervals or a quote for your submission. Construction settings can change the system size, and historical credit rates varied.

Compare runtime trends at a glance

These curves show estimated runtimes for example system sizes. System size includes solvent and ions; Martini uses coarse-grained beads. Read each engine's own axes, and use the calculator below for a rough estimate from your uploaded structure.

These are historical trends, not guaranteed runtimes. Different systems and settings underlie each engine's estimates, so the curves do not establish a universal speedup between tools.

Get a crude estimate for your structure

Choose your input structure, simulation duration, and tool for a rough planning estimate. The calculator uses uploaded atom count and geometry; the final solvated system may be much larger. Your structure is read locally in your browser.

The conservative allowance uses the upper planning range plus a fixed contingency: 5 minutes for GROMACS and OpenMM, or 1 minute for OpenMM + Martini. This padding helps with planning, but it is not a guaranteed maximum. Membrane estimates are especially approximate because composition and box dimensions can substantially change the system size.

Explore estimated runtime by duration and system size

Select an engine and explore how simulation duration and system size affect estimated runtime. Drag to rotate the chart, or hover to read an estimate.

Shape changes the amount of solvent

Two proteins with the same number of residues can produce very different simulated systems. A compact, globular protein generally fits in a smaller solvent box. An elongated protein, an irregular complex, or widely separated chains may need a much larger box to maintain appropriate distances from periodic images.

The additional space is filled with solvent. More solvent means more particles to simulate at every step, even though the protein residue count has not changed.

The effect depends on the box shape, padding, orientation, and any membrane constraints. This is why the constructed particle count is a stronger planning measure than residue count alone. Use the intended biological assembly and appropriate physical settings; arbitrary structural changes made just to fit a cheaper box can change the scientific question.

Ligands add preparation work and compatibility questions

Proteins and nucleic acids use established biopolymer parameter sets. Uploaded small molecules go through a separate parameterization workflow. Larger or more complex ligands can take substantially longer to prepare than comparably sized peptides or nucleotides, even when their contribution to the final atom count is modest.

The cost depends on the chemistry and parameterization method. Ligand size is not enough to assign a reliable cost multiplier, and some ligands cannot be parameterized reliably at all. A universal ligand cost multiplier would not reliably capture these differences.

Submit a 1 ns simulation with your actual ligands before purchasing more credits or a bigger plan for that system. Check the submitted chemistry, intended protonation and formal charge, and the ligand's placement relative to the protein. Review the prepared system and trajectory as well as whether the simulation completes. A compatibility pilot is not evidence that a long simulation will remain stable or answer the scientific question.

Treat membrane simulations as their own setup

A membrane introduces lipids, additional solvent, and construction and equilibration requirements. Its composition and box dimensions affect particle count and computational cost. An estimate for a small soluble protein is therefore a poor reference for a large membrane assembly.

For example, our benchmarked 40 ns Martini/OpenMM membrane simulations had a median total runtime of about 7.5 minutes. That result reflects the particular systems and settings benchmarked; it should not be treated as a general runtime for every 40 ns membrane simulation.

For your own estimate, preserve the intended membrane composition, dimensions, and protein orientation in the pilot. Changing them changes the constructed system and weakens the comparison.

Choose the engine and level of detail for your question

GROMACS and OpenMM are simulation engines. Martini 3 is a coarse-grained force field; Neurosnap offers a workflow that runs it with OpenMM. Coarse-graining represents groups of atoms as beads, which can make larger systems and longer simulations computationally practical while changing the molecular detail available for interpretation.

Read All-Atom vs. Coarse-Grained Molecular Dynamics: What’s the Difference and When Should You Use Each? for the scientific tradeoffs. Martini protein models also use structural-bias choices that affect the dynamics, as described in the Martini protein-model tutorial.

Do not transfer a runtime estimate unchanged between engines or representations, and do not assume a universal conversion between Martini simulated time and physical time. Our benchmarks used different systems and protocols, so they do not establish a universal engine speedup.

Convert your pilot into a credit estimate

On Neurosnap, compute credits are proportional to a simulation's billed compute duration. Different services charge different credit usage rates per second. You can find the rate on the Statistics tab of each tool's submission page.

Credits used = billed runtime in seconds × service rate in credits per second

For the same service and rate, twice the billed runtime uses twice the credits. The production simulation duration you request in nanoseconds determines how much molecular time is simulated; the computer's actual runtime determines the charge.

Start with the pilot's actual total runtime and charged credits. Queue waiting time is separate from the worker runtime used in this analysis.

For an initial allowance:

Long-simulation credits ≈ pilot credits × target duration / pilot duration

This scales the pilot's entire cost, including preparation. It can be conservative when production performance stays comparable, but hardware, preparation, analysis, system behavior, and pricing can change. The pilot is charged separately and consumes its own credits.

When production speed is available, you can make a more useful estimate:

Production hours ≈ 24 × requested nanoseconds / speed in ns per day

Then add preparation, equilibration, and analysis time:

Total hours ≈ preparation + equilibration + production + analysis hours

Estimated credits ≈ total hours × 3,600 × service rate in credits per second

Use the current rate shown on the tool's Statistics tab. A production speed report does not include every stage of the simulation workflow. If preparation or analysis timings are unavailable, retain an allowance for them rather than treating them as zero.

For example, 240 ns/day corresponds to about 10 production hours for 100 ns. If preparation, equilibration, and analysis take another hour, the estimated total is 11 hours. At a hypothetical rate of 0.0005 credits/second (1.8 credits/hour), that would be 19.8 credits for the longer simulation, plus the separately charged pilot. These numbers illustrate the calculation; they are not a Neurosnap price quote.

For a costly system, a second, longer pilot can help distinguish startup overhead from the incremental cost per ns. If two comparable pilots take T1 and T2 hours at D1 and D2 ns, a rough local estimate is:

Additional hours per ns ≈ (T2 − T1) / (D2 − D1)

Use this only when conditions are comparable and the measurements give a sensible positive slope. Keep settings comparable, use the observed variability when choosing an allowance, and budget independent replicas as separate simulations.

Use the closest historical system size and setup as a starting point, then replace that estimate with a pilot of the system you intend to run.