Feature #1433

free energy code introduces a crash in recent GROMACS versions for a system which is stable under older gromacs versions and with free energy off

Added by David Mobley almost 7 years ago. Updated over 6 years ago.

Target version:


In the process of trying to test some new features in version 5.0, I resurrected an old test system which I used extensively under GROMACS 3.3.4 and prior. This test system still runs under GROMACS 4.6.3 and the 5.0 pre-release I'm working with, but ONLY if the free energy code is turned off. If I turn free energy on, I get a constraints warning of a deviation of 'nan' as sooon as I start running dynamics (though minimization works fine) and the simulation hangs. It will run forever, it appears, so I end up actually having to manually kill it (and in fact ctrl-C and ctrl-D don't kill it -- I actually have to use 'kill -9 (pid)').

I am attaching a test system to reproduce the problem. As currently set up, it will run properly under 4.6.3 (and I believe 4.6.5) and the 5.0 pre-release I'm working with, but change free_energy to 'yes' in the mdp files, or the mdp file for equil_nvt, and it will hang.

I have verified that this system still works properly with the free energy code turned on under older GROMACS versions (3.3.4).

Please note that this appears particularly important and problematic, since a system run at lambda=0 with the free energy turned ON should be identical to a system run with the free energy code turned off. That's how I have this set up, so it seems particularly concerning that it hangs with free energy turned on, but not with it off.

bug.tar.gz (1.48 MB) bug.tar.gz David Mobley, 02/07/2014 09:35 PM

Associated revisions

Revision 72d747f0 (diff)
Added by Erik Lindahl over 6 years ago

Added grompp checks for zero atom masses in state B

Grompp already issued fatal errors if atoms had zero mass, or
if vsites had non-zero mass, in state A. This patch adds
state B to the same check.

Refs #1433.

Change-Id: Iec3d764ff7db6e7bdc3901d51b475cf2c35fe137


#1 Updated by Berk Hess almost 7 years ago

I still don't fully understand how this lambda-vector business works, but you have zero masses at lambda=1 and I guess masses are coupled to your lambda=1. So I think this setup can never have worked.

#2 Updated by David Mobley almost 7 years ago

OK, so it looks like the issue is really two things, one of which is my fault:

1) In resurrecting my test system, I had to set up the perturbation again, and I forgot to fill in the B state mass column in the atomtypes section, resulting in some B state masses which are zero, as you note
2) There is apparently a difference in how missing B state masses are handled in 4.x and later as compared to 3.x, in that I can run this system at lambda = 0 even with zero B state masses in older GROMACS versions, but not under the new ones. Presumably when the lambda vector stuff was implemented for 4.6 this changed.

In any case, presumably this is not exactly a bug, then, but also it would be nice to avoid silent failure. Maybe a specific warning any time any of the atoms in a system has a zero mass in either A or B state?

#3 Updated by Rossen Apostolov over 6 years ago

  • Status changed from New to Accepted
  • Priority changed from High to Low

grompp already gives a warning:

" Some parameters for bonded interaction involving perturbed atoms are
specified explicitly in state A, but not B - copying A to B"

#4 Updated by Gerrit Code Review Bot over 6 years ago

Gerrit received a related patchset '1' for Issue #1433.
Uploader: Erik Lindahl ()
Change-Id: Iec3d764ff7db6e7bdc3901d51b475cf2c35fe137
Gerrit URL:

#5 Updated by Erik Lindahl over 6 years ago

  • Tracker changed from Bug to Feature
  • Status changed from Accepted to Resolved
  • Target version changed from 4.6.x to 5.0

As Berk wrote, this is not a bug, but incorrect topology. However, I added a check for stateB to the place where we already check masses for stateA in grompp - that should help catch things like this automatically next time.

#6 Updated by Rossen Apostolov over 6 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF