Short-term reason: When we write out a system/trajectory, people will expect to be able to slice the topology in nice ways, using residue names and such.
In the long run, we may want to support atom-type based parameter assignment.
DD – Hierarchies are tricky and can fall out of date. Should at least store metadata on the atom level, and then the hierarchy can just provide a view of atom groups.
JW – Strongly agree
DD – It’s reasonable to get two residues as the result of a single query. These can indicate important things like sequence position in the original protein.
There should be a lot of flexibility in how to maintain metadata in merge_molecules
Can an atom be part of more than one residue?
Should an atom know which HierarchyElements it’s part of?
Can merge_molecule maintain iterators (append the second mol’s iterators to the first’s?)
Is there any need to run percieve_hierarchy in a way that preserves information from before?
(Most notes taken on IP’s notebook)
What about multiple molecules? Notebook only talking about single molecules.
We need reverse look ups (get residues from atoms and vice versa). Not just the name.
Can a residue contain multiple molecules? Distinction between molecule hierarchy and topology hierarchy?
topology.topology_molecules[0] → one indexing system
<HierarchyScheme with iterator “hier_mols” …>
topology.hier_mols[0] → another indexing system, determined by atom metadata
Will a residue know its bonds? Will it know its bonds to other residues?
Will the assignment of “amber-ish” atom types + residue names play well with output formats? Do parameter lookups go through (atom type) or (atom type, residue name)? In the former case, we’ll need to solve the atom type compression problem.
Figure out how virtual sites
Make sure that merge molecules will actually work with proton addition/removal
Prepare a pair of alchemically related systems, providing an atom map.