To follow pdb conventions, a patch that renames the type attribute to name attribute in both AtomDecerator and ResidueDecerator is attached.
>>>> On Feb 12, 2008, at 4:56 PM, Daniel Russel wrote: >>>> >>>>> <02.fix_atom_name_in_pdb> >>>> >>>> _______________________________________________ >>>> IMP-dev mailing list >>>> IMP-dev@salilab.org >>>> https://salilab.org/mailman/listinfo/imp-dev >> >
Keren Lasker wrote: > To follow pdb conventions, a patch that renames the type attribute to > name attribute in both AtomDecerator and ResidueDecerator is attached.
Why should we follow PDB conventions anyway? And I have a couple of other problems with this proposed patch: 1. The residue type really is a type. All THY residues are thymines, for example - it's not an arbitrary name. 2. The atom type could be argued to really be 'name', since, for example, AT_CG1 and AT_CG2 are both carbon, and this is orthogonal from the CHARMM forcefield type (probably CT2 or CT3). But the name does determine the element, so could easily be described as 'type'. And if you go down that route, you have to go all the way, also renaming AtomType to AtomName. In this patch you end up with methods like void set_name(AtomType t) which seems weird to me. Either it should be set_type(AtomType) or set_name(AtomName).
What do others think?
Ben
Ben Webb wrote: > Keren Lasker wrote: > >> To follow pdb conventions, a patch that renames the type attribute to >> name attribute in both AtomDecerator and ResidueDecerator is attached. >> > > Why should we follow PDB conventions anyway? And I have a couple of > other problems with this proposed patch: > 1. The residue type really is a type. All THY residues are thymines, for > example - it's not an arbitrary name. > I generally agree with you for those reasons (obviously, I guess, since I did it that way). However, calling it name seems to be more common (not that I have done an exhaustive survey). If there really is a strong convention, we probably should follow that.
> 2. The atom type could be argued to really be 'name', since, for > example, AT_CG1 and AT_CG2 are both carbon, and this is orthogonal > from > the CHARMM forcefield type (probably CT2 or CT3). In modeller this data is stored as name, I guess that you know better the reasons for that - so the conversion is: ap.set_type(IMP.AtomType(a.name)) We should just use what ever is the convention - which I thought was name, but if not than we can leave it as it is.
Keren Lasker wrote: >> 2. The atom type could be argued to really be 'name', since, for >> example, AT_CG1 and AT_CG2 are both carbon, and this is orthogonal from >> the CHARMM forcefield type (probably CT2 or CT3). > In modeller this data is stored as name
Indeed - the name of the atom largely determines its type, so the two are somewhat intertwined.
> We should just use what ever is the convention - which I thought was > name, but if not than we can leave it as it is.
As with everything related to PDB, I don't think there is any kind of convention.
Ben
fine - I personally prefer name, but you are the boss :) On Feb 13, 2008, at 4:35 PM, Ben Webb wrote:
> Keren Lasker wrote: >>> 2. The atom type could be argued to really be 'name', since, for >>> example, AT_CG1 and AT_CG2 are both carbon, and this is orthogonal >>> from >>> the CHARMM forcefield type (probably CT2 or CT3). >> In modeller this data is stored as name > > Indeed - the name of the atom largely determines its type, so the two > are somewhat intertwined. > >> We should just use what ever is the convention - which I thought was >> name, but if not than we can leave it as it is. > > As with everything related to PDB, I don't think there is any kind of > convention. > > 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
participants (3)
-
Ben Webb -
Daniel Russel -
Keren Lasker