On Sun, Jun 3, 2012 at 4:17 AM, 周文昌
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