Molecule type as a topology attribute when reading a TPR

[jbarnoud]

TPR files produced by gromacs have a notion of molecule type. A molecule is a connected fragment, and each molecule that share a molecule type have the same template topology.

Molecule type is an interesting attributes in Gromacs topologies as it allows, among other things, to work with multi-residue molecules in a way much more elegant than chains in a PDB file for instance. Yet, not all topology format have such an attribute.

The TPR parser partially deals with molecule types as it builds the segments based on them. But the segments built by the TPR parser are not exactly equivalent to having a molecule type attribute. Also, working with segment is a pain as their meaning differs from a format to the other.

I would like to add a moltype topology attribute that the TPR parser would populate. Do you see a problem with that? Are there other formats that define an equivalent concept and that could populate the moltype attribute as well?

[mnmelo]

If the meaning of 'segment' already differs between formats I wouldn't mind overloading it for the GROMACS case, which doesn't have any other segment data.

OTOH, having ambiguous attribute semantics sucks, because it breaks a format-agnostic interface.

I'm thus divided: half for the simplicity of using the already implemented segment construct, half for keeping the abstraction pure. Someone else please chip in!

[jbarnoud]

The definition of segment is not consistent from format to format. A demonstration of this is #1496 where mmtf and pdb give different number of segments for the same structure. In the PDB format, the segment are the chain if I well remember. In the TPR parser, segments are consecutive strings of atoms with the same molecule type. Because you can have more than one consecutive string of atoms with the same molecule type, but segids must be unique, the molecule type is prefixed with `seg_<some serial number>`. What I like with having a `moltypes` attribute, is that it is semantically well defined. It would also be populated only for the formats that define it. For now, we only have TPR that I know defines such concept; TNG defines it too. Other topology format may define it too, I just do not know which one.

…

On 07/24/2017 04:00 PM, mnmelo wrote: If the meaning of 'segment' already differs between formats I wouldn't mind overloading it for the GROMACS case, which doesn't have any other segment data. OTOH, having ambiguous attribute semantics sucks, because it breaks a format-agnostic interface. I'm thus divided: half for the simplicity of using the already implemented |segment| construct, half for keeping the abstraction pure. Someone else please chip in! — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#1555 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABUWukNUT8tQ0tFljQSqzrci0jXjqUp1ks5sRKOAgaJpZM4OhGzi>.

[richardjgowers]

Yeah this is pretty tricky. It's nice to have consistent names for things across formats, so that we're format agnostic, but then we also want to incorporate all information available in the topology and provide the format specific information that a gromacs user may reasonably expect.

[kain88-de]

I have a question. Do we ever mark what fields are specific to a format? Are there any docs highlighting the difference or similarities when a specific topology is parsed. I assume there are still a good amount of little gotchas involved from time to time.

[richardjgowers]

@kain88-de there is a table with that here: https://github.com/MDAnalysis/mdanalysis/blob/develop/package/MDAnalysis/topology/__init__.py