I changed my previously proposed mda.Merge to align more closely with
the old Merge behavior, in that it preserves the atom order as given to
Merge. Given the introduction of residue and segment indices (distinct
from ids), the behavior of this new Merge assigns separate residue and
segment indices to each argument of Merge. That is, if two arguments to
merge are atomgroups from the same universe with the same residue
indices, in the post-merge universe, they will have different residue
indices. If the user doesn't want this, s/he should add together the
atom groups before merging.
My understanding is that resid is just an attribute of a residue,
whereas the residue index is the unique identifier of that residue
instance. I didn't think it would make much sense for Merge to duplicate
atoms by giving them different indices while keeping their residue
indices the same, such that you have doubled or tripled (etc.) the
number of atoms in a residue or segment.
Before I was sending the per-atom segment indices to Topology instead of
the per-residue segment indices. Topology.__init__() or
TransTable.__init__() should probably check that the correct length
index arrays are passed on.
I added an attribute to the TopologyAttrs called `per_object` where the
value of this attribute is 'atom', 'residue', or 'segment' if the length
of the TopologyAttr value should equal n_atoms, n_residues, or
n_segments. The Universe method `_process_attr` now checks if the
TopologyAttr has `per_object` attribute, and raises a ValueError of the
length of the value array is not as expected.
Finally I updated `test_modelling.py`. This actually increased the
number of errors raised during testing by 2, because instead of stopping
at an error in the first few lines of the test file, it goes on and
errors occur for Capping and `atoms.write`.