Project

General

Profile

Task #3203

Tools should check that input is valid when first using it

Added by Anthony Nash 21 days ago. Updated 3 days ago.

Status:
Accepted
Priority:
Normal
Assignee:
Category:
-
Difficulty:
uncategorized
Close

Description

As discussed on the GMX mailing list.

I've been fighting a particularly painful problem with a system I'm building in Gromacs.

gmx mdrun (grompp worked on the system) has been throwing a segmentation fault on my collagen system in a vacuum. Shortly after, I tried gmx solvate but that too was also throwing a segmentation fault. I tried the same steps over three different Gromacs distributions and they all failed ruling out any issues with Gromacs versions.

My system is a set of collagen fibrils (little in the way of water/voids) built from a crystal structure. I've had the system running before as a wildtype (just as is) and after I added post-translational modified (PTM) amino acids. That was a year ago. This week I've added a new PTM amino acid to the final frame of the wildtype simulation. Adding the PTM amino acid went through fine with pdb2gmx, make_ndx, editconf, all working completely ok.

Unfortunately, gmx solvate fails with a segmentation fault and no other indication of the problem. As I built the system from a final mdrun frame, individual peptides had crossed the unit cell (leaving voids in the main unit cell) and the final geometry kept those peptides 'whole'. Suspecting that gmx solvate can't solvate a space in the unit cell which is actually occupied across its period boundary conditions (as a guess), I executed trjconv -pbc atom to put all the content back into the original cell. However, I'm still getting a segmentation fault even when I restore the pbcs.

If I remove everything put a few amino acids, gmx solvate works. Further, VMD crashes when it tries to render either pre or post trjconv -pbc atom. I can only guess that my structure (in the .gro file) is causing gmx solvate to crash, but I'm really not sure why.

Suggestions are hugely appreciated. Please let me know what information I can provide to help.

FILES
I've attached two files:
test.gro <-- the initial configuration with whole molecules separated out from the unit cell.
test2.gro <-- the initial configuration but the all protein brought back into the unit cell to conform to PBC behaviour.

test.gro (344 KB) test.gro Anthony Nash, 11/14/2019 11:33 PM
test2.gro (344 KB) test2.gro Anthony Nash, 11/14/2019 11:33 PM
system.top (196 Bytes) system.top Anthony Nash, 11/15/2019 09:38 AM
Screenshot 2019-11-15 at 18.38.55.png (461 KB) Screenshot 2019-11-15 at 18.38.55.png Anthony Nash, 11/15/2019 08:09 PM

History

#1 Updated by Paul Bauer 21 days ago

  • Assignee set to Paul Bauer
  • Target version set to 2019.5

Hello,
thanks for the report, I'll have a look into it.

Can you please also add the exact commands you used that caused the segfault for the vacuum and solvated systems?

Cheers

Paul

#2 Updated by Anthony Nash 21 days ago

Thanks, Paul.

It was:

gmx solvate -cp test.gro -cs spc216.gro -o solvated.gro -p system.top

#3 Updated by Paul Bauer 21 days ago

Thanks!
Please also upload the system.top file.

#4 Updated by Anthony Nash 21 days ago

Attached: system.top.

#5 Updated by Paul Bauer 21 days ago

  • Status changed from New to Accepted

reproduced on 2019 HEAD

#6 Updated by Anthony Nash 21 days ago

Paul Bauer wrote:

reproduced on 2019 HEAD

Paul, many thanks for looking into this? Does it look like this is a potential bug? This simulation is for corrections to a manuscript and I am considering whether I need to inform the Editor that there will be a delay?

Thanks again. Much appreciated.

#7 Updated by Mark Abraham 21 days ago

With release-2019 HEAD, I get

GROMACS:      gmx solvate, version 2019.5-dev-20191107-0a698f1520
Executable:   /home/mabraham/git/r2019/build-cmake-gcc-debug/install/bin/gmx
Data prefix:  /home/mabraham/git/r2019/build-cmake-gcc-debug/install
Working dir:  /home/mabraham/redmines/redmine-3203
Command line:
  gmx solvate -cp test.gro -cs spc216.gro -o solvated.gro -p system.top

Reading solute configuration
Reading solvent configuration

Initialising inter-atomic distances...

WARNING: Masses and atomic (Van der Waals) radii will be guessed
         based on residue and atom names, since they could not be
         definitively assigned from the information in your input
         files. These guessed numbers might deviate from the mass
         and radius of the atom type. Please check the output
         files if necessary.

NOTE: From version 5.0 gmx solvate uses the Van der Waals radii
from the source below. This means the results may be different
compared to previous GROMACS versions.

++++ PLEASE READ AND CITE THE FOLLOWING REFERENCE ++++
A. Bondi
van der Waals Volumes and Radii
J. Phys. Chem. 68 (1964) pp. 441-451
-------- -------- --- Thank You --- -------- --------

Generating solvent configuration
Will generate new solvent configuration of 9x2x2 boxes
Solvent box contains 13827 atoms in 4609 residues
Removed 3036 solvent atoms due to solvent-solvent overlap

-------------------------------------------------------
Program:     gmx solvate, version 2019.5-dev-20191107-0a698f1520
Source file: src/gromacs/selection/nbsearch.cpp (line 693)
Function:    gmx::internal::AnalysisNeighborhoodSearchImpl::getGridCellIndex(const int*) const::<lambda()>

Assertion failed:
Condition: cell[0] >= 0 && cell[0] < ncelldim_[0]
Grid cell X index out of range

For more information and tips for troubleshooting, please check the GROMACS
website at http://www.gromacs.org/Documentation/Errors
-------------------------------------------------------

when previous branches segfault, so that's a minor improvement. That is likely an issue relating to something being outside the expected PBC range. But test2 fails the same way.

#8 Updated by Mark Abraham 21 days ago

Anthony's problem started somewhere before gmx was involved.

Look the coordinates for the NGLY residue - some of them are nan (i.e. "Not a Number") in test.gro and test2.gro. That tends to happen when whatever generated them did something like dividing by zero. I assume this is what was produced by pdbgmx. The heavy atoms from which the hydrogens are built all have plausible X coordinates, while the Y and Z are all zero. A residue with co-linear heavy atoms is going to have a hard time working out where the hydrogens should go when pdb2gmx generates them. So I conclude that Anthony needs to troubleshoot somewhere before pdb2gmx saw the input, so he can give pdb2gmx proper heavy-atom coordinates to work with.

pdb2gmx could use a check that it's not writing nan. (Ideally also a check that hack blocks have sane input, but that's much harder to do.) The analysis neighbor search code could use a check that the input coordinates are sane (e.g. not NaN).

#9 Updated by Paul Bauer 21 days ago

Thanks @Mark for debugging some more.
I can see that the code for reading in structure files checks for NAN in coordinates and prints a useful error message.

#10 Updated by Mark Abraham 21 days ago

Paul Bauer wrote:

Thanks @Mark for debugging some more.
I can see that the code for reading in structure files checks for NAN in coordinates and prints a useful error message.

Then gmx solvate must have been using some other reading routine, as that did not get printed here. gmx solvate read the files and proceeded to search for neighbors to insert solvent into gaps

#11 Updated by Paul Bauer 21 days ago

  • Status changed from Accepted to Fix uploaded

sorry for the confusion, I meant that I'll add those checks :)
Check uploaded here: https://gerrit.gromacs.org/c/gromacs/+/14300

#12 Updated by Mark Abraham 21 days ago

Paul Bauer wrote:

sorry for the confusion, I meant that I'll add those checks :)
Check uploaded here: https://gerrit.gromacs.org/c/gromacs/+/14300

I don't think reading NaNs is the problem. It's using NaNs, regardless of whether they were read or generated. Imagine a python pipeline that used bits of pdb2gmx and genbox and then called solvate. The proposed patch doesn't help at all given the inputs from Anthony's case.

#13 Updated by Anthony Nash 20 days ago

Thank you both for looking into this. I hadn't noticed those NaNs. In fact, I've never seen NaNs in a gro file until today.

I looked back to the input of pdb2gmx and it turns out I had a single ' ' (space) at the residue number mark. This was from a very tired brain when I was manually adding in N- and C- caps.

I've attached an image (the file is corrected now) of the pdb file that produced the NaNs.

#14 Updated by Mark Abraham 20 days ago

OK, we'll regard this as solved from Anthony's point of view, but whether we should make gmx more helpful is still an open question

#15 Updated by Mark Abraham 19 days ago

Anthony Nash wrote:

Thank you both for looking into this. I hadn't noticed those NaNs. In fact, I've never seen NaNs in a gro file until today.

I looked back to the input of pdb2gmx and it turns out I had a single ' ' (space) at the residue number mark. This was from a very tired brain when I was manually adding in N- and C- caps.

I've attached an image (the file is corrected now) of the pdb file that produced the NaNs.

You should pay attention to those columns. Gro and pdb are fixed width formats, not whitespace delimited. Maybe that's how you got those zero values

#16 Updated by Paul Bauer 9 days ago

  • Status changed from Fix uploaded to Blocked, need info

should there be any code changes for now?

#17 Updated by Paul Bauer 3 days ago

  • Tracker changed from Bug to Task
  • Subject changed from Segmentation fault using gmx solvent to Tools should check that input is valid when first using it
  • Status changed from Blocked, need info to Accepted
  • Target version changed from 2019.5 to 2021-infrastructure-stable
  • Affected version deleted (2019.2)

Converted this to a task to validate input and output

Also available in: Atom PDF