Choosing one

Start from the system,not the benchmark

All of these integrate the same equations. What differs is which kind of system each was built around, and that is what should decide it.

Same physics

Classical force fields, PME electrostatics, the same thermostats. Agreement between engines is expected.

Different assumptions

One was built for proteins in water, another for metals, another for coarse-grained beads.

Force fields travel

AMBER parameters run in GROMACS, CHARMM in several. The field is not locked to the engine.

The engines

Five that coveralmost everything

There are more, but a project that does not fit one of these is unusual enough that you already know why.

GROMACSFastest per GPU-hour for biomolecular systems, free, and the largest community. The default answer.
AMBERIts force fields are developed with it, and nucleic acids, QM/MM and free-energy work are strongest here.
LAMMPSMaterials, granular media, coarse-grained polymers. Anything that is not a protein in water.
OpenMMA Python library rather than an executable. The right choice when the simulation is part of a larger program.
NAMDBuilt for very large systems on many nodes, and pairs naturally with VMD for setup and analysis.
What actually decides it

Four questions,in order

Ask these and the choice usually makes itself before any benchmark is run.

What is the system

Protein in water, or a crystal lattice? That single fact removes most of the list immediately.

Which force field

If a specific parameter set is required, use the engine it was published for and avoid the conversion.

What method

Free energy, constant pH, QM/MM, enhanced sampling. Support for these is where engines genuinely diverge.

Who is nearby

Working input files from a colleague beat any benchmark, especially on a first project.

The most underrated of these is the last one. Inheriting working input files and someone who can answer questions is worth more than a twenty per cent throughput difference, especially on a first project. Force fields are portable between engines far more often than habits are.

Around the engine

The tools youalso end up needing

No MD project is only an MD engine. These three categories account for most of the rest of the time.

LEaP, pdb2gmxPreparationtopology, parameters, solvation
MDAnalysisAnalysisor MDTraj, or cpptraj
VMD, PyMOLLookingmore often than you expect

Preparation — building topology, assigning parameters, solvating — is where mistakes get made and where the engines differ most in ergonomics. Analysis is MDAnalysis, MDTraj or the engine's own tools, and it is worth learning one properly rather than three badly. Visualisation is VMD, PyMOL or ChimeraX, and you will use it far more than you expect.

On a machine

GROMACS isalready built

Nothing here needs compiling. Pick a machine, and these two commands put it on there.

hub://gromacs

$ dxflow workflow create --identity gromacs hub://gromacs

$ dxflow workflow start gromacs

Read it, then run itPrepaid and by the hour, on a machine that is yours about a minute after you ask.