← Blog
Published on
2025-09-01

GROMACS on cloud GPUs: setup and self-benchmark guide

Use this guide to check GPU access, select a compatible GROMACS environment, and benchmark your own simulation on a cloud GPU. The original RTX 4090 launch target is no longer available for new Compute workloads; see the current GPU fleet and check the console for launchable presets.

This is a setup and validation workflow, not a tested image-and-dataset package. It does not supply a benchmark dataset or measured results. Validate your chosen GPU, driver, GROMACS build, and simulation inputs before relying on the results.

Before you start (read this)

This guide assumes:

  • You have selected a GPU preset and an image or operating system suitable for your GROMACS build
  • You know whether you are using a container or a virtual machine, and which installation permissions it provides
  • You are comfortable running commands in a Linux shell

Compute supports containers and virtual machines. Containers do not provide root or sudo access; virtual machines provide operating-system control. If your container needs system dependencies, include them in a suitable image. A custom template records launch configuration; it does not back up changes made inside a running instance.

Step 1: Select a current GPU instance

  1. Go to Compute → Instances
  2. Start creating a new instance using the current launch guide
  3. Choose a location and an available GPU preset; review its GPU, CPU, memory, storage, and active price
  4. Add your SSH key
  5. Choose a container template or virtual-machine operating system that meets the software requirements below

Environment checks before launch

  • An operating system supported by your selected GROMACS release
  • An NVIDIA driver and CUDA-enabled GROMACS build compatible with the selected GPU
  • A documented GROMACS version, with its build requirements checked
  • Enough CPU, system memory, and disk space for your simulation
  • A way to copy inputs in and save results outside the instance

Do not assume GROMACS is preinstalled. Check the image documentation and verify the executable after connecting.

Launch the instance.

Step 2: Connect and verify GPU access

SSH into the instance using the command shown in the UI.

First check that the GPU is visible:

nvidia-smi

Confirm that the GPU model matches the preset you selected. This checks device visibility, not whether your GROMACS build can run on that GPU.

If nvidia-smi fails or shows no GPU, pause the setup and inspect the error and instance configuration. Preserve your files and share the instance ID and error with Support if needed. Do not terminate an instance as an automatic troubleshooting step: termination deletes its data.

Step 3: Decide how you will run GROMACS

Choose a prebuilt environment or a source build according to your access and software requirements. Neither path below is a claim that a specific GROMACS image has been tested on Compute.

Option A: Use a compatible prebuilt GROMACS environment

Use an image from a source you trust, with documented GROMACS and GPU compatibility. Record its exact tag or digest so you can repeat the setup.

For a container instance, configure that image through a custom template and verify that it works with Compute’s access requirements. Do not assume Docker is available inside an already-running container.

command -v gmx

If the executable is available, inspect its build information:

gmx --version

Check the reported version and GPU support. A successful version check does not prove runtime compatibility; confirm that with the test run below.

The commands below assume gmx is available in this same environment. If your installation uses a different executable or launch wrapper, use it consistently.

Option B: Build GROMACS inside the instance

Choose a source build when you need specific build options or cannot find a suitable prebuilt environment. Use a virtual machine if you need operating-system package installation; a user-local build in a container still requires its dependencies to be available.

At a high level, this means:

  • Installing build dependencies
  • Configuring GROMACS with CUDA support
  • Compiling with CMake

Follow the official GROMACS installation guide for your selected release. Enable CUDA support with -DGMX_GPU=CUDA, check its compiler and CUDA requirements against the actual GPU and driver, and run the documented build tests. See NVIDIA’s Blackwell compatibility guidance when evaluating an older build for a newer GPU.

Keep the build recipe, inputs, and results outside the instance. A template can reuse an image and launch settings, but it does not capture arbitrary live filesystem changes. Check the stop and termination rules before relying on local storage.

Step 4: Prepare your test system

Create a working directory:

mkdir -p ~/gromacs
cd ~/gromacs

You need a valid .tpr file compatible with your selected GROMACS version to run mdrun.

If you already have one, copy it here as system.tpr or change the filename in the command below.

Otherwise, use your own validated simulation inputs, including any referenced topology files. The example below assumes these filenames exist; this article does not provide them:

gmx grompp -f md.mdp -c conf.gro -p topol.top -o system.tpr

Step 5: Run a GPU-offloaded benchmark

For a compatible single-GPU workload, the following starting point requests GPU nonbonded work while allowing GROMACS to select supported PME and update placement. Check the GPU-offload requirements for your release and inspect the log; these flags are not a universal performance optimum.

gmx mdrun -s system.tpr -deffnm bench \
 -nb gpu -pme auto -update auto -pin on

While it runs, confirm GPU activity in another shell:

nvidia-smi

GPU activity is a useful cross-check. Use the GROMACS log to confirm which tasks ran on the GPU; a utilization sample alone does not validate the simulation.

When the run finishes, record the reported performance (ns/day), elapsed time, input settings, and software and hardware versions. Repeat with the same inputs before comparing configurations.

What success looks like

  • gmx --version reports GPU support
  • nvidia-smi shows activity during the run
  • Performance stabilizes after warm-up
  • No CUDA or runtime errors appear in the log

Treat these as initial checks, not proof of scientific correctness. Review warnings, numerical behavior, and simulation outputs before using a run as a benchmark.

Common failure modes (and what they mean)

“GROMACS not found”
The executable may be absent or outside your shell path. Check the selected image or installation, then use its documented environment setup.

CUDA or GPU errors at runtime
Possible causes include build or driver compatibility, GPU visibility, and unsupported workload settings. Check the full error, nvidia-smi, gmx --version, and the run log before changing the environment.

Inconsistent performance between runs
Compare instance size, CPU allocation, software versions, input settings, and warm-up behavior. Keep the environment and workload fixed when assessing repeatability.

About performance numbers

Performance depends on:

  • GROMACS version
  • CUDA version
  • CPU threads used
  • System size and PME settings

This article reports no measured performance results. Benchmark your own workload and compare completed work against the actual instance cost.

When not to use this guide

  • You are looking for Support diagnostics
  • You need multi-node MPI scaling
  • You want a turnkey, persistent GROMACS environment

For a packaged or repeatable environment, maintain a versioned image and build recipe. Ask Support about platform access or instance issues; use the GROMACS documentation for application-specific setup and validation.

Try Compute today

Check the current GPU presets and active price in the console before launching. Use a compatible image or build, and keep inputs and results backed up outside the instance. Running instances are billed per second, including idle time. You can reuse launch configuration with custom templates; check the stop and termination rules before pausing or removing an instance.

‍

Your next workload belongs on Hivenet.

Pick one AI, compute, or storage workload and see the difference for yourself. Spin it up in minutes, or let our team map your fastest path to production.