[IUCr Home Page] [CIF Home Page]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Transfer from msCIF: refine_ls_class category




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)]


Copyright © International Union of Crystallography

IUCr Webmaster