TorchMD: A PyTorch Molecular Dynamics Engine With a Split Licence You Should Read Before Installing
End-To-End Molecular Dynamics (MD) Engine using PyTorch
At a glance
- What is it?
- TorchMD wraps a molecular dynamics integrator in PyTorch tensors so force fields and neural network potentials can be written as differentiable Python. The code is MIT, but the README states that file format readers taken from Moleculekit carry a non-for-profit research licence, and that is the first thing to check against your use case.
- Who is it for?
- Adopt TorchMD if you are a researcher who wants to write a force field or a neural network potential as PyTorch code and run dynamics on it without leaving the autograd ecosystem, and if the non-for-profit research licence on the Moleculekit-derived readers in torchmd/run.py fits how you intend to use the software. Do not adopt it if you need a production simulation stack, a stable API, or commercial redistribution rights over those readers.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 148 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap TorchMD fills: force fields as PyTorch code, not as compiled kernels
Classical molecular dynamics engines are fast because their force evaluation is compiled and specialised. That same design makes force field development awkward: changing a functional form usually means editing C or CUDA and rebuilding. TorchMD takes the opposite route. The README describes the project as an attempt to provide a simple to use API for performing molecular dynamics using PyTorch, with the stated goal that researchers can more rapidly do research in force-field development and integrate neural network potentials into the dynamics. The intended user is therefore not someone running a long production trajectory of a well characterised system. It is someone whose force field is still changing, or whose potential is a neural network that already exists as a PyTorch module. The project describes itself as WIP and directs feedback to the GitHub issue tracker, which is a fair signal about the stability you should expect from the API.
How the engine is put together: PyTorch tensors, chemical units, and a separate potential project
The architecture implied by the README is a dynamics loop whose state and forces live in PyTorch, which is what makes a neural network potential usable inside the integrator rather than bolted on. TorchMD uses chemical units consistent with classical MD codes such as ACEMD: kcal/mol for energies, K for temperatures, g/mol for masses, and Å for distances. That choice matters more than it looks. It means an existing parameter set written for a classical engine can be dropped in without a unit conversion layer, and it means any neural potential you plug in has to emit energies in kcal/mol and accept coordinates in Å, not the arbitrary internal units a model may have been trained with. The README also points to a separate repository, TorchMD-Net, for fast and accurate neural network potentials. So the split is deliberate: TorchMD is the integrator and the PyTorch-facing API, TorchMD-Net is where the learned potentials live. If you only install TorchMD, you get the engine, not the models.
Installation: mamba, two extras, and a CUDA index URL
The README recommends installing TorchMD in a new Python environment, ideally through the Miniforge package manager. The commands it gives are: mamba create -n torchmd, then mamba activate torchmd, then mamba install pytorch python=3.10 -c conda-forge, then pip install "torchmd[full]" --extra-index-url https://download.pytorch.org/whl/cu126. The README notes that instead of the full installation you can install only the bare minimum dependencies with pip install torchmd --extra-index-url https://download.pytorch.org/whl/cu126. Two details are worth pulling out. First, the extra-index-url points at a CUDA 12.6 wheel channel, so the documented path assumes a GPU build of PyTorch; the README does not describe a CPU-only installation recipe. Second, the full extra is where the heavier dependencies sit, and the README does not enumerate them, so the practical way to decide between torchmd and torchmd[full] is to check what your own script imports. The README states that Moleculekit is installed automatically because it appears in the requirement file. Examples of how to perform dynamics are said to be in the examples folder.
The licence is MIT on the repository, but not on everything it pulls in
This is the part of the README that deserves the most attention. It states that all the code in the repository is MIT, but that several file format readers are taken from Moleculekit, which has a free open source non-for-profit, research licence, and that this is mainly in torchmd/run.py. Moleculekit is installed automatically because it is in the requirement file. The practical consequence is that the MIT label on the repository does not by itself describe the terms of the whole installed package. If your use is non-profit research, the two licences appear compatible on their face. If your use is commercial, or if you intend to redistribute a bundle that includes torchmd/run.py and the Moleculekit-derived readers, the README's own wording is the place to start and you should get your own reading of the Moleculekit licence rather than relying on the repository's MIT badge. This is not legal advice; it is a pointer to the exact file the README names.
Where TorchMD is the wrong tool
The README calls the project WIP and asks for feedback on the API and on potential bugs. That is an honest description and it should steer decisions. If you need a simulation stack that will not change under you across a multi-year project, or if you need the performance profile of a compiled engine on large solvated systems, TorchMD is not positioned for that, and the README does not claim otherwise. There is a second, subtler boundary. The project's value proposition is that the force field or potential is expressible in PyTorch. If your potential is already implemented as a compiled kernel and you have no intention of differentiating through it, the PyTorch layer buys you little and costs you the overhead of tensor-based force evaluation. The README gives no benchmark numbers, so any performance expectation you form should come from your own measurement on your own system, not from the repository. The absence of a homepage and the reliance on the GitHub issue tracker for support are consistent with a research codebase rather than a supported product.
The nearest alternative and the real difference in approach
OpenMM is the obvious comparison, and the README itself says the project will now be developed in collaboration with OpenMM and ACEMD. The difference is architectural. OpenMM exposes a Python API for setting up and running simulations, but the force computation is done by compiled platform kernels, and adding a new functional form generally means writing a plugin in C++. TorchMD puts the force evaluation in PyTorch, so a custom potential is a Python module that participates in autograd. That is the whole trade: you give up the tuned kernel performance of a mature engine and in exchange you get to write, differentiate and iterate on the potential in the same language as the rest of your model code. The collaboration noted in the acknowledgements suggests the two are not meant to be competitors in the long run, but for a decision made today, the question is simply whether your bottleneck is force field expressiveness or simulation throughput. TorchMD is aimed at the first.
Maintenance, versions and what to verify before you commit
The release history shows three versions within about half an hour on 2026-01-07 (v1.1.0, v1.1.1, v1.1.2), which reads as a rapid patch sequence rather than a long-stable line, and the repository has been pushed as recently as 2026-04-21. The README does not document an upgrade path, a deprecation policy, or a compatibility matrix between TorchMD versions and TorchMD-Net versions, so pinning both in your environment file is the only reliable approach the material supports. The README also states that to reproduce the paper you should go to the tutorial notebook in the torchmd-cg repository, which is a different repository from this one; if you are trying to reproduce published results, that is where the runnable path lives, not in the examples folder of this repository. Before adopting, verify three concrete things: that your workflow actually routes through torchmd/run.py, since that is the file the README flags for the Moleculekit licence; that your input files use the kcal/mol, K, g/mol and Å units the project documents; and that the PyTorch build you install matches the CUDA index URL in the installation command.
Editorial conclusion
Adopt TorchMD if you are a researcher who wants to write a force field or a neural network potential as PyTorch code and run dynamics on it without leaving the autograd ecosystem, and if the non-for-profit research licence on the Moleculekit-derived readers in torchmd/run.py fits how you intend to use the software. Do not adopt it if you need a production simulation stack, a stable API, or commercial redistribution rights over those readers. Before installing, read the licence note in the README, check whether your workflow actually goes through torchmd/run.py, and confirm that the units used by your input files match the kcal/mol, K, g/mol and Å convention the project documents.
Community notes