[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Send comment to list secretary]
[Reply to list (subscribers only)]
Re: Transfer from msCIF: refine_ls_class category
- To: Multiple recipients of list <coredmg@iucr.org>
- Subject: Re: Transfer from msCIF: refine_ls_class category
- From: Brian McMahon <bm@iucr.org>
- Date: Tue, 8 Dec 1998 15:22:56 GMT
I have (at last) been looking again at the core dictionary with a view to implementing the results of our discussions on binning or sorting into classes reflections at the experimental and refinement stages. It seemed that Howard's scheme had the benefit of simplicity. In brief, the idea was as follows: introduce two new categories, DIFFRN_REFLNS_CLASS and REFLNS_CLASS, describing the data bins for experimental reflections and for those used in refinement. Individual reflections in the DIFFRN_REFLN and REFLN lists would have an associated code (_diffrn_refln_class_code and _refln_class_code respectively) linking them to a particular bin. Gotzon disapproves of the strict segregation into experimental and refinement classes, but it is possible (if desired) to introduce another data name, called something like _refln_diffrn_class_code which would flag every reflection in the refinement list with the code corresponding to the bin to which it was assigned during data collection. It's also possible to add a similar cross-link to the entries in the _diffrn_refln_ list, but I doubt that there's a real practical need for this. The question also arose of overlapping bins. It's possible to set up some compound codes such as loop_ _diffrn_reflns_class_code _diffrn_reflns_class_description A 'reflections matching criterion A' B 'reflections matching criterion B' AB 'reflections matching criteria A and B' although interpreting these would perhaps need to be programmed explicitly into an application. In summary, Howard's proposed structure is: ########################################### ## ADD TO EXISTING CATEGORY DIFFRN_REFLN ## ########################################### _diffrn_refln_class_code ---->-------->-------- ###################################### | ## NEW CATEGORY DIFFRN_REFLNS_CLASS ## | ###################################### | _diffrn_reflns_class_[] | _diffrn_reflns_class_code <--<--------<-------- _diffrn_reflns_class_description _diffrn_reflns_class_number_of_reflns_measured_all _diffrn_reflns_class_number_of_reflns_measured_gt _diffrn_reflns_class_number_of_reflns_unique_all _diffrn_reflns_class_number_of_reflns_unique_gt _diffrn_reflns_class_number_of_reflns_unique_possible _diffrn_reflns_class_percent_of_reflns_possible_all _diffrn_reflns_class_percent_of_reflns_possible_gt _diffrn_reflns_class_d_res_high _diffrn_reflns_class_d_res_low _diffrn_reflns_class_av_R_eq _diffrn_reflns_class_av_sgI/I _diffrn_reflns_class_meanI_over_sigI_all _diffrn_reflns_class_meanI_over_sigI_gt _diffrn_reflns_class_Rmerge_F_all _diffrn_reflns_class_Rmerge_F_gt _diffrn_reflns_class_Rmerge_I_all _diffrn_reflns_class_Rmerge_I_gt #################################### ## ADD TO EXISTING CATEGORY REFLN ## #################################### _refln_class_code --->------->------->--- ############################### | ## NEW CATEGORY REFLNS_CLASS ## | ############################### | _reflns_class_[] | _reflns_class_code <---------<--------<-- _reflns_class_description _reflns_class_number_of_reflns_total _reflns_class_number_of_reflns_gt _reflns_class_d_res_high _reflns_class_d_res_low _reflns_class_R_factor_all _reflns_class_R_factor_gt _reflns_class_R_Fsqd_factor _reflns_class_R_I_factor _reflns_class_wR_factor_all The fly in the ointment, however, is the existence in the core (version 2, taken over from the mmCIF dictionary) of a REFLNS_SHELL category, which describes the properties of reflections binned for refinement according to their resolution shell. The datanames in this category are listed below. I have flagged with '+' those that are similar to datanames in Howard's proposed DIFFRN_REFLNS_CLASS, and with '-' those similar to datanames in REFLNS_CLASS. _reflns_shell_[] +- _reflns_shell_d_res_high +- _reflns_shell_d_res_low + _reflns_shell_meanI_over_sigI_all + _reflns_shell_meanI_over_sigI_gt _reflns_shell_meanI_over_sigI_obs + _reflns_shell_number_measured_all + _reflns_shell_number_measured_gt _reflns_shell_number_measured_obs _reflns_shell_number_possible + _reflns_shell_number_unique_all + _reflns_shell_number_unique_gt _reflns_shell_number_unique_obs + _reflns_shell_percent_possible_all + _reflns_shell_percent_possible_gt _reflns_shell_percent_possible_obs + _reflns_shell_Rmerge_F_all + _reflns_shell_Rmerge_F_gt _reflns_shell_Rmerge_F_obs + _reflns_shell_Rmerge_I_all + _reflns_shell_Rmerge_I_gt _reflns_shell_Rmerge_I_obs Three questions: (1) Does the Group agree that I should implement Howard's scheme as it stands? Thus the REFLNS_CLASS category is an addition to the REFLNS_SHELL category, and definitions should be modified to make this explicit, e.g.: data_reflns_class_[] _name '_reflns_class_[]' _definition ; Data items in the REFLNS_CLASS category record details, for each reflection class assigned according to some criterion other than shells of resolution, about the reflections used to determine the structural parameters. Details of each resolution shell are described in the category REFLNS_SHELL. ; (2) Does the Group see at this stage a genuine need for a data name such as the suggested _refln_diffrn_class_code to identify experimental binning among the reflections listed in the refinement lists? (3) Is the Group happy with the proposed handling of overlapping bins through application-specific compound codes? and a possible fourth... (4) is there general agreement with the suggested data names in the two new categories? Regards Brian
[Send comment to list secretary]
[Reply to list (subscribers only)]
- Prev by Date: Re: Resolution limits
- Next by Date: Re: Transfer from msCIF: refine_ls_class category
- Prev by thread: Re: Transfer from msCIF: refine_ls_class category
- Next by thread: Re: Transfer from msCIF: refine_ls_class category
- Index(es):