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: Howard Flack <Howard.Flack@cryst.unige.ch>
  • Date: Mon, 14 Dec 1998 17:57:12 GMT

>  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 is not that simple. A reflection in the refinement list is
generated by the merging of several reflections from the data collection
list. These reflections may not all belong to the same data collection
bin. [e.g. measurements on several crystals]

> 
> The question also arose of overlapping bins.
  
  I'm unclear in my own mind which of the proposed schemes leads to the
system of most use in practice.   

> 
> 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.
Note:
IDB>   When shells were envisaged, they were perceived
IDB> to be something that would be used only at the refinement stage, but the
IDB> msCIF dictionary seems to indicate that shells will be identified at the
IDB> measurement stage, at least for the purposes of reporting statistics on
IDB> the different shells.

  In essence the REFLNS_SHELL category corresponds to a
DIFFRN_REFLNS_CLASS and a REFLNS_CLASS category (in my suggested way of
doing things) which use exactly the same criteria based on shells. The
latter two can thus be and hence have been rolled into one in this
particular instance. To my mind there is no conflict, pure ointment with
only a Cheshire fly. It is probably more convenient to report this
binning with REFLNS_SHELL but it could be done with  DIFFRN_REFLNS_CLASS
and REFLNS_CLASS as well.

> (1) Does the Group agree that I should implement Howard's scheme as it stands?

  Thank goodness I don't have a vote.


> 
> (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?

   See my comment above.


> 
> (3) Is the Group happy with the proposed handling of overlapping bins through
> application-specific compound codes?
> 
   See my comment above.


> (4) is there general agreement with the suggested data names in the two new
> categories?

   Definitely not. The Cheshire fly is grinning at me through his beard
because I have made a mistake.

  The mistake in my proposal for DIFFRN_REFLNS_CLASS and REFLNS_CLASS
lies in the _all and _gt suffixes. The DIFFRN_REFLNS category does not
include intensity thresholds for excluding measurements so there is no
sense to the _all and _gt suffixes in DIFFRN_REFLNS. The thresholds are
defined on the REFLNS_CLASS only. Those _gt and _all items which are
considered necessary should be moved (and renamed) into the
REFLNS_CLASS. If required the _all version can also be given in
DIFFRN_REFLNS (without the _all suffix). I now also note a certain
redundancy in some of the items i.e. _av_sgI/I and
_meanI_over_sigI_all;  _av_R_eq and _Rmerge_I_all for example. No real
excuse for such a mess but I was more interested in simplifying the
structure than in the detail of the names and their definitions.
 

Best wishes,
   Howard


-- 
Howard Flack        http://www.unige.ch/crystal/ahdf/Howard.Flack.html
Laboratoire de Cristallographie               Phone: 41 (22) 702 62 49
24 quai Ernest-Ansermet             mailto:Howard.Flack@cryst.unige.ch
CH-1211 Geneva 4, Switzerland                   Fax: 41 (22) 702 61 08

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