>> 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).