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 (http://manual.gromacs.org/documentation/2019/onlinehelp/gmx-trjconv.html), 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). *(from redmine: issue id 2824, created on 2019-01-04 by mrshirts, closed on 2019-01-08)* * Relations: * relates #2037 * Changesets: * Revision 83192f1d6c7a1885879292a140d75dce0a648d23 by Mark Abraham on 2019-01-08T09:41:14Z: ``` Fix trjconv -ndec This only works with XTC writing, but the documentation and implementation was wrong. That mean that the terminal feedback to the user was also wrong when writing a .gro file. Fixes #2824 Refs #2037 Change-Id: I9f047d0b1042fa37e366ee8c99dabbb1f3458b0a ``` * Revision cfb3ca1f2fd30466e1898f7d80792159cbc2f4a5 by Mark Abraham on 2019-01-21T15:39:15Z: ``` Fix trjconv -ndec This only works with XTC writing, but the documentation and implementation was wrong. That mean that the terminal feedback to the user was also wrong when writing a .gro file. Fixes #2824 Refs #2037 Change-Id: I9f047d0b1042fa37e366ee8c99dabbb1f3458b0a ```