Project

General

Profile

Bug #2037

trjconv produces gro files unreadable by VMD

Added by Semen Yesylevskyy about 3 years ago. Updated 9 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
analysis tools
Target version:
Affected version - extra info:
all of them
Affected version:
Difficulty:
simple
Close

Description

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.

topol.tpr (2.4 MB) topol.tpr Semen Yesylevskyy, 08/21/2016 11:20 AM
for_eq.pdb (4.27 MB) for_eq.pdb Semen Yesylevskyy, 08/21/2016 11:20 AM

Related issues

Related to GROMACS - Task #1323: determine future of existing tools forNew
Related to GROMACS - Bug #2824: treatment of -ndec for .gro and pdb .gro files inconsistent with documentation and stdoutClosed

Associated revisions

Revision 82e0f418 (diff)
Added by Berk Hess about 3 years ago

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.

Fixes #2037.

Change-Id: I0e593622ee0380c3934a7b7b6826ae29aed00a59

Revision 83192f1d (diff)
Added by Mark Abraham 9 months ago

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 cfb3ca1f (diff)
Added by Mark Abraham 9 months ago

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

History

#1 Updated by Semen Yesylevskyy about 3 years ago

The files to reproduce

#2 Updated by Semen Yesylevskyy about 3 years ago

Well, the GRO files specification says it should be 3 decimal places for coordinates, so this is a bug in trjconv, not in VMD.

http://manual.gromacs.org/current/online/gro.html

 C format
    "%5d%-5s%5s%5d%8.3f%8.3f%8.3f%8.4f%8.4f%8.4f" 

#3 Updated by Mark Abraham about 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)

My suggested solution is to remove the notion of precision of a trajectory frame. AFAIK both PDB and GRO are intended to be written with specific numbers of digits of precision for X (3) and V (3 or 4 respectively), and G96, XTC and TNG are intended to be able to be varied, and are thus controlled by the writing software. Yet there seems to be little need for the software doing the reading to be able to read the precision. If the trajectory is being
  • 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

#4 Updated by Mark Abraham about 3 years ago

  • Status changed from New to Accepted

#5 Updated by Semen Yesylevskyy about 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 about 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.

#7 Updated by Semen Yesylevskyy about 3 years ago

Concerning definition of the format I think everybody just googles for "GRO file format" and ends up here http://manual.gromacs.org/current/online/gro.html.

#8 Updated by Gerrit Code Review Bot about 3 years ago

Gerrit received a related patchset '1' for Issue #2037.
Uploader: Berk Hess ()
Change-Id: I0e593622ee0380c3934a7b7b6826ae29aed00a59
Gerrit URL: https://gerrit.gromacs.org/6131

#9 Updated by Berk Hess about 3 years ago

  • Status changed from Accepted to Fix uploaded
  • Assignee set to Berk Hess
  • Target version set to 2016.1

#10 Updated by Mark Abraham about 3 years ago

  • Related to Task #1323: determine future of existing tools for added

#11 Updated by Berk Hess about 3 years ago

  • Status changed from Fix uploaded to Resolved

#12 Updated by Berk Hess about 3 years ago

  • Status changed from Resolved to Closed

#13 Updated by Mark Abraham 9 months ago

  • Related to Bug #2824: treatment of -ndec for .gro and pdb .gro files inconsistent with documentation and stdout added

#14 Updated by Gerrit Code Review Bot 9 months ago

Gerrit received a related patchset '1' for Issue #2037.
Uploader: Mark Abraham ()
Change-Id: gromacs~release-2019~I9f047d0b1042fa37e366ee8c99dabbb1f3458b0a
Gerrit URL: https://gerrit.gromacs.org/8923

#15 Updated by Gerrit Code Review Bot 9 months ago

Gerrit received a related patchset '1' for Issue #2037.
Uploader: Paul Bauer ()
Change-Id: gromacs~release-2018~I9f047d0b1042fa37e366ee8c99dabbb1f3458b0a
Gerrit URL: https://gerrit.gromacs.org/9012

Also available in: Atom PDF