Bug #138

steepest descents exits with a segmentation fault; tweaking coordinates resolves

Added by David Mobley over 13 years ago. Updated over 6 years ago.

Target version:
Affected version - extra info:
Affected version:


I'm having a funny problem with the steepest descents minimizer using freeze groups. I'm trying to run
some calculations on some simple dipoles of different magnitudes -- basically I have two carbon atoms
with different charges, and I freeze them in space at different separations. Anyway, sometimes steepest
descents fails to minimize properly and just exits with a segmentation fault after a few steps. I can't get
it to work without tweaking the input coordinates (i.e. by 0.001 nm), then it works fine.

I'm linking to a tarball to (hopefully) reproduce the problem. I'm using Gromacs 3.3 with the PME
bugfix. Just download the tarball and run "" or the first two steps of it to reproduce the problem.
I can get it to work by editing the gro file and changing the last digit of the x and z coordinates of the
first atom from 0 to 1.

Please let me know. I'm trying to do a lot of these calculations and it's really a pain to have to stop,
identify the ones where minimization fails, and then tweak the input coordinates to get it to work.


#2 Updated by David van der Spoel over 13 years ago

you left out the ffamber stuff.
could you please put up a new tarball?

#3 Updated by David Mobley over 13 years ago

I updated the tarball; download it again and you should be set.

#4 Updated by David van der Spoel over 13 years ago

Nope. Server caching problem?
No ffamber anyway.

#5 Updated by David Mobley over 13 years ago

Sorry, try again. Looks like it was a gzip issue (it automatically renamed the new file rather than
overwriting the old, so I uploaded the wrong one before).


#6 Updated by David van der Spoel over 13 years ago

Ok, I reproduced the SEGV using a pre 3.3 intermediate version.

If you run mdrun -v and set nstxout = 1 to see the trajectory you will see that
the SEGV is caused by atoms shooting out of the box, due to large forces that
is. So most likely something non-physical is going on, but I can not exclude a
gromacs problem of course.

To confuse things further, mdrun works with 3.3.2beta (but not grompp due to
rlist != rcoulomb). It also works in vanilla 3.3.1. This does not necessarily
mean that bugs have been fixed, anyway I couldn't find anything that seemed
related to the problem at hand.

When I turn off freezing it also converges nicely in 3.3

I suggest you could try to update src/mdlib/minimize.c if you truly need to
stick tho this version of mdrun. Alternatively you could use a newer mdrun for
the minimization step only.

#7 Updated by David van der Spoel over 13 years ago

Hi David,

can I close this one?

#8 Updated by David Mobley over 13 years ago

I suppose, although I still think there's something funny with the minimizers even in 3.3.1. I fairly often
(i.e., not all the time, but often enough to be annoying) have one of two things happen: Either (a)
minimization ends very quickly (especially with L-BFGS) when forces are still too large so I have to do a
second round of minimization with "steep", or (b) I get these segmentation fault errors.

#9 Updated by David van der Spoel over 13 years ago

If there still are large forces the minimization should not end. If you
encounter such an example please report it back. Maybe we should cap the
displacement in the minimizer per step such that one can not get these large forces?

#10 Updated by David van der Spoel about 13 years ago

If there are new examples of misbehaving minimizations please reopen this one or open a new bugzilla.

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

Gerrit received a related patchset '1' for Issue #138.
Uploader: Roland Schulz ()
Change-Id: I7c5569693a4b84f481f0f7afd85f0f01c33295cf
Gerrit URL:

Also available in: Atom PDF