Project

General

Profile

Feature #2108

Please remove new annoying 'note' in Gromacs

Added by Michael Holmboe over 2 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
preprocessing (pdb2gmx,grompp)
Target version:
Difficulty:
simple
Close

Description

With Gromacs 2016.x using the forcefield Clayff (Cygan, 2004, for inorganic molecules/minerals/zeolites) or other 'non-bonded' ff's, used to model mainly ionic compounds (i.e. with atoms held together by only non-bonded interactions), one runs into a new (atleast since Gromacs 5.1.2) annoying 'note' for every unbounded atom in their molecules (In my case usually several thousands).

---
Atom 1 'some-atom' in molecule type 'my-molecule' is not bound by a potential or constraint to any other atom in the same molecule type.

Atom 2 ...

Atom 3 ...

and on and on for every atom in the 'molecule'.
---

Then..

NOTE 1 [file topol.top, line xx]:
In molecule type 'my-molecule' XXXXX atoms are not bound by a potential or
constraint to any other atom in the same moleculetype. Although
technically this might not cause issues in a simulation, this often means
that the user forgot to add a bond/potential/constraint or put multiple
molecules in the same moleculetype definition by mistake.

Turning each atom into individual 'molecules/residues' would be an unpractical workaround, and from a chemical perspective simply wrong and confusing. Thus, would it be possible to remove this 'note' in future versions of Gromacs? It is super annoying when running large 'ionic' structures...

logfile.err (373 KB) logfile.err Michael Holmboe, 01/31/2017 03:55 PM

Associated revisions

Revision 4ac1f5b4 (diff)
Added by David van der Spoel over 2 years ago

Only print all dangling atoms with grompp -v

Fixes #2108

Change-Id: I28ec7498e52fb7a3a81ffcd6764e8edd3ae1b367

History

#1 Updated by Berk Hess over 2 years ago

Since such atoms are not bound to any other atom, they usually point to a mistake and can cause issues during runs.
I would think you do want to put these in separate molecule definitions. What is the issue with defining a moleculetype for every type of ion you have?

#2 Updated by Mark Abraham over 2 years ago

Alternatively, we could permit a force field to declare that it doesn't have bonded interactions, so that such a note would not be sensible to issue for such a force field

#3 Updated by Michael Holmboe over 2 years ago

Berk Hess wrote:

Since such atoms are not bound to any other atom, they usually point to a mistake and can cause issues during runs.
I would think you do want to put these in separate molecule definitions. What is the issue with defining a moleculetype for every type of ion you have?

I understand the issue for people using the normal 'bonded' forcefields. However, my own (and likely a handful of other peoples) issue with this is simply from a practical point of view, since with Clayff some bonds/interactions are defined as constraints, and some are not. Hence, when modeling periodic and multilayered systems like I do, the current Gromacs definition of a 'molecule' or 'residue' loses its practical and conceptual meaning for no good reason, and Im forced to generate slightly more elaborate index files. Thats basically it.

#4 Updated by Michael Holmboe over 2 years ago

Mark Abraham wrote:

Alternatively, we could permit a force field to declare that it doesn't have bonded interactions, so that such a note would not be sensible to issue for such a force field

That would be great. /Michael

#5 Updated by Berk Hess over 2 years ago

This could still cause issues when e.g. making molecules whole, if that applies to your case. A chemical bond can be added to avoid such issues and the grompp note as well. But such a bond does generate non-bonded exclusions, if you have nrexcl>0.

#6 Updated by Michael Holmboe over 2 years ago

Berk Hess wrote:

This could still cause issues when e.g. making molecules whole, if that applies to your case. A chemical bond can be added to avoid such issues and the grompp note as well. But such a bond does generate non-bonded exclusions, if you have nrexcl>0.

I have never had any problems before. In my particular case, since simulating periodic (usually in both x and y) layers (i.e. a mainly non-bonded molecule) which extend across the whole box, I can never make them 'whole' anyway, since periodic molecules across the box cannot be unwrapped. FYI, in the original Clayff, one uses nrexcl 1, since it contains a flexible spc-like O-H harmonic bond constraint. Some people (like me) have also extended it with other constraints, so actually it is not fully non-bonded, just predominately non-bonded.

What if one could use something like a #define statement to switch it off? Would it be possible to implement such a thing?

#7 Updated by Mark Abraham over 2 years ago

Michael Holmboe wrote:

What if one could use something like a #define statement to switch it off? Would it be possible to implement such a thing?

It would be straightforward to use an environment variable to disable actually issuing this note, which we do for some other kinds of things. That would be easier than extending the set of formal force-field descriptors.

#8 Updated by Gerrit Code Review Bot over 2 years ago

Gerrit received a related patchset '1' for Issue #2108.
Uploader: David van der Spoel ()
Change-Id: gromacs~master~I28ec7498e52fb7a3a81ffcd6764e8edd3ae1b367
Gerrit URL: https://gerrit.gromacs.org/6446

#9 Updated by David van der Spoel over 2 years ago

  • Status changed from New to Fix uploaded

#10 Updated by Berk Hess over 2 years ago

David's fix does not actually remove the note, but it does remove the line printed for every atom (which I changed to use -v iso -debug).
I and several others have waisted hours studying crashing systems only to find out later that a bond was missing in the topology, so I'd rather not remove this note completely.

#11 Updated by Mark Abraham over 2 years ago

  • Status changed from Fix uploaded to Resolved
  • Target version changed from future to 2018

#13 Updated by Mark Abraham over 2 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF