*** For details on how to be removed from this list visit the *** *** CCP4 home page http://www.ccp4.ac.uk ***
On Wednesday 10 January 2007 13:18, [EMAIL PROTECTED] wrote: > > Quoting Ethan Merritt <[EMAIL PROTECTED]>: > > > > If this concept is taken further, one could ask why we are not > > > explicitly refining hydrogen atoms ? > > > > We are. > > At least, those who correctly use available options in refmac or shelx are. > > The best results (R, Rfree, geometry) are obtained by explicit inclusion > > of hydrogens via the riding-hydrogen model. This is also a basis for the > > Molprobity validation tools. > > This misses the point. In the riding hydrogen model, the positions of the > hydrogens are NOT explicitly refined but extrapolated in each refinement cycle > from knowledge of the positions of the other protein atoms and by assuming > ideal > geometry. It does not miss the point. It illustrates the point exactly. Because we know the hydrogens must be there (they are covalently attached) we should make our best effort at including that knowledge in the model. The correctness of our knowledge and the success of our effort is reflected by the observed improvement in objective measures like R and Rfree. The same holds for disordered sidechains. We know they must be there, and we should make our best effort to include that knowledge in the model. How best to do that is up for discussion. > The riding hydrogen model does indeed improve the geometry and R-factors, but > I > guess that not many people would write out and deposit a PDB file with > hydrogens > for a 3A structure, even if they used the riding hydrogen model during the > refinement. Because it is not necessary to do so. Storing every H coordinate generated by the riding model adds no information to the PDB file that is not already present in the parsimonious description provided by the header record: REMARK 3 HYDROGENS HAVE BEEN ADDED IN THE RIDING POSITIONS To be strictly correct, the parameters of the riding model itself could be given explicitly, but that gets us back to last week's discussion on what bits of information are *not* put in the header by refmac. In this case, however, the information is in the program code and can be retrieved if you know the code version, with *is* provided. A more serious omission IMHO is the lack of information about the scattering factors used to calculate Fcalc; they are provided by the user at run time and not permanently archived anywhere that I know of. OK, they are in the refmac log file, but they are not scavenged and saved by data harvesting for deposition.
