gmx solvate crashing or leaving gaps for hexagonal solvent box
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
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.
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
Also fix a memory leak in the sorting routine.
Should fix crashes mentioned in #2148.
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.
#1 Updated by Teemu Murtola over 2 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.
#4 Updated by Teemu Murtola over 2 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).
#7 Updated by Teemu Murtola over 2 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.