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: "I. David Brown" <idbrown@mcmail.cis.McMaster.CA>
  • Date: Fri, 11 Sep 1998 17:21:03 +0100 (BST)
	A more common way of defining classes is likely to be into
categories such as h+k even and h+k odd etc.  It should be easy to add
these to the 'for examples' in the definitions.

	I can see many cases where this division into classes will be made
at the refinement stage, so that classes will not be defined for
_diffrn_reflns_class.  For example, in a normal single crystal analysis,
it may be desirable to split the reflections according to parity (even or
odd) if there is a superstructure present.  This separation would not need
to be applied at the measurement (_diffrn_) stage, but might be useful in
assessing the correctness of the superstructure.  

This means that the parent for the codes in the refine_ls_class,
refln_class and reflns_shell_class categories should be
_reflns_class_code, but _reflns_class_code should in turn have as its
parent _diffrn_reflns_class_code.  This makes _diffrn_reflns_class_code a
grandparent.  Are grandparents allowed?  And can one have a child
(_reflns_class_code) present if its parent is not present?

	The way around this difficulty would be to make
_diffrn_reflns_class_code the parent to a new item
_reflns_class_diffrn_code, thus separating the parent and child functions
of _reflns_class_code.  I suppose this would be the more elegant solution.

	I do not see why we have _*_d_res_low in the category
_diffrn_reflns_class.  _*_d_res_high may be useful to give an idea of how
extensive the class of reflections is, but defining both the high and low
resolution limit suggests that we are working in shells, which are fully
covered in the reflns_shell and reflns_shell_class categories.  I suppose
if these were in the msCIF dictionary we should keep them here as Gotzon
must have thought them to be necessary.

	Are we being consistent in the way we break down the different
groups of reflections?  Dividing them into classes (presumably, though not
necessarily) on the properties of their Miller indices, and dividing them
into shells on the basis of their d values are essentially similar
operations, yet in the first case we identify the classes by use of an id
code which allows us to summarise the properties of the class as well as
identify individual reflections, but in the latter case we identify the
shells by the two parameters _res_high and _res_low which have no
child-parent relations.  When shells were envisaged, they were perceived
to be something that would be used only at the refinement stage, but the
msCIF dictionary seems to indicate that shells will be identified at the
measurement stage, at least for the purposes of reporting statistics on
the different shells.  If this is the case, should shells also have an id
with a similar tie-back to diffrn_reflns?  This could be added at this
stage by introducing _refln_shell_code as the child of _reflns_shell_code
and similar items involving _diffrn_.  I think this would allow us to
combine the reflns_shell, reflns_class and reflns_shell_class into a
single category.  Or maybe we could do this anyway - as a catchall
category that would allow the statistics to be given for reflections
divided by group, both shell and class as desired.  If no shell
information was given, the breakdown would be by class only and vice versa. 
We would still have to define the different classes and shells somewhere. 
Or could shells be seen as a particular kind of class?  Brian raises some
interesting questions here.


*****************************************************
Dr.I.David Brown,  Professor Emeritus
Brockhouse Institute for Materials Research, 
McMaster University, Hamilton, Ontario, Canada
Tel: 1-(905)-525-9140 ext 24710
Fax: 1-(905)-521-2773
idbrown@mcmaster.ca
*****************************************************

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