The R-factor difference of 0.0004 is what you have to expect as the result of writing the coordinates, B-factors, and occupancies to the PDB file. In memory floating-point numbers have >= 12 digits precision (we use double precision for almost everything); in the PDB file you have only 7 digits for the coordinates and just 5 digits for the B-factors and occupancies.
Ralf

On Fri, Mar 23, 2012 at 9:49 AM, Christian Roth <christian.roth@bbz.uni-leipzig.de> wrote:
Hi Nat,

I agree with you that the difference is very small and likely negligible. I
just asked for curiosity if there might be any reason for this behaviour.

Christian

Am Donnerstag 22 März 2012 23:07:33 schrieb Nathaniel Echols:
> On Thu, Mar 22, 2012 at 2:54 PM, Christian Roth
>
> <christian.roth@bbz.uni-leipzig.de> wrote:
> > I am not sure I looked into the polygon. In the log it is stated that the
> > R values are calculated after a resolution and sigma cutoff applied.  If
> > I understood the log correctly the values taken from the pdb header are
> > without sigma cutoff. Maybe thats the reason for the difference. Does
> > modelvsdata somewhere print the values without cutoff in the log file? I
> > did not find it. However does this mean till firsst OHS in phenix refine
> > a default cutoff is used and in than throughout the refinement no coutoff
> > is used anymore?
>
> After spending some time looking at similar cases today I am not sure
> myself what is going on.  I do not think a sigma cutoff is applied,
> unless perhaps the PDB header indicates that one was used previously
> (this is a thoroughly antiquated practice).  However, outlier
> filtering appears to be used throughout.  I found one example where
> nearly 4000 reflections have amplitudes of zero (which is surely not
> correct), and are discarded as outliers in phenix.refine.  This
> reduces R-free by 0.03.  In model_vs_data, the same numbers appear
> twice:
>
>   Model_vs_Data:
>     r_work(re-computed)                : 0.2030
>     r_free(re-computed)                : 0.2639
> ...
>   After applying resolution and sigma cutoffs:
>     n_refl_cutoff : 31257
>     r_work_cutoff : 0.2030
>     r_free_cutoff : 0.2639
>
> But this totally contradicts what I told you earlier, sorry.  I was
> assuming that they would be different.
>
> I do have a general piece of advice, however: ignore the discrepancy,
> and just report the value that came out of refinement (because that is
> what will end up in the PDB).  The difference in your case is
> relatively small, probably less than what you'd see if you calculated
> R-factors with (for instance Refmac), because of different
> implementations of bulk solvent correction and scaling, etc.*.  (Even
> different versions of Phenix aren't guaranteed to yield identical
> R-factors, due to low-level changes.)  Considering how difficult it
> can be to reproduce the statistics in published structures, a change
> of 0.0004 isn't enough to worry about.
>
> -Nat
>
> * http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2906258/?tool=pubmed
> _______________________________________________
> phenixbb mailing list
> phenixbb@phenix-online.org
> http://phenix-online.org/mailman/listinfo/phenixbb
>


_______________________________________________
phenixbb mailing list
phenixbb@phenix-online.org
http://phenix-online.org/mailman/listinfo/phenixbb