Discussion List Archives

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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: Thu, 3 Sep 1998 11:58:18 +0100 (BST)

There are a number of other categories and individual data names in the
proposed msCIF dictionary that are also potentially general enough to be
transferred to the Core. Here is a list of the data names - their intent is
probably clear enough, but I'll post the full definitions if people need to
see them.

   _diffrn_reflns_number_of_classes
   _diffrn_reflns_class_[]
   _diffrn_reflns_class_av_R_eq
   _diffrn_reflns_class_av_sgI/I
   _diffrn_reflns_class_number_of_reflns
   _diffrn_reflns_class_d_res_high 
   _diffrn_reflns_class_d_res_low 
   _diffrn_reflns_class_description
   _diffrn_reflns_class_code
   _reflns_class_[]
   _reflns_class_number_of_reflns_total 
   _reflns_class_number_of_reflns_gt 
   _reflns_class_code
   _reflns_shell_class_[]
   _reflns_shell_class_d_res_high
   _reflns_shell_class_d_res_low
   _reflns_shell_class_meanI_over_sigI_all
   _reflns_shell_class_meanI_over_sigI_gt
   _reflns_shell_class_number_measured_all
   _reflns_shell_class_number_measured_gt
   _reflns_shell_class_number_possible
   _reflns_shell_class_number_unique_all
   _reflns_shell_class_number_unique_gt
   _reflns_shell_class_percent_possible_all
   _reflns_shell_class_percent_possible_gt
   _reflns_shell_class_Rmerge_F_all
   _reflns_shell_class_Rmerge_F_gt
   _reflns_shell_class_Rmerge_I_all
   _reflns_shell_class_Rmerge_I_gt
   _reflns_shell_class_code

For all of these, the questions posed by Howard and David are relevant.

Howard writes:
 
H>> David has also suggested that the REFINE_LS_CLASS category in the modulated
H>> structures dictionary should be moved lock, stock and barrel to the core:
H>
H>  In principle I agree. This will save duplication of names.
H>  In practice the text needs amending to allow for "ordinary" space
H> groups and structures. =>
H>
  >;
  >     loop_
  >         _refine_ls_class_R_factor_gt
  >         _refine_ls_class_code
  >                 0.057    'Main'
  >                 0.074    'Com'
  >                 0.064    'NbRefls'
  >                 0.046    'LaRefls'
  >                 0.112    'Sat1'
  >                 0.177    'Sat2'
  >;
  >; Example 1 - extracted from van Smaalen [(1991). J. Phys.:Condens.
  >              Matter 3, 1247-1263.]
  >;
H>
H>     Example 0 might have a set of R factors in terms of parity "groups"
H>of reflections.
H>
H>
  > # - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  >       _definition
  >;         Data items in the REFINE_LS_CLASS category record details 
  >          (for each reflection class separately) about the reflections used
  >          for the structure refinement. Each reflection class is normally 
  >          defined by the number m=sum|mi|, where the mi are the integer 
  >          coefficients that, in addition to h,k,l, index the corresponding 
  >          diffraction vector in the basis defined in 
  >          _cell_reciprocal_basis. However reflection classes 
  >          could be defined, if convenient, in a more general and flexible
  >          way.
  >;
H>
H>  What is called the "normal" definition in the above is not really
H> meaningful for "normal" space groups and structures.

If these are to be adopted as general terms, we should explore the purposes
for which reflections might be sorted into different classes.

 * Gotzon identifies main and satellite reflections for incommensurate
   modulated structures.

 * Howard mentions parity groups.

 * Is this a possible mechanism for tagging Friedel-related reflections?

 * Perhaps reflections that should be omitted in R_free calculations could be
   indicated.

Any others?

David writes:

D> There seems to be something missing from this list - namely there is no
D> item that defines what reflections are used to define the class.  I am not
D> sure whether this can be done in an explicit way, or whether it should be
D> done using a text string that is not computer interpretable, e.g.,
D> _refine_ls_class_definition.

One would envisage the introduction of _diffrn_refln_class_code and
_refln_class_code into the main lists of raw and refinement reflections.
I don't know whether existing diffractometer software can (or can be easily
modified to) select and flag different reflections in this way. If reflections
can be grouped into classes according to arbitrary schemes, is it possible that
one reflection might be assigned to two or more classes?

Opinions welcome.

Brian

[Send comment to list secretary]
[Reply to list (subscribers only)]