[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 <[email protected]>
- Subject: Re: Transfer from msCIF: refine_ls_class category
- From: Brian McMahon <[email protected]>
- 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):

