Grommp server-side issue in running NPT equilibration step

usegalaxy.eu support
1

I am running the “High Throughput Molecular Dynamics and Analysis” tutorial (GTN:T00050) on usegalaxy .eu using a custom protein-ligand system (PDB: 8XPY, Nipah virus glycoprotein + ligand BD065) for research purposes leading to a publication.

I successfully completed the following steps without issues: GROMACS initial setup, energy minimization, and NVT equilibration (using a custom MDP file uploaded as an mdp datatype).

The problem occurs at the NPT equilibration step using GROMACS simulation (Galaxy Version 2022+galaxy0). The job consistently fails with exit code 1. The Tool Standard Error is completely empty, and the Tool Standard Output contains only the OpenCL ICD warning — no GROMACS output whatsoever, meaning grompp never produces any output before the job dies.

The inputs are all verified correct: GRO from NVT (dataset 77), Solvated TOP (dataset 49), CPT from NVT (dataset 79), posre ITP (dataset 39), and a custom MDP file (dataset 94: npt_minimal.mdp). The atom count in the GRO (48,167) has been verified to match exactly what the topology expects (6,680 protein + 52 ligand + 41,433 water + 2 ions). The same MDP approach worked successfully for NVT equilibration.

I have tried multiple MDP files (Parrinello-Rahman and Berendsen pressure coupling), different bond constraint settings, maxwarn set to both 0 and 1, and multiple reruns. All produce identical failure: exit code 1, empty stderr, only the OpenCL warning in stdout.

The command line shown in the job details performs multiple ln -s symlink operations before running gmx grompp. I suspect one of these symlink operations is failing silently on the compute node, killing the job before grompp runs. This would explain why there is zero grompp output despite grompp being correctly invoked in the command string.

The NVT step (which uses an identical tool setup and MDP approach) ran successfully, so the issue appears specific to the NPT step, possibly related to how the CPT checkpoint file is being symlinked or passed to grompp with the -t flag.

Could you please investigate why the job is dying before grompp produces any output, and whether there is a compute node issue with the symlink or checkpoint file handling for this tool? I am happy to share my history if needed.

1 Like
2

Thanks for the detailed report and also for the bug reports from Galaxy Europe (those are even more helpful for debugging).

Gromacs did start running and the key to debugging is the Log output. Although all outputs are in failed state you can click the eye icon on that dataset and get detailed information.

The important section of the log is this one:

NOTE 1 [file ./md.mdp]:
  Removing center of mass motion in the presence of position restraints
  might cause artifacts. When you are using position restraints to
  equilibrate a macro-molecule, the artifacts are usually negligible.


WARNING 1 [file ./md.mdp]:
  You are using pressure coupling with absolute position restraints, this
  will give artifacts. Use the refcoord_scaling option.

Estimate for the relative computational load of the PME mesh part: 0.28

There was 1 note

There was 1 warning

-------------------------------------------------------
Program:     gmx grompp, version 2020.4
Source file: src/gromacs/gmxpreprocess/grompp.cpp (line 2353)

Fatal error:
Too many warnings (1).
If you are sure all warnings are harmless, use the -maxwarn option.

So the tool has concerns about what you are trying to do and that’s why it aborts the run.

Now I’m not a computational chemist, but you have two options. Either you change your analysis so that the warning doesn’t get triggered, or you actively choose to ignore the warning.

With the second option there’s the additional catch that the tool version that you have been using initially (2020.4+galaxy1) does not expose that `-maxwarn` option. The latest version (to which you switched already according to your second bug report), however, does offer the option.

Just carefully study the log output of that latest version (there are now two warnings), then decide what to do. I tested the `-maxwarn` option and though that might not be the best way forward, it worked.

Best,

Wolfgang