Bug #281

Gromacs 4.0.2 and 4.0.3 unable to utilize multiple groups with settle

Added by Chris Neale over 11 years ago. Updated over 11 years ago.

Erik Lindahl
Target version:
Affected version - extra info:
Affected version:


Created an attachment (id=343)
files that reproduce the problem with gmx 4 but not gmx 3

In order to position restrain a single water molecule, we constructed a new .itp file that is in all ways identical to tip3p except that the molecule name and atome names differ. We then applied position restraints to only this "WAT" and not to "SOL". gromacs 4.0.2 and 4.0.3 crash with a segmentation fault even when nsteps is set to zero. When we instead use gromacs 3.3.3 it works fine without any segmentation fault.

Testing discovered that this can be resolved with define = -DFLEXIBLE or simply modifying wat.itp such that it is always flexible while leaving tip3p regular solvent to be settled.

We tried rearranging the order of groups, but this did not help.

We then verified that this problem exists in a simple box of 216 tip3p.

The commands for the associated tarball are:
grompp -f empty.mdp -p -c spc216.gro -o reg.tpr -maxwarn 1
mdrun -deffnm reg -v

doubleSettleSegFault.tar.gz (8.75 KB) doubleSettleSegFault.tar.gz files that reproduce the problem with gmx 4 but not gmx 3 Chris Neale, 01/26/2009 11:49 PM


#1 Updated by Berk Hess over 11 years ago

Actually your systems runs in 3.3 but incorrectly.
Gromacs is and has always been able to handle only a single settle
geometry. In 3.3 all your molecules will have the geometry of the first settle.
Gromacs 4.0 warns you about this.
The problem was that I put an incorrect array index into the error message
causing a segv in the error message.
I fixed that for 4.0.4, now you will get:
Program mdrun, VERSION 4.0.4_pre
Source code file: ../../../../src/mdlib/constr.c, line: 841

Fatal error:
More than one settle type.
Suggestion: change the least use settle constraints into 3 normal constraints.

I thought about allowing more than one settle type,
but I think this situation is so rare, that it is not
worth make the code more complex.


#2 Updated by Chris Neale over 11 years ago

Thanks Berk,

this is a good solution for us also.


Also available in: Atom PDF