[phenixbb] r_free_flags.export_for_ccp4 option of iotbx.reflection_file_editor

Nathaniel Echols nechols at lbl.gov
Fri Mar 25 08:58:43 PDT 2011


On Fri, Mar 25, 2011 at 1:14 AM, Keitaro Yamashita
<yamashita at castor.sci.hokudai.ac.jp> wrote:
> I'm using phenix-1.7-650 (current latest).
>
> I noticed that r_free_flags.export_for_ccp4 option of
> iotbx.reflection_file_editor, which convert flag convention to ccp4
> style, does always assign 1..19 to working set at random.
>
> In CCP4 style, I think working set flag numbers should be
> 1 .. (1 / fraction - 1).
> Otherwise, I'm afraid it might have a bad influence on further
> processing e.g. flag value completion using ccp4 program.

Good point - this does not appear to be difficult to change, so I will
do this now.  In all honesty, that option is a huge hack - I wasn't
happy about adding it, but we've been unable to convince anyone else
to make their programs more automatic in identifying the correct flag.
 I suspect (I hope) that the flag value completion in CCP4 will only
look at the %free, not the counts of all values, but I haven't looked
at their code to confirm this.  That said, we recommend using Phenix
to extend existing flags anyway, because Phenix will take lattice
symmetry into account by default, preventing twinning-related bias
problems.  (You can still make it output the flags in CCP4 format when
doing this.)

The one warning I have about this option is that the propagation of
other (non-test) values is not guaranteed, i.e. the test set '0' will
always be preserved, but what is '7' in the input may not be '7' in
the output.  The 'preserve_input_values' option will propagate
unmodified R-free flags, but extending the flags will break this.
(I'm not sure why - that's what I have written in the code - but I'll
see if it's fixable too.)

-Nat



More information about the phenixbb mailing list