How to use information in topology files

[kain88-de]

It has come up in #941 and #815 that we do have a problem with abstracting the away the differences between topology formats because they save different information. There are in two types of problems

1. Set of common properties
In #815 I noticed that I right now write code under the assumption that a field like masses is always available even if they are not specified in the topology (eg PDB). While the new topology system only provides data actually present in the topology.

2. properties specific to a format
In #941 @jbarnoud noted that he would like to make all information in a topology available to the user. This means going away from being completely format independent.

To me this suggests that we need to make a list of properties that are always available independent of the format and a special property under which we can add format specific properties like so: ag.special.format_properties.

What do others think for this? Should we have properties like masses, charges always available with a guess function for some format?

[jbarnoud]

Since you mention guesses, I link #507 for the record.

[orbeckst]

In general I like being able to work with reasonable automatic guesses if

1. code informs me (or fails properly) when this cannot be done confidently (we as the developers have to discuss what we consider "confidently")
2. I have the opportunity to override or provide information to make sure I get exactly what I want, e.g. if I care about calculating dipole moments I must make sure that I get the charges that I consider correct
3. ideally the code informs me about how to do 2 if 1 cannot be safely done

[richardjgowers]

I think I'm in very much favour of 2. If someone provides a file full of information we should make it all available. Some stuff might not work, but as long as this is properly documented (ie what you need to provide for each calculation) it should be fine. If you only provide an XYZ as your topology, you can't go crying when Resname based stuff doesn't work!

WRT masses, I think we've removed that currently in 363 just because we've not implemented guessers yet. I'd happily backtrack on this because they can be guessed with a fair degree of confidence

[kain88-de]

If you only provide an XYZ as your topology, you can't go crying when Resname based stuff doesn't work!

But we should fail with an error message saying that this isn't available information in the chosen topology instead of just throwing an attribute error.

Another thing is this makes code fragile that depends on MDAnalysis. We should have a defined set of values that have to exist independent of the topology and a set of values that are guessed when non are found. This will help a lot for people who write their own libraries on top of MDAnalysis.

[richardjgowers]

So we could hack into the __getattr__ a list of known possible failures, so if resname fell through to here we could provide a better error message. I don't like the current practice of setting the default segid to "SYSTEM", I'd rather have try/excepts when segids are to be used.

[kain88-de]

I think we should start a wiki page where we document names and what default behavior we expect from them. A wiki page might be easier to handle as an overview than a long issue thread. The discussion can still happen here.

[mnmelo]

In #598 I'm working on implementing the guessers for #363. Some decisions must be made at this point, even after choosing option 2. above. I need feedback for the following:

• What critical attributes should be present, even if the topology doesn't provide them?
• When unavailable, should these critical attributes:
  • be guessed?
  • left at some non-guessed default? (This is the behavior for bonds as of 15.0: loading a .gro file creates u.atoms.bonds as <TopologyGroup containing 0 Nones>)

[richardjgowers]

I guess a good starting point is to try and follow the previous api. So all attributes that had to exist before are handled gracefully when they do not exist. This can probably get done through hacking into __getattr__ and adding a list of special error messages.

Eg if I try and access .resnames from my xyz file, I should get a special message regarding their absence. I prefer this over a placeholder entry, as it doesn't fill up the namespace unnecessarily.

WRT masses, if these are guessed by default, they should still raise some sort of warning on Universe creation (Warning: Guessing masses according to 'Gromos' basis)

Bonds/Angles/Dihedrals are kind of a special case as they don't belong to the Atoms in the same way as masses, so they deserve their own first class position like residues and segments have. If this is then an empty container, that then makes idioms like if u.bonds: work intuitively.

[mnmelo]

I don't agree with the if u.bonds construct by default. It seems pythonic but doesn't tell you whether the container is empty because it wasn't guessed or empty because you have a Lennard-Jones fluid system that really has no bonds.

I'd propose to let the user decide whether to guess bonds or not at Universe creation time (or later). For the case of topologies that do provide bond information, we might include a kwarg that allows the user to specify which bonds to keep: the topology's, the guessed ones, or one complementing the other. After this, if u.bonds will work just the same, but much more meaningfully.

[mnmelo]

Anyway, summarizing this thread: attributes that are absent from the topology at Universe creation time can fall in one of four categories:

1. Left out of the Topology, with an AttributeError on accession (like the specialized attributes from specific formats @jbarnoud proposes to keep);
2. Left out of the Topology, but with a nice error on accession, perhaps suggesting how to set/guess values (like resnames);
3. Added to the topology, set to a dumb default (like currently bonds for .gro or resids for .xyz);
4. Added to the topology, guessed, possibly with a warning.

Let's then decide which attributes go into each category? What's the best way to gather a consensus vote for this, a shared Google Docs spreadsheet or @kain88-de's suggestion for a Wiki page?

[richardjgowers]

I guess make a wiki page so it's all on the repo still

[mnmelo]

There, I made a wiki page at https://github.com/MDAnalysis/mdanalysis/wiki/Topology-attribute-handling
Let's see how it goes.