So where do we stand? The key question is what do we want AtomType to mean?
A couple of options: 1) - we use PDB atom types for AtomType - AtomType is only guaranteed to be unique when paired with the ResidueType or XXXType of its parent (we need LigandType or something) - code that creates atoms must fill in element for all atoms it creates (so add another argument to the setup_particle function) - we could later add a function that generates a unique atom type by combining the parent type and the atomtype - we don't have to parse the whole dictionary unless we want to get other information about the ligands or to fix broken names
2) - we generate unique atom types by prefixing the pdb atom types with, for example, the residue name - AtomType is then globally unique
I would vote for 1 but don't feel too strongly either way. We should probably get input from Hao too.
On Aug 7, 2009, at 11:49 AM, Dina Schneidman wrote:
> yes, that's of course the ultimate solution. > I wanted to do that, however changed my mind when I saw the size of > this dictionary. > It seems not reasonable to load it for each PDB parsing. > However I do think it will be nice to have it as optional. > > On Fri, Aug 7, 2009 at 11:47 AM, Ben Webbben@salilab.org wrote: >> On 08/07/2009 11:42 AM, Dina Schneidman wrote: >>> >>> Do you mean to his dictionary of chemical components? >>> www.wwpdb.org/ccd.html >> >> Yes, that looks about right. Their Ligand Expo tool will even give >> you >> pretty pictures of a given residue. >> >> Ben >> -- >> ben@salilab.org http://salilab.org/~ben/ >> "It is a capital mistake to theorize before one has data." >> - Sir Arthur Conan Doyle >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev >> > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev