r_free_flags.export_for_ccp4 option of iotbx.reflection_file_editor
Dear PHENIX developers, 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. I look forward to your response, Keitaro
On Fri, Mar 25, 2011 at 1:14 AM, Keitaro Yamashita
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
I was wondering about do we really need this option at all -:) Converting the flags conventions is simple but dirty work. I guess it would be much better if the respective programs are smart enough to recognize the input flags conventions or at least provide an option so the user can specify it. I guess most of the programs do that. Pavel. On 3/25/11 8:58 AM, Nathaniel Echols 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
On Fri, Mar 25, 2011 at 1:14 AM, Keitaro Yamashita
wrote: 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 _______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb
Dear Nat,
Good point - this does not appear to be difficult to change, so I will do this now.
I'm very happy to hear it. Thank you for your consideration. As Pavel said, converting flag convention is dirty work, but I think it's sometimes useful. (For some programs which assume ccp4 freeR-flag convention) So I hope this function will be maintained.
I suspect (I hope) that the flag value completion in CCP4 will only look at the %free, not the counts of all values,
Reading the manual of freerflag (ccp4 program), I found this description: "The fraction of data per bin is taken from the highest value of the freeR flag" when completing existing freeR flags. http://www.ccp4.ac.uk/html/freerflag.html
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.
Yes, this is very helpful! Cheers, Keitaro
participants (3)
-
Keitaro Yamashita
-
Nathaniel Echols
-
Pavel Afonine