> >> Identifying atoms via their PDB names and the type of their parent >> as is >> currently sort of done, works fine. > > Sure, but what we call the atom type isn't the atom type - it's the > name. Sure it is. Why do you say it is not? It happens that the proposed type is derived from the PDB name and only makes sense within the context of the surrounding molecule and hence very structure focussed rather than chemistry focused. But that doesn't make it any less a type.
- It is canonical - it provides a fine enough labeling of the atoms that we can determine what we need to determine about them - it has the virtue of being similar to something everyone is familiar with - there doesn't seem to be a standard convention for assigning atom types (every bit of software seems to do its own thing) etc.
> It would make more sense to use the particle name for that purpose, > therefore, and put real type information (e.g. CHARMM or Mol2 atom > type name, element) in a "real" AtomType. Why would this make more sense?
The issue that the user has to provide some identifier for atoms when they create them. This identifier needs to be enough such that, which we have a full structure, all other information can be derived from it. If possible (and it is) there should be only one such piece of information. If the user just provides the CHARMM atom type, then there is no way to figure out bonds for a residue or the PDB atom names. If we use the PDB name-derived types, then IMP can determine the CHARMM atom type, bonds, use other forcefields, etc.
If some piece of code wants chimera atom types, it can easily derive them from the PDB atom types (and possibly store them back in the Particle).
What am I confused about?