Bug #2824

Updated by Michael Shirts about 1 year ago

the flag -ndec is silently ignored by trjconv in the creation of .gro files. This is in contrast to behavior in at least 5.1.3, where -ndec worked, and the manual (, which states "The precision is always taken from -ndec, when this option is set." It also says "The precision of the .xtc output is taken from the input file for .xtc, .gro and .pdb, and from the -ndec option for other input formats" which is somewhat in conflict, but it's not true either.

Note that the stdout still SAYS the output precision is what is set by -ndec, i.e. it says: "Setting output precision to 1e-10 (nm)." And no warnings are issued that -ndec is ignored.

Looking at the gmxio.c logfile message written by Berk on Aug 23 2016, it says
"The gro precision is now fixed to 3, 4 and 5 decimal places for
x, v and box respectively to ensure compatibility with other software.
Variable precision reading is still supported."

More discussion was in issue #2037 - basically, it seems to be because VMD was coded to use a fixed format, so more precision broke it, and some of the original documentation said the format was fixed (though gromacs itself didn't), it was changed to fixed format.

Editorial: This broke a number of our scripts (silently, until I tried to figure out why crystal packings now had a bunch of noise in them). I do think it's problematic that g96 is the only ascii file version left with definable precision. This means g96 is the only human readable way what the coordinates are to machine precision (and nobody uses that). We run a number of analyses scripts where we just parsed high-precision ASCII files, which worked great. ASCII is limited precision, but it's always portable. 3 digits of precision is not sufficient to actually work with things (minimization doesn't actually give minimized output if the output is three digits of precision).

We'll have to see how easy it is to use 3rd party tools to extract trr into Python for other types of analysis that need high precision for the future (I guess we could use .g96, but that could change as well, presumably, and there aren't any tools that use it already), though that adds complexity. .tng is also an option, but doesn't seem to be many .tng reading libraries out there (mdtraj doesn't do it).

For now, I think we'll just using an old version of gromacs to do it, since the .trr is back-compatible. That's a trivial workflow change.

Would be interesting to know what other people now do to get analysis of coordinates into Python (or other non-gromacs code).

I guess I can't complain too much since I missed the 2016 conversation on this issue (probably was getting ready to teach general chem for the first time that semester).

But at least the documentation and the program output should be updated to state what it is going on (i.e. -ndec is ignored for .gro and .pdb).