Bug #2364
g_membed not working on gromacs 2018
Description
Following my post on the users mailing list, here is the bug report for the g_membed protocol in gromacs 2018:
When I try to embed a protein into the membrane with g_membed and gromacs 2018, it fails at step 0 with the following error message:step 0: One or more water molecules can not be settled.
Check for bad contacts and/or reduce the timestep if appropriate.
Wrote pdb files with previous and current coordinates
Warning: Only triclinic boxes with the first vector parallel to the x-axis and the second vector in the xy-plane are supported.
Box (3x3):
Box[ 0]={ -nan, -nan, -nan}
Box[ 1]={ -nan, -nan, -nan}
Box[ 2]={ -nan, -nan, -nan}
Can not fix pbc.
This seems to be independent of my system (tried multiple proteins and membranes). I also checked different timesteps, nxy, nz options and increased the number of steps. However, running the exact same system with gromacs 2016.3, the embedding simulation succeeds.
Steps to reproduce this:
1) Orient a protein in an equilibrated and solvated membrane, merge the topology files
2) Running grompp with a standart mdp file and freezegrps=Protein, energy exclusion on protein:
gmx grompp -f g_membed.mdp -c system.gro -p system.top -o g_membed.tpr --maxwarn 2
3) run the embedding simulation:
echo Protein Other | gmx mdrun -deffnm g_membed -membed embed.dat -mp embedded.top -c embedded.gro
I attached all files and a script to reproduce the issue. Please let me know if you need any further data or assistance.
Related issues
Associated revisions
History
#1 Updated by Mark Abraham about 3 years ago
Thanks very much - we'll take a look at this, but probably not until after Christmas!
#2 Updated by Paul Bauer about 3 years ago
I had a look at this and can easily reproduce it with the release-2018 branch.
Looks like it starts with a bad temperature accounting (first actual difference between the log files for the two versions), but I can't say why this happens.
Note, it doesn't seem to be caused by any of the SIMD changes, because the bug is also triggered when using a version build with GMX_SIMD=None
#3 Updated by Mark Abraham about 3 years ago
Paul Bauer wrote:
I had a look at this and can easily reproduce it with the release-2018 branch.
Looks like it starts with a bad temperature accounting (first actual difference between the log files for the two versions), but I can't say why this happens.
Note, it doesn't seem to be caused by any of the SIMD changes, because the bug is also triggered when using a version build with GMX_SIMD=None
There have been some patches that fixed the initial temperature reporting (but IIRC the computation was always OK) which could be suspects.
#4 Updated by Mark Abraham about 3 years ago
- File membed-2016.4.log membed-2016.4.log added
- File membed-2018.log membed-2018.log added
The step 0 KE is broken, so I assume that some of the logic that was changed for the step 0 KE reporting doesn't work - perhaps even for the group scheme generally? We should diff some non-membed group-scheme log files bewteen 2016 and 2018 for clues
#5 Updated by Paul Bauer about 3 years ago
The offending commit seems to be aee855491496f831e60546031d74cb918b9e063a according to my bisecting. But this is a rather large commit so I'm not really sure.
#6 Updated by Mark Abraham about 3 years ago
Concur with the bisection result. I presume the atom lookup no longer works correctly in this case, and will look at why.
#7 Updated by Mark Abraham about 3 years ago
Judging by the debug output, something (mdatoms? indices into it?) are getting garbled before settles get set up. membed only runs a single rank, which might be a factor.
#8 Updated by Mark Abraham about 3 years ago
- Status changed from New to In Progress
- Assignee set to Mark Abraham
- Target version set to 2018
It turns out that my concerns about the way this patch reorganized mtop were valid (see https://gerrit.gromacs.org/#/c/6216/). membed edits mtop, and did not re-establish its invariants.
I will open a Redmine where we can record our need to make it harder to misuse mtop, or the data that helps us do efficient searching of it.
#9 Updated by Gerrit Code Review Bot about 3 years ago
Gerrit received a related patchset '1' for Issue #2364.
Uploader: Mark Abraham (mark.j.abraham@gmail.com)
Change-Id: gromacs~release-2018~I27166acec903e4c0cf3b9a54aaf4b9db7d6974b0
Gerrit URL: https://gerrit.gromacs.org/7411
#10 Updated by Mark Abraham about 3 years ago
- Related to Task #2371: mtop searching needs reconsideration added
#11 Updated by Erik Lindahl about 3 years ago
- Status changed from In Progress to Fix uploaded
#12 Updated by Erik Lindahl about 3 years ago
- Status changed from Fix uploaded to Resolved
#13 Updated by Erik Lindahl about 3 years ago
- Status changed from Resolved to Closed
Fix membed by calling the proper mtop finalization routine
Fixes #2364
Refs #2371
Change-Id: I27166acec903e4c0cf3b9a54aaf4b9db7d6974b0