Hi Keitaro,
Currently, R-work and R-free are 22%, 24%, respectively (with twin_law) at 2.5 Angstrom resolution.
the difference between Rfree and Rwork seems to be suspiciously small given the resolution. Here is the typical distribution of Rfree, Rwork and Rfree-Rwork for structures in PDB refined at 2.5A resolution: Command used: phenix.r_factor_statistics 2.5 Histogram of Rwork for models in PDB at resolution 2.40-2.60 A: 0.115 - 0.141 : 5 0.141 - 0.168 : 81 0.168 - 0.194 : 492 0.194 - 0.220 : 1100 0.220 - 0.246 : 808 0.246 - 0.273 : 166 0.273 - 0.299 : 25 0.299 - 0.325 : 5 0.325 - 0.352 : 0 0.352 - 0.378 : 1 Histogram of Rfree for models in PDB at resolution 2.40-2.60 A: 0.146 - 0.178 : 4 0.178 - 0.210 : 48 0.210 - 0.242 : 483 0.242 - 0.274 : 1273 0.274 - 0.305 : 750 0.305 - 0.337 : 116 0.337 - 0.369 : 8 0.369 - 0.401 : 0 0.401 - 0.433 : 0 0.433 - 0.465 : 1 Histogram of Rfree-Rwork for all model in PDB at resolution 2.40-2.60 A: 0.002 - 0.012 : 30 0.012 - 0.022 : 93 0.022 - 0.031 : 266 0.031 - 0.041 : 502 0.041 - 0.051 : 531 0.051 - 0.061 : 580 0.061 - 0.071 : 349 0.071 - 0.080 : 202 0.080 - 0.090 : 93 0.090 - 0.100 : 37 Number of structures considered: 2683 Did you use PHENIX to select free-R flags? It is important.
In my understanding, least square target function has very poor convergence since it is much biased to the current model.
ML is better than LS because ML better account for model errors and incompleteness taking the latter into account statistically.
I'm afraid refinement couldn't converge correctly with twin_lsq_f.
It may or may not, depending how far your current model is from the correct one. Small molecule folks use LS all the time.
This is why I thought it could be better to refine without twin_laws for first several cycles.
You may try, but in that case you will not be accounting for twinning. By the way, if you run the command: phenix.model_vs_data model.pdb data.mtz does it suggest that you have twinning?
The next CCN (Computational Crystallography Newsletter; http://www.phenix-online.org/newsletter/) that comes out beginning of January will contain an article about using ML target in twin refinement, which will be implemented in some (hopefully near) future. I'm looking forward to using it. Will it be different formulation from Refmac?
I do not know what's implemented in Refmac - I'm not aware of a corresponding publication.
Not sure, can you send (off-list) logfile of that run? This is weird... If you could send me the inputs that I can use to reproduce this problem then I will be able to explain what is going on. I'm sorry, the model under refinement must be kept confidential so I could not give it to you.
Typically, when people send us the "reproducer" (all inputs that are enough to reproduce the problem) then we can work much more efficiently, otherwise it takes a lot of emails before one can start having a clue about the problem.
But in log file, twin_law keyword is definitely accepted:
Command line parameter definitions: refinement.input.xray_data.labels = F,SIGF
refinement.refine.strategy = individual_sites+individual_adp
refinement.twinning.twin_law = -k,-h,-l However, the refinement target is still ml:
=============================== refinement start ============================== ... | maximum likelihood estimate for coordinate error: 0.37 A | | x-ray target function (ml) for work reflections: 6.900796 | |-----------------------------------------------------------------------------|
I could reproduce this myself, this is a bug. Sorry for the problem. A work-around for you now is to remove the PDB file header (all REMARK 3 records) from the input PDB file. This problem will be fixed in the next available PHENIX version.
Does phenix.refine read some informations from pdb file other than coordinates?
Yes, and this was the root of the problem. This is why I suggested to remove the REMARK 3 records from PDB file header. All the best! Pavel.