Bug #2148

gmx solvate crashing or leaving gaps for hexagonal solvent box

Added by Erik Marklund almost 4 years ago. Updated about 3 years ago.

preprocessing (pdb2gmx,grompp)
Target version:
Affected version - extra info:
Have tested 2016.1 and 2016.3. Same errors in both cases.
Affected version:


e are trying to merge a box containing a peripheral membrane protein with another box generated with memgen. Both boxes are hexagonal and exactly the same size,Naively, we thought that gmx solvate -cp protein.gro -cs membrane_and_water.pdb -o solvated.pdb would do the trick. Unfortunately, this causes gmx solvate to crash:

Generating solvent configuration
Will generate new solvent configuration of 1x2x1 boxes
Solvent box contains 99373 atoms in 28208 residues
Removed 12253 solvent atoms due to solvent-solvent overlap
Removed 5122 solvent atoms due to solute-solvent overlap
Sorting configuration
Found 2 different molecule types:
POPE ( 52 atoms): 233 residues
SOL ( 3 atoms): 23294 residues
gmx(16892,0x7fffaa24f3c0) malloc: *** error for object 0x7fe36d0008f0: pointer being freed was not allocated
  • set a breakpoint in malloc_error_break to debug
    Abort trap: 6

So we then tried to remove the membrane, keeping only the water, and use that system as the argument for -cs (gmx solvate -cp protein.gro -cs only_water.pdb -o poorly_solvated.pdb). Gmx solvate doesn’t crash now, but the output file has strange gaps of some size in the water parts, which cannot be explained by the removed lipids. Can gmx solvate not handle solvent boxes with non-orthogonal box vectors?

The whole point in doing it this way was to avoid water molecules being inserted in the membrane. Perhaps overkill, but I am quite surprised at how bad things went with gmx solvate.

The protein structure has a gap in the sequence. We are aware of that and have corrected that, so no need to point that out.

input_output.tar (18.9 MB) input_output.tar Input files and the strange output file Erik Marklund, 03/28/2017 11:36 AM

Related issues

Related to GROMACS - Bug #2151: gmx solvate fails with solvent pdb (not gro) fileClosed

Associated revisions

Revision 8ea59db7 (diff)
Added by Teemu Murtola almost 4 years ago

Fix memory access issues in gmx solvate

There were out-of-bounds access if
1) the solvent configuration was given as a .pdb file, or
2) there were more than one type of residue in the solvent (which
triggered sorting).

Also fix a memory leak in the sorting routine.

Should fix crashes mentioned in #2148.

Change-Id: If08a7bea989803dc5641f53478004e830268750d

Revision 44909a43 (diff)
Added by Teemu Murtola over 3 years ago

Avoid some incorrect behavior with gmx solvate

gmx solvate cannot replicate non-rectangular solvent boxes correctly
(there are several different places that assume a diagonal box matrix),
so give a fatal error if that is attempted. To support some uses with
triclinic boxes, skip the replication step if the solvent and target box
sizes are already equal.

Support for general triclinic boxes can be added separately, and the
check introduced here can be valuable even in that case: it keeps a
pre-equilibrated solvent box intact if the target box size is the same.

Related to #2148.

Change-Id: I078df1f2279ccb758b11787becb89f5dbbbdfca7


#1 Updated by Teemu Murtola almost 4 years ago

gmx solvate can be picky about the way the input solvent configuration is handled. I'm not sure if this has changed at some point or has always been like that. I suspect that the code works correctly only if the input configuration has whole molecules in a rectangular unit cell with a corner at origin (or maybe some other representation, but this would be my guess). I don't have access to a visualization software to check your configuration, but could you check this if your input conformation is something else?

The crash is probably something else and would need debugging.

#2 Updated by Gerrit Code Review Bot almost 4 years ago

Gerrit received a related patchset '1' for Issue #2148.
Uploader: Teemu Murtola ()
Change-Id: gromacs~release-2016~If08a7bea989803dc5641f53478004e830268750d
Gerrit URL:

#3 Updated by Teemu Murtola almost 4 years ago

The change in gerrit fixes the crashes (at least valgrind no longer complains about anything with these inputs).

#4 Updated by Teemu Murtola almost 4 years ago

Looking at the code, gmx solvate (or its predecessors) probably never have been able to deal with non-orthogonal box vectors for the solvent box. But it may work if you make the solvent box bigger than the solute, and put atoms there into the rectangular unit cell (since the problematic code is only the part that replicates the solvent box).

#5 Updated by Teemu Murtola almost 4 years ago

  • Related to Bug #2151: gmx solvate fails with solvent pdb (not gro) file added

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

Gerrit received a related patchset '1' for Issue #2148.
Uploader: Teemu Murtola ()
Change-Id: gromacs~master~I078df1f2279ccb758b11787becb89f5dbbbdfca7
Gerrit URL:

#7 Updated by Teemu Murtola over 3 years ago

  • Status changed from New to Feedback wanted
  • Target version changed from 2016.4 to 2018

The latter linked change should "fix" this by giving a fatal error for cases that gmx solvate does not support (and never has supported). Additionally, if the solvent box has the correct size already, it can be used even if it is non-rectangular.

#8 Updated by Mark Abraham over 3 years ago

Erik, does Teemu's fix on master branch suit you?

#9 Updated by Mark Abraham about 3 years ago

  • Status changed from Feedback wanted to Closed

assuming resolved, reopen if needed

Also available in: Atom PDF