[phenixbb] R/Rfree can not be reproduced
Nathaniel Echols
nechols at lbl.gov
Sun Jun 3 08:27:04 PDT 2012
On Sun, Jun 3, 2012 at 4:17 AM, 周文昌 <wenchangyu2006 at gmail.com> wrote:
> I had a weird case in which I can not reproduce the R/Rfree value for the
> same refinement. "same" means I run my refinement first and then I rerun
> with "phenix.refine *.eff --overwrite". The R/Rfree values for the two cases
> are different (0.2942/0.3190 vs 0.2942/0.3085). Should not they be the
> same always?
Not necessarily. When phenix.refine writes out the parameter file,
some floating-point (decimal) numbers in the parameters end up with
less precise values than they started with. The most specific example
I can think of is a parameter whose default is "1/3", which is
internally converted to 0.333333...., which is truncated to only ten
digits after the decimal place when the parameter file is written out.
When you read the parameter file back in, the imprecise value
overrides the default. Since this particular parameter controls the
grid spacing for the FFT structure factor calculations, it can change
both the calculation of target (i.e. R-factor) values and gradients,
which can and does lead to a different result. When Jeff and I
figured this out recently we were quite surprised by how large a
difference it can make.
If you want to avoid this, you have two choices:
1. Don't use the complete parameter file - only use those parameters
you really care about and ignore the ones that are (theoretically)
unmodified.
2. Find that parameter (whose name I forget at the moment) and always
set the value to 0.25, which will lack the truncation effect. This
will also make your refinement more accurate because it's sampling the
FFT more finely. It will also make your refinement much slower and
take up twice as much memory.
I guess this is another question for the FAQ list...
-Nat
More information about the phenixbb
mailing list