trjconv produces gro files unreadable by VMD
Given tpr and pdb files attached I'm doing the following:
gmx trjconv -f for_eq.pdb -o trjconv.pdb gmx trjconv -f for_eq.pdb -o trjconv.gro
i.e. I'm just converting the same file for_eq.pdb to either pdb or gro.
When opening trjconv.gro in VMD it is corrupted completely, while trjconv.pdb is completely fine.
When I'm doing the same conversion with editconf the gro file IS readable:
gmx editconf -f for_eq.pdb -o editconf.gro # VMD is fine with this
The only difference between editconf.gro and trjconv.gro which I see is the number of decimal places:
trjconv.gro: 1SM1 N 1 8.2780 8.3948 5.6172 editconf.gro 1SM1 N 1 8.278 8.395 5.617
It seems that additional digits broke VMD gro files parser badly. This may be the bug in VMD rather than in Gromacs, but given the popularity of VMD it is better to make it happy.
The obvious solution is to make trjconv behave exactly as editconf.
Remove variable precision gro writing
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.
#3 Updated by Mark Abraham over 3 years ago
- Affected version - extra info set to all of them
Thanks. For a workaround you can do
gmx trjconv -f for_eq.pdb -o trjconv.gro -ndec 3.
There's at least three aspects to this problem:
1) the code maintains a precision field for each trajectory frame (but it should probably only do that for G96, TNG and XTC writing, and not as a per-frame data member)
2) reading from PDB arbitrarily sets the precision to 4 digits
3) writing to GRO from trjconv honours whatever precision is found (while editconf imposes 3 digits for GRO)
- converted between formats, then the writing software typically needs to honour the user's request,
- consumed in analysis then there's probably no value in knowing the precision, and
- subsampled without changing format, then the output frame should be identical to the input frame (but this should consider precision only for formats where that is natural).
However, trjconv does both the first and third dot points, for many data formats, so there is no clear way to resolve this tension until we break up trjconv into several parts. Then we can e.g. handle subsampling without having to worry about representing the data in a format that can be read and written between all file formats
#5 Updated by Semen Yesylevskyy over 3 years ago
Thank you for workaround!
Keeping precision is probably useful in general. The actual problem is that trjconv doesn't respect GRO file format specification (%8.3f for coordinates). GRO writer should just disregard the frame precision and write %8.3f hardcoded. In such case gro files from all tools would be the same and respecting the format.
It would also be very useful to display a warning if user tries to force precision for fized-format files like GRO and PDB. Something like "You are trying to set precision for fixed-format file. Precision 3 is forced by file type."
#6 Updated by Berk Hess over 3 years ago
we used to support different precision gro files. This is a matter of who defines the standard (and I guess strictly speaking this is a Gromos file format). Anyhow, it's probably better to only allow writing .3 precision for gro. I don't think pdb supports different decimal places, so there should be no issue there.
I added the precision to the trx frame. I think we still need such a thing, since if we read from gro, pdb or xtc, we don't want to write more, and probably also by default not fewer, decimals to xtc or tng than the precision we have.