Discussion List Archives

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

comments on coreCIF.dic 2.1

  • To: Multiple recipients of list <coredmg@iucr.org>
  • Subject: comments on coreCIF.dic 2.1
  • From: "I. David Brown" <idbrown@mcmail.cis.McMaster.CA>
  • Date: Tue, 5 Jan 1999 15:19:39 GMT
Comments on coreCIF.dic version 2.beta5

I thought it would be a useful opportunity to review all the items
in this dictionary as well as those that have been recently added
or changed.  There are a few inconsistencies that need attention. 
I have numbered my suggestions for ease in reference.  I apologise for the
large number, but this is obviously the time for housecleaning.

David

1. _atom _site_calc_flag
      Replace 'site data' in the description with 'site coordinates'
(This is part of my campaign to get rid of the sloppy use of the
word 'data').

2. _atom_site_occupancy
      This number is subject to experimental uncertainties and so
can lie outside the given enumeration range of 0.0 to 1.0 by up to
3*u.  The wording should make this clear.  See for example the
wording used for _refine_ls_abs_structure_Flack.  This is important
for those writing checking programs.

3. _atom_site_U_iso_or_equiv
      The enumeration range is given as 0.0 to 10.0, the upper limit
being regarded as one sufficiently high that it is never likely to
be reached in practice.  However, from a philosophical point of
view, the enumeration range should be 0.0 to infinity since there
is no absolute upper limit on this value.  In reading this
dictionary I realise how much our thinking has changed since the
first dictionary was produced.  We are now much more precise in our
definitions - more concerned with the logical consistency of the
file and less with the fuzzier chemical concepts.  With this
evolution in our philosphy the upper enumeration limit should be
changed to 'infinity'.

4. _atom_type_analytical_mass_%
      I am not sure how the enumeration range here came to be 0.0 to
infinity.  No component can be present in amounts greater than
100%.  The upper limit should be 100.

5. _cell_measurement_refln_[]
      Replace 'diffractometer data' with 'diffractometer
measurements'

6. _chemical_conn_atom_number
      The second sentence of the definition is redundant given the
information that appears below it, but if it is necessary, the
phrase 'Within an _atom_site_ list' should be moved from the front
of the sentence to the end.

7. _chemical_formula_structural
      In the last sentence of the definition 'atom type and atom
site data' should be replaced by 'atom type and atom site lists'.

8. _citation_author_ordinal
   _citation_editor_ordinal
      The sentence 'Must match data name _citation_id' is clearly
wrong.  It is the _citation_author_citation_id and
_citation_editor_citation_id that must match _citation_id.  This
sentence makes no sense in these two data item definitions.

9. _diffrn_detector_details
      This datablock is not in alphabetical order.  It should be two
datablocks further down.

10. _diffrn_radiation_polarisn_norm
      'perpendicular component of the polarisation' is rather
meaningless.  I assume what is meant is the 'electric vector of the
major component of the polarisation'.

11. _diffrn_radiation_polarisn_ratio
      This is quite a confusing definition.  I assume that what is
meant is: 'The ratio of the intensities of the major polarisation
component to the component perpendicular to this.  The direction of
the electric vector of the major component is given in _*_norm.'

12. _diffrn_radiation_probe
    _diffrn_radiation_type
      These definitions are confusing.  'The name of' is redundant
in _*_probe, but its definition as 'The type of radiation' sounds
as if it should be the definition of '_*_type'.  A better
definition would be 'The nature of the radiation', howver, this is
the definition supplied under _*_type!  Clearly we are in a state
of linguistic confusion here.  My recommendation is to define
_*_probe as 'The nature of the radiation' and _*_type as 'The type
of radiation'.  The wording of the definitions is hardly very
explicit even in my proposed revision.  However, the meaning is
clear from the examples, but we should make the definitions at
least self-consistent.

13. _diffrn_refln_intensity_sigma
    _diffrn_reflns_av_sigmaI/netI
    _diffrn_reflns_class_av_sgI/I
    _diffrn_standards_scale_sigma
    _refine_ls_weighting_scheme 
    _reflns_threshold_expression
    _reflns_shell_meanI_over_sigI_ (two data items)
      There is an element of confusion in these data definitions. 
We have replaced the ambiguous e.s.d. by s.u. which, as I
understand it, refers to our best estimate of the uncertainty in a
measurement, expressed in the form of the estimated standard error
that we would expect to calculate if we could repeat the
measurement many times.  However, when we talk about intensity
measurements (and the resulting structure factors) we use the term
'sigma' to mean the contribution of the counting statistics to the
standard uncertainty.  This is different from the s.u. itself which
will include other factors besides counting statistics.  It is
therefore useful to distinguish between the uncertainty arising
from counting statistics, which is conveniently called 'sigma', and
the standard uncertainty in the intensity (used, e.g., in
determining the weighting for least square) which is correctly
called the standard uncertainty, or u.  This distinction should be
made in the dictionary and the definition of 'sigma' clearly
spelled out as containing only the contribution of the counting
statistics.  The best place to do this is in
_diffrn_refln_intensity_sigma.  With these defintions I would
recommend the following adjustments:

_diffrn_refln_intensity_sigma       The name is OK but the quantity
                                    given is not the s.u. (or e.s.d.) 
                                    It should be spelled out that this
                                    is the counting statistic
                                    contribution to the s.u.
_diffrn_reflns_av_sigmaI/netI       I assume that sigma is intended
                                    here, so this definition is OK
_diffrn_reflns_class_av_sgI/I       Same as previous
_diffrn_standards_scale_sigma       It is not at all clear what is
                                    required here.  Is this a standard
                                    uncertainty estimated for each of
                                    these scales, is it an estimated
                                    standard deviation derived from
                                    several different measurements of
                                    the scale, or is it in some way
                                    derived from counting statistics
                                    (i.e. sigma)?  Curiously
                                    _diffrn_standard(s)_scale is not
                                    itself defined and it is not clear
                                    to me what it actually represents. 
                                    As I understand the experiment, a
                                    linear regression, defined by two
                                    parameters, is made to the
                                    intensities of the standards. There
                                    are statistical ways of determining
                                    the e.s.d. of each.  But if neither
                                    of these parameters are given, what
                                    is the function of _*_sigma?
_refine_ls_weighting_scheme         The enumeration gives 'sigma' as a
                                    possible value.  According to my
                                    definition this would be the number
                                    based on counting statistics which
                                    is, I assume, what is intended here,
                                    though the definition states that
                                    'sigma' means standard uncertainty. 
                                    I would recommend changing this to
                                    'sigma based on counting statistics'
_reflns_threshold_expression        The definition suggests that the
                                    expression will be given in terms of
                                    u(I) etc. but it is normally given
                                    in terms of sigma(I).  For the sake
                                    of consistency, u should be replace
                                    by sigma.
_reflns_shell_meanI_over_sigI       I assume that sigma is intended
                                    here, not the standard uncertainty
                                    mentioned in the definition.
(It is interesting how many different ways we have of naming
sigma(I)/I and its inverse in the data names!).

14. _diffrn_refln_scan_width
      Is this angle measured as theta or 2*theta?  I assume 2*theta,
but this should be spelled out.  If it is 2*theta, the range is 0.0
to 180, the present range of 0 to 90 suggests that theta is what
should be reported.

15. _diffrn_refln_standard_code
      'matched' should be 'matches'.  Also further down the
definition should read "Must be '.' or match the data name ..."
since most reflections will not have a standards code and this
field will be given by '.'

16. _diffrn_refln_wavelength
      Replace 'data collected' by 'reflections measured'

17. _diffrn_radiation_type
      Add 'time of flight' to the list of examples to indicate that
a wider range of values is possible.

18. _diffrn_reflns_number
    _diffrn_reflns_class_number
      The definitions are not consistent and in the first case
ambiguous.  Reflections can be systematically absent (and hence not
included in this number) either because they correspond to a
lattice translation (and are therefore not counted if a primitive
setting of the cell is used) or because they are the result of
glide planes and screw axes.  The latter are also elements of
'translational symmetry' and therefore are strictly included in the
exclusion described for _diffrn_reflns_number, but I suspect that
only the lattice centering absences are intended since this is
explicitly stated for _diffrn_reflns_class_number.  That is to say,
the value required in these fields is the number that would be
determined if the crystal were indexed on a primitive cell.

19. _diffrn_reflens_reduction_process
      Replace 'intensity data' by 'intensities'

20. _diffrn_reflns_class_d_res_high
    _*_d_res_low
    _*_number
      Replace 'for each reflection class' by 'for this reflection
class'

21. _exptl_crystal_description
      Details of the size of the crystal are normally given using
_exptl_crystal_size_ data items rather than _*_face_ as stated in
the definition (though _*_face_ could be used).  I recommend adding
_*_size to the definition.

22. _exptl_crystal_face_
      There are ambiguities in this definition.  Firstly, I assume
that 'diffractometer' should be 'goniometer' since the crystal
might never be placed on a diffractometer if a single-crystal or
Laue camera were used.  Crystal faces are usually measured on an
optical goniometer, though an x-ray diffractometer may double as an
optical goniometer if suitably equipped.  I would recommend the
following wording: 'The goniometer angle settings when the
perpendicular to the specified crystal face is aligned along a
specified direction (e.g. the bisector of the incident and
reflected beams in an optical goniometer)'.  The orientation of the
axes does not need to be specified since the relative orientations
of the crystal on the optical and x-ray goniometers will be given
by the Miller indices (assuming the crystallographic axes are
correctly labelled in the both experiments, which should never be
taken for granted).

23. _refine_ls_R_Fsqd_factor
    _refine_ls_R_I_factor
      These definitions have not been updated to replace 'observed'
by 'significantly intense'.

24. _refine_ls_class_code
      This code is required to match '_diffrn_reflns_class_code' but
this clearly should be '_reflns_class_code', not only because this
is logically required elsewhere, but also because we have decided
to decouple the _diffrn_reflns_class from the _reflns_class.

25. _refine_ls_class_R_ (four data items)
    _refine_ls_class_wR_factor_all
    _reflns_class_R_ (five data items)
      Replace 'over the specified reflections' by 'over the
reflections of this class'.

26. _refln_d_spacing
      I am suggesting here a new data item.  Since we are moving
from defining resolution in terms of theta to defining it in terms
of the d spacing, it makes sense to allow (encourage?) the
presentation of the d spacing of a reflection instead of the
diffraction angle.  It can be defined as:

            _refln_d_spacing = 2/(_refln_sint/lambda)

27. _refln_F_ (six data items)
      The phrase 'in electrons' should be included in the
parentheses that follow.

28. _refln_include_status
      Replace _reflns_observed_criterion with
_reflns_thershold_expression.  It is not clear to me what the
symbol for an included reflection is.  It looks like a degree sign
in my printed copy, but I assume that it is a lower case letter
'o'.  Because several different fonts are used in the printing and
it is not clear which font has been used for these symbols, the
actual ascii character is uncertain.  The printed character does
not seem to match either the Times Roman or the Courier fonts used. 
Perhaps the ascii character could be more explicitly defined, e.g.,
by stating 'o for observered' in the text.

29. _reflns_limit_
      Replace 'intensity measurements' by 'reported reflections'
which more accurately describes the _reflns category (as opposed to
the _diffrn_reflns category which deals with measurements).

30. _reflns_number_ (two data items)
    _reflns_class_number_ (two data items)
      The last sentence of these definitions which states 'The item
_reflns_special_details describes the reflection data' is a bit
vague, particularly in the light of the additional burden we are
placing on this item to specify whether the Fiedel pairs have been
averaged (and presumably whether other symmetry reflections have
been averaged).  I would suggest 'The special characteristics of
the reflections included in the _refln list should be given in the
item _reflns_special_details'.

31. _reflns_special_details
      This definition should be upgraded to reflect its new
responsibilities.  How about: 'Description of the properties of the
reported reflection list that is not given in other data items.  In
particular it should include information about the averaging (or
not) of symmetry equivalent reflections including Friedel pairs.'

32. _reflns_class_code
      This should also match _refine_ls_class_code.

33. _reflns_scale_group_code
      The last sentence of the definition seems to exclude the
possibility that these codes could be the same as those used in the
_diffrn_scale list.  I assume that what is meant is that they 'need
not be the same', not that they 'may not be the same'. Or am I
missing something?



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