[phenixbb] Questions about phenix.refine with twin_law

Pavel Afonine pafonine at lbl.gov
Sun Dec 26 09:49:47 PST 2010


  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.




More information about the phenixbb mailing list