I think the wiki page with the attributes says it all--it is just
a general tree. You have parent and child "pointers", a counter
for how many children and a parent index and a string naming what
sort of thing you are. I am pretty sure we shouldn't have anything
less general (unless we want to fix that a residue always has a
chain as a parent) and unless you want to support DAGs, I am not
sure what a more general thing to support is.
Well, I was thinking from the other direction - a container class
which can contain particles and/or other containers. So for
example, a rigid body would be a simple container of particles, a
residue would be similar, while a chain would be a container of
residues. (Whether you have an actual Residue class derived from
Container, and whether it's done at the C++ or Python level, is
debatable.) The two approaches are, of course, essentially equivalent.
But containers need to support attributes. So they are then simply a
type of particle which also has a list of other particles in it (and
a separate list of other containers, since we need containers to be
nested). I really don't see the need over just storing the things in
attributes.
If the wiki page is going to be the only information I can work on,
here are my concerns with it thus far: ;)
- It seems odd to me to treat a bond as a 'particle'. Would you do
angles and dihedrals in the same way?
Sure. We need a place to put things. We provide a class of objects
(namely Particles) which have centralized memory management which
allows for fields to be optimized and (eventually) for the whole
Model to be stored and reloaded and such. So we should use these
objects. Adding another type of object just complicates things
without adding any benefit.
- Is Residue just an example of a member of a hierarchy, or would
chains and proteins be treated differently?
A tree node is a tree node. It can happen to also have some
biological function, but that is orthogonal to being a hierarchy node.
- How would you deal with references to particle IDs to turned-off
particles? "PI" is just an Int variable, right?
Check if the particle is turned on or off? Seems the same as with any
other system.
- If I wanted to pull out every atom in residue 1, I'd really have
to scan through every single particle to figure out which ones a)
have a residue attribute and b) have it = 1 ? That seems inefficient.
You would find the particle for residue 1 and get "child_0",
"child_1"...
I don't think you should ever have to scan through all particles
(and, personally, I don't think you should be able to as it would
encourage bad habits).