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

core_CIF_2.4 Discussion #7



Core-CIF Discussion #7


Dear Colleagues,

     There were two extensive responses to Discussion #6, one from Howard
Flack and one from Curt Haltiwanger.  Their comments and my responses are
given in this Discussion #7 together with the latest draft of active changes
to the CIF core dictionary.  Most of the suggestions received have been
incorporated in this draft.

     The deadline for receipt of comments on this draft is Sept. 30, 2004.
However, if this is not convenient, the deadline can be changed.  I just 
need
to know when all the comments have come in so that I can work on the next
version.  This email prints out on about 20 pages.  I'm sorry for the length
of the file, but it is important that all the comments are available to you
when you check through the current proposals.

Best wishes

David Brown

-- 
Dr. I.D.Brown, Professor Emeritus,
Department of Physics and Astronomy
McMaster University, Hamilton
Ontario, Canada


-------------------------
General comment by Curt Haltiwanger
-----------------------------------

David, thanks for the expansion of the CIF statements [giving a 
description of
the nature and purpose of CIF in Discussion #6].  A good feeling for a 
CIF is
found by looking at them all.
How's this [for a summary]?

The CIF should be a useful easy to read file that allows a 
crystallographer to
archive details of the experiment and to evaluate the quality of a reported
result.

In addition to archiving data, it should facilitate data exchange between
software within a laboratory and between different laboratories.  The CIF
should facilitate electronic input to the publication process and allow easy
data exchange between authors and journals and computerized databases.  The
CIF must also allow crystallographers and other scientists access to the 
data
in a useful interpretable way for statistical studies.

Using only a few simple syntax rules the CIF is based on a data 
structure that
is completely self-defined with order independent self-defined data items.

Response by IDB
---------------
Curt's statement captures half of what CIF is about, but none of the 
goals set
out in these statements addresses the other aspect of CIF, namely its
relational structure.  Very little of the currently available software makes
use of this relational structure, though some of the newer programs like
enCIFer and CIFedit refer to the dictionaries when constructing or editing a
CIF in order to ensure compliance.  The means that the editing programs 
do not
become obsolete as the dictionary evolves.  We are making sure that this
relational structure is built into all our revisions so that programs 
written
using this relational structure will be able to exploit the existing 
archive.
Future versions of CIF will have dictionaries that give the mathematical
relations between items so that a generic program with no knowledge of
crystallography but with access to the dictionary would be able to retrieve
the distance between two atoms whether or not the distance was given in the
CIF.  We are not there yet, but the present generation of CIFs will be
compatible with these advanced dictionaries written using the advance
dictionary language dRel.


####################
#
# Items included in discussion #7             Recommendation
# -----------------------------------------------------------------
#
# Item 6 Atom_site_refinement_flag_        Editorial changes only
#
# (Item 7 diffrn_refln_status              has now been dropped)
#
# Item 8 _geom_bond_count                  Approve
#
# (Item 9 _refine_scattering_density       has now been dropped)
#
# Item 10 _atomic_sites_solution_hydrogen  Approve

# Item 11  Distributed density           Discussion
#
# Howard Flack agrees with the above recommendations and Curt Haltiwanger
# agrees with the recommendations for 7 and 9.  Items 7 and 9 have now been
# dropped and comments on 6, 8, 10 and 11 are included below.
#
#
##########################################
#
# Item 6.  Atom_site_refinement_flags
#
##########################################
#
#
# The following seven items are in the latest approved coreCIF
# dictionary (version 2.3).  They provide plenty of space to describe a
# variety of different kinds of restraints.  Proposed editorial changes are
# included in the items shown below and are flagged with a comment.
#
data_atom_site_refinement_flags_adp
    _name                      '_atom_site_refinement_flags_adp'
    _category                    atom_site
    _type                        char
    _list                        yes
    _list_reference            '_atom_site_label'
    _related_item              '_atom_site_refinement_flags'
    _related_function            alternate
    loop_ _enumeration
          _enumeration_detail
        .  'no constraints on atomic displacement parameters'
        T  'special-position constraints on atomic displacement parameters'
        U 
#  
###The following is a new wording for the _enumeration_detail of U
#
;           A restraint or constraint not related to symmetry applied to the
            atomic displacement parameters.
;
        TU 'Both constraints applied'
#                   
### The following is a new _definition for _atom_site_refinement_flag_adp.
#
    _definition
;            A code that indicates that refinement restraints or constraints
             were applied to the atomic displacement parameters of this 
site.
;

_atom_site_refinement_flags_occupancy             ?   # No change

_atom_site_refinement_flags_posn                  ?   # No change

data_atom_site_calc_attached_atom
    _name                      '_atom_site_calc_attached_atom'
    _category                    atom_site
    _type                        char
    _list                        yes
    _list_reference            '_atom_site_label'
    _list_link_parent          '_atom_site_label'
#
### This item is now shown as a child of _atom_site_label.  I assume that it
### is legal to have a parent-child relation between two items in the same
### category.  _atom_site_aniso_label would seem to be a precedent.
#
    _enumeration_default        '.'
    _definition
;              The _atom_site_label of the atom site to which the 'geometry-
               calculated' atom site is attached.
;

data_atom_site_calc_flag                             
    _name                      '_atom_site_calc_flag'
    _category                    atom_site
    _type                        char
    _list                        yes
    _list_reference            '_atom_site_label'
    loop_ _enumeration
#
### dif added to enumeration list (see comment below).
#
      _enumeration_detail   dif   'determined from diffraction measurements'
                            d     'abbreviation for "dif"'
                            calc  'calculated from molecular geometry'
                            c     'abbreviation for "calc"'
                            dum   'dummy site with meaningless coordinates'
    _enumeration_default    dif
    _definition
;              A standard code to signal if the site coordinates have been
               determined from the intensities or calculated from the 
geometry
               of surrounding sites, or have been assigned dummy 
coordinates.
               The abbreviation 'c' may be used in place of 'calc'.
;
#
# Curt's comment 2004-06-03 (made in connection with #11 below) seems
# appropriate here.
# -----------------
# Given the, albeit slim, possibility of confusion between d for determined
# from diffraction and dummy, should we add
#
# det  'Determined directly from diffraction measurements'   (or should 
it be
# dif  for  "Diffraction data" )
# d     'abbreviation for determined by diffraction'
# m    'abbreviation for duMmy site with Meaningless coordinates
# AND
# encourage the use of the three or four letter codes.
#
# IDB Response
# ------------
# A good idea, but if we want to encourage three letter codes, why 
define 'm'?
# 'dif' is probably better than 'det'.  I have added it above.
#

data_atom_site_constraints
    _name                      '_atom_site_constraints'
    _category                    atom_site
    _type                        char
    _list                        yes
    _list_reference            '_atom_site_label'
    _enumeration_default        '.'
    _example                'Ueq for H atoms set to 1.2*Ueq attached atom'
#
### I have changed the example above to one that is more clearly a 
constraint,
### and the definition below has been expanded to explain the difference
### between constraints and restraints.
#
    _definition
;              A description of the constraints applied to parameters at 
this
               site during refinement.  A constraint is a parameter that is
               held fixed during a round of refinement but whose value 
may be
               changed between rounds.  A restraint is a parameter whose 
value
               is varied during a round of refinement but is not allowed to
               vary freely.  See also _atom_site_restraints,
               _atom_site_refinement_flags and 
_refine_ls_number_constraints.
;  
#
#
data_atom_site_restraints
    _name                      '_atom_site_restraints'
    _category                    atom_site
    _type                        char
    _list                        yes
    _list_reference            '_atom_site_label'
    _example                    'restrained to planar ring'
    _definition
;              A description of restraints applied to specific parameters at
               this site during refinement. A constraint is a parameter that
               is held fixed during a round of refinement but whose 
value may
               be changed between rounds.  A restraint is a parameter whose
               value is varied during a round of refinement but is not 
allowed
               to vary freely.  See also _atom_site_constraints,
               _atom_site_refinement_flags and _refine_ls_number_restraints.
;
#
### The above definition has been expanded to explain the difference between
### constraints and restraints.
#
# Curt's further comments 2004-06-03
# ----------------------------------
# I am quite happy to see item 6 change into an editorial change only and I
# approve of the change of the enumerator U to be a restraint or constraint
# not related to symmetry......[in item _atom_site_refinement_flags_adp].
#
# This eliminates my need to decide if a U that is 1.2 times the Ueq of the
# attached atom is a restraint or a constraint.  By the way, I have it 
on good
# authority (David Watkin and George Sheldrick) that this is a constraint as
# it is held constant during a given least-squares refinement cycle and
# shifted between cycles.
#
# But it also means we are not capturing all of what is needed to pass data
# from one piece of software to another. 
# For that reason I restate my request for a _refine_input_details which 
would
# be in addition to the _refine _special_details which would remain a 
place to
# put "Description of special aspects of the refinement process. "
#
# As I envision it would be something like the following, but I don't 
like the
# reference to specific programs in the example.
#
data_refine_input_details
    _name                      '_refine_input_details'
    _category                    refine
    _type                        char
    _list                        no
    _example                   
;        SHEXL.ins file or the Crystals constraint and restraint list as 
input
         by the user.
;
    _definition
;              A copy of the input file or the constraint and restraint
               information used for the refinement.
;
#
# [The example Curt includes does not correspond to the definition he
# has provided.  The example should be the actual SHELX.ins file, not a
# statement about it. IDB]
# With crystallographers and noncrystallographers doing 100s of structures a
# year, I can not imagine many cases where a written description of the
# special details of the refinement is going to be included in the cif.  It
# would be wonderful, but it is not likely to happen.  If it is 
required, the
# scientists will send their CIFs to somewhere that does not have the
# requirement.   If there is a written description, it should not get 
combined
# with a least-squares input file.
#
# IDB Response
# ------------
# There is nothing to suggest that Acta Cryst. or any other journal would
# require this item or even an equivalent written statement about the
# restraints.  Acta Cryst. already expects some information to be supplied,
# e.g., about the way in which hydrogen atoms are constrained, but not 
in the
# detail that an input file would supply.  A record of the input file 
might be
# useful for internal archiving, but it would normally be included only 
if the
# author thought it useful, or if it were being sent to another lab that was
# planning to repeat or improve the refinement.  Before we approve this
# proposed item, we should have some indication that there is a demand 
for it.
# CAN I HAVE YOUR COMMENTS PLEASE.  IS THIS ITEM LIKELY TO BE USED?  
Remember
# that there is nothing to prevent anyone from assigning a local name to
# contain this item if they find it useful.  I would recommend that we 
wait to
# see how many other people feel it worthwhile to define a place for an 
input
# file before adding this to the official dictionary.
#
#
# STATUS: Editorial changes made.  Please check if these are OK. DISCUSSION
# NEEDED ON CURT'S PROPOSAL.
#
##########################################
#
# Item 8  _geom_bond_count
#
##########################################
#
# _geom_bond_count
#
# COMMENT: In high symmetry structures when many bonds are related by 
symmetry
# it is not necessary to list all the bonds in the environment of the first
# named atom. Some users may wish to give only the symmetry independent
# distances and a multiplier to indicate how many such bonds are found 
in the
# atomic environment.
#
data_geom_bond_count
_name               '_geom_bond_count'
_category           geom_bond
_type               numb
_list               yes
_list_reference     '_geom_bond_atom_site_label_'
loop_
    _example
    _example_detail
;      loop_
       _geom_bond_atom_site_label_1
       _geom_bond_atom_site_label_2
       _geom_bond_distance
       _geom_bond_count
           Ni1 O1 1.789(3) 4
           Ni1 O2 2.134(3) 2
;
;       Gives the lengths of the six bonds around Ni1, where Ni1 is part 
of an
        NiO6 moiety sitting at a position of 4/m symmetry. '
;
_enumeration_range     0:
_definition
;          The number of times the given bond appears (as the result of
           crystallographic symmetry) in the environment of the atoms
           labelled _geom_bond_atom_site_label_1. This should
           not be used if symmetry equivalent bonds are included explicitly
           in the list.
;
#
# STATUS: Ready for approval
#
# Curt's comment 2004-06-03
# -------------------------
# I agree with the change to count [the name originally was
# _geom_bond_multiplicity].
# I'd add to the example, ... bonds around Ni1, where Ni1 is part of an NiO6
# moiety sitting at a position of 4/m symmetry.
# Should the definition include the idea of symmetry in the definition.
# Perhaps "....appears (as the result of symmetry) in the environment of the
# atoms labeled ....'
#
# IDB Response
# ------------
# These suggestions have been incorporated.
#
#################################
#
# Item 10.  _atom_sites_solution_hydrogens
#
#################################
#
# _atomic_sites_solution_hydrogens
#
# COMMENT: The definition of this item in the current dictionary is bundled
# with primary and secondary solution methods
# and for this reason there is no flag to indicate that the hydrogen atoms
# were not located. We need a new flag for this case.
#
# Add to the enumeration loop the following
#
#       notdet 'coordinates were not determined'
#
# COMMENT by Howard Flack 04-01-14
# --------------------------------
#      OK with me.
#
# Curt Comment 2004-06-03
# -----------------------
# I think this is a good idea, but I am having trouble imagining its use.
# Since it is associated with sites, plural, I assume that it refers to all
# hydrogen sites.  Is that correct? Is that a usual occurrence?  In small
# molecule organics, the hydrogen atoms are often taken from a 
difference map
# and refined when attached to heteroatoms, calculated when on carbon atoms,
# and occasionally not determined for the water molecules.  The same 
would be
# true of organomatallics.  Frankly I don't think I have ever used
# _atomic_sites_solution in any cif I have written or worked with.   How 
many
# examples are there?  If only a few then add 'notdet' and not worry about
# mixed situations, though those are probably the most common in reality.
#
# IDB Response
# ------------
# This item is always present in the CIFs I get for Acta Cryst.E.  SHELX
# dutifully adds this item with the value 'geom' to the CIF whether the
# crystal contains any hydrogen or not (it is not present in many inorganic
# crystals) and regardless of the method actually used. 
# Authors almost always fail to
# remove or check this default (suggesting that most authors do not even 
check
# what SHELX writes and leave George's default value of 'geom' whether it is
# correct or not).  One very eminent and fastidious crystallographer 
recently
# told me that he never questions what George puts into CIF, assuming that
# this is what Acta Cryst. requires.  What hope is there for the rest of us?
# Since only one value can be given, the best this item can
# do is indicate the principal method used.  'notdet' would only be used if
# hydrogen was present but no H coordinates had been determined.
#
# STATUS: Ready for approval
#
#####################################
#
# Item 11 Distributed atomic density
#
#####################################
#
# The following items are based on a request from David Watkin.
# They are intended to describe atoms that are disordered or moving so that
# their atomic density is assumed to be distributed over a simple geometric
# shape such as a ring as might arise from a rotating group such as a
# trifluooromethyl group or a cyclopentadiene molecule. 
#
# Various possible shapes are defined - ring, spherical shell,
# cylindrical shell, etc.  The atoms that form the ring or shell are listed
# with dummy coordinates in the atom_site loop to allow the composition 
of the
# crystal to be calculated.  The dummy atoms are flagged with an identifier
# that links them to a new category giving details of the shape of the
# distribution, thus allowing, e.g., the scattering density to be 
calculated.
# This requires the introduction of an _atom_site_distributed_density_id 
item
# in the atom_site category, and the definition of a new distributed_density
# category.
#
# Howard Flack and Curt Haltiwanger had many comments and suggestions.  
These
# are discussed at the appropriate point below.  The draft proposed here has
# been reviewed by David Watkin and his comments appear at the end of this
# section (which is also the end of the file).
#
# Curt's comment
# --------------
# This is a nice addition.  When will all least-squares programs be able 
to do
# this?
#
# Howard's comments
# ------------------
#  Essentially it's good and useful stuff but it needs to be defined 
with much
# more clarity.
#
#  I found the text confusing. I hope that DJW[atkin]
# has read the text of item 11.  I look forward to hearing whether the
# proposed CIF encoding corresponds to his current needs and is also 
flexible
# enough to allow future developments.
#
# IDB Response
# ------------
# David Watkin (DJW) was involved in the development of this item, but there
# are significant (though compatible) differences between this draft and the
# way things are defined in CRYSTALS (See David Watkin's comments at the end
# of this section).  In this draft I have tried to stay close to a 
description
# of the true physical state of the crystal and stay clear of a description
# that depends on the idioms of a particular program.  The definitions given
# here should be flexible enough to allow further expansion as the need
# arises.
#
# Howard Continues
# -------------
#  The title 'distributed scattering density' is a bit misleading, I 
find. One
# expects to be able to represent p orbitals or d orbitals or third-order
# vibration effects under such a title. The objective of item 11 is however
# more limited. It really sets out to provide a means of representing some
# forms of disordered atomic centres. The convolution with the 
distribution of
# electrons around the disordered atomic centres is not really part of its
# objective. May be another name would illustrate more readily this 
goal. When
# the text talks about 'density' it is the nuclear density of the atomic
# centres which is implied and not (or usually not) the electronic 
density of
# the atoms.
#
# IDB Response
# ------------
# Howard is right.  I have removed the word 'scattering' (except where it is
# properly intended) and the description is now given in terms of atomic
# density.
# COMCIFS has recently approved the rhoCIF dictionary (rho = electron 
density)
# designed by the Commission on Electron and Momentum Density, which makes
# provision for the description of electron density in terms of a multipole
# expansion around a point.
#
#################
#
# A new item for the ATOM_SITE category
#
#################
#
data__atom_site_distributed_density_id
    _name               '_atom_site_distributed_density_id'
    _category           atom_site
    _type               char
    _list               yes
    _list_reference     '_atom_site_label'
    _list_mandatory     no
    _link_parent        '_distributed_density_id'
    _example            ?
    _definition
;              An identifier that links the atom defined by _atom_site_label
               with the distributed density of this atom defined in the
               distributed_density category. 
               Note that all the atoms that give rise to a particular
               distributed density, e.g., a ring, should be included in the
               atom_site list, even when they, or the centroid of the
               distribution, lie on a special position.
               That is, the crystallographic site symmetry is not used to
               generate the whole distributed density shape from the
               crystallographic asymmetric portion.
               The value of _atom_site_symmetry_multiplicity should be 
chosen
               so that the sum of all the atoms in the atom_site list when
               multiplied by their _atom_site_occupancy and their
               atom_site_symmetry_multiplicity is equal to the
               _chemical_formula_sum multiplied by _cell_formula_units_Z.
;
#
#
##########################
#
#   New Category  DISTRIBUTED DENSITY
#
##########################
#
data_distributed_density_[]
    _name               '_distributed_density_[]'
    _category           category_overview
    _type               null
    _definition
;              Items in the distributed_density category describe the
               geometric arrangement of an atom or atoms when they are
               distributed uniformly over a line or surface such as a ring,
               cylindrical shell or spherical shell, the line or surface 
being
               given a thickness through the application of an atomic
               displacement parameter.
;
loop_     _example_detail
          _example
;
This example is fictitious (and chemically implausible) but it is 
designed to
illustrate how a complex system of distributed density can be recorded.  In
this example pentamethyl cyclopentadiene (Cp*) and borazole occupy the same
location in the crystal in the ratio 5:1.  The atoms of the borazole 
ring are
fixed as are three quarters of the atoms in the Cp* ring, but the remaining
quarter of the Cp* molecules are freely rotating.  The rotating Cp* 
molecules
give rise to two concentric rings of density, one from the atoms in the ring
and the other from the methyl groups (hydrogen atoms are ignored).  On 
top of
these rings lie the atoms of the fixed Cp* molecules.  The atoms of the
borazole molecule also lie over the inner Cp* ring.  Full details of the
chemical composition are given in the atom_site loop together with the
positions of the fixed atoms.
The coordinates of the atoms that give rise to the distributed ring of 
density
are set to '.' meaning that they have no significance as the atoms are dummy
atoms included to give the correct composition providing that
_atom_site_occupancy and _atom_site_symmetry_multiplicity are given. 
The composition defined in the atom_site loop is linked to the
distributed_density loop through the parent-child identifiers, 'an1' and 
'an2'
(for annulus 1 and 2). 
The one quarter of the Cp* molecules that are rotating have the occupation
number of 0.208 = 5/6 (the total occupancy of the Cp*)  x 1/4 (the portion
rotating) = 5/24.  The three quarters that are in fixed positions have the
occupation number of 0.625 = 5/6 x 3/4 = 15/24 .
;
# Curt's Comment
# --------------
# I assume that an1 and an2 [in the example] refer to annulus1 and 
annulus2 
# Perhaps saying something like:
#
# The composition defined in the atom_site loop is linked to the
# distributed_density loop through the parent-child identifiers, 'an1' and
# 'an2' (for annulus 1 and 2). 
# The one quarter of the Cp* molecules that are rotating have the occupation
# number of 0.208 = 5/6 (the total occupancy of the Cp*)  x 1/4 (the portion
# rotating) = 5/24.  The three quarters that are in fixed positions have the
# occupation number of 0.625 = 5/6 x 3/4 = 15/24.
#
# IDB Response
# ------------
# I have replaced the original text with this suggestion.
#
# The example now follows:
;loop_
  _atom_site_label
  _atom_site_type_symbol
  _atom_site_fract_x
  _atom_site_fract_y
  _atom_site_fract_z
  _atom_site_U_iso_or_equiv
  _atom_site_occupancy
  _atom_site_symmetry_multiplicity
  _atom_site_adp_type
  _atom_site_distributed_density_id
  _atom_site_calc_flag
#
### The _*_calc-flag of 'd' should be changed to 'dif' if we agree on that
### change (see above).
#
# Inner ring of cyclopentadiene carbon atoms and borazole
C1   C -0.1362(8)  -0.0974(8)  -0.3116(10) 0.0662(18) 0.625(1) 4  Uiso . d
C2   C -0.1060(8)  -0.2165(8)  -0.1837(10) 0.071(2)   0.625(1) 4  Uiso . d
C3   C -0.1774(9)  -0.1939(9)  -0.0820(11) 0.082(2)   0.625(1) 4  Uiso . d
C4   C -0.2529(9)  -0.0561(9)  -0.1479(12) 0.084(2)   0.625(1) 4  Uiso . d
C5   C -0.2261(8)  -0.0002(8)  -0.2891(10) 0.072(2)   0.625(1) 4  Uiso . d
C1a  C   .           .           .          .         0.208(1) 4   .  
an1 dum
C2a  C   .           .           .          .         0.208(1) 4   .  
an1 dum
C3a  C   .           .           .          .         0.208(1) 4   .  
an1 dum
C4a  C   .           .           .          .         0.208(1) 4   .  
an1 dum
C5a  C   .           .           .          .         0.208(1) 4   .  
an1 dum
N1   N -0.1375(8)  -0.0968(8)  -0.3201(10) 0.065(2)   0.167(1) 4   Usso . d
B1   B -0.1002(8)  -0.2265(8)  -0.1728(10) 0.071(2)   0.167(1) 4   Uiso . d
N2   N -0.1402(8)  -0.1034(8)  -0.0765(10) 0.076(2)   0.167(1) 4   Uiso . d
B2   B -0.2370(9)  -0.0364(9)  -0.1832(10) 0.085(2)   0.167(1) 4   Uiso . d
N3   N -0.2893(8)   0.0034(8)  -0.3621(10) 0.062(2)   0.167(1) 4   Uiso . d
B3   B -0.2246(9)  -0.0452(9)  -0.3004(11) 0.073(2)   0.167(1) 4   Uiso . d
# Outer ring of methyl groups
C11  C -0.0951     -0.0733     -0.4330     0.1901     0.625(1) 4   Uani . d
C12  C -0.0272     -0.3236     -0.1750     0.1990     0.625(1) 4   Uani . d
C13  C -0.1719     -0.2833      0.0404     0.2483     0.625(1) 4   Uani . d
C14  C -0.3291     -0.0080     -0.0844     0.2450     0.625(1) 4   Uani . d
C15  C -0.2817      0.1218     -0.3770     0.2219     0.625(1) 4   Uani . d
C11a C   .           .           .          .         0.208(1) 4   .  
an2 dum
C12a C   .           .           .          .         0.208(1) 4   .  
an2 dum
C13a C   .           .           .          .         0.208(1) 4   .  
an2 dum
C14a C   .           .           .          .         0.208(1) 4   .  
an2 dum
C15a C   .           .           .          .         0.208(1) 4   .  
an2 dum
# Details of the two rings of distributed density are given in the following
# loop.
loop_
  _distributed_density_id
  _distributed_density_shape
  _distributed_density_position_x
  _distributed_density_position_y
  _distributed_density_position_z
  _distributed_density_radius
  _distributed_density_direction_h
  _distributed_density_direction_k
  _distributed_density_direction_l
  _distributed_density_Uiso
  _distributed_density_symmetry_multiplicity
an1 ring -0.1810(8)  -0.1133(8)  -0.2058(8)   
                1.198(6)    1.35(2) 0.07(2) -0.45(2)   0.052(2)   4
an2 ring -0.1873(14) -0.1156(14) -0.2210(2)
                2.626(6)    1.30(2) 0.10(2) -0.40(2)   0.131(3)   4
;

# Howard's comment
# ----------------
#  I don't see why you want to limit the scope of this item to UNIFORM
# distributions. I think the items should be expressed to allow non-uniform
# distributions even if you only have particular uniform distribution in 
mind
# at the moment for implementation.
#
# IDB Response
# ------------
# Describing non-uniform distributions would require a major addition to the
# present proposal.  It would mean defining some kind of modulation or shape
# function that would itself be shape-dependent.  It is not at all clear how
# this would best be done or what kind of non-uniform distributions people
# would want to use.  It would be best to leave 'uniform' in this definition
# until there is a strong enough demand that we can see how a non-uniform
# distribution would be best described.  I have added a sentence about 
how the
# atomic displacement parameter gives thickness to one- and two-dimensional
# distributions (see below).
#
data_distributed_density_details
    _name             '_distributed_density_details'
    _category          distributed_density
    _type              char
    _list              both
    _list_reference    '_distributed_density_id'
    _example           
;              The distribution was modelled using a disk of
               density of the given radius.
;
    _definition
;              Information about the distribution of density not
               given in other items.
;
# HDF Comment
# -----------
#   I don't think this is a very good example. You only need to include 
'disk'
# as one of the possibilities in _distributed_density_shape.
#   Is it really a disk? A disk for me is infinitely thin and of a well
# defined radius. With Uiso .ne. 0 the atoms are fuzzy and the disk has
# blurred edges and a definite thickness.
#
# IDB response
# ------------
# We could add 'disk' to the shape enumeration list, but we need an example
# that is not included in the shape enumeration.  At present disk 
qualifies.
# My response to the second paragraph is given below.
#
data_distributed_density_direction_
loop_    _name              
                      '_distributed_density_direction_h'
                      '_distributed_density_direction_k'
                      '_distributed_density_direction_l'
    _category         distributed_density
    _type             numb
    _type_conditions  esd
    _list             both
    _list_reference   '_distributed_density_id'
    _units            rlu
    _units_detail     reciprocal lattice units
    _example          ?
    _definition
;      The (covariant) components on a reciprocal-lattice basis of a 
vector of
       arbitrary length used to indicate the direction of the unique axis of
       the distribution, e.g., the axis of a cylindrical shell or the normal
       to the plane of a ring.
;

# Howard's Comment
# ---------------
# Is it intended that the length of this vector have any meaning? If so 
state
# what it is. If not define the values to represent a vector of unit 
length or
# of arbitrary length according to what is the most suitable. How about the
# following the text for _definition:
# The (covariant) components on a reciprocal-lattice basis of a vector of
# unit/arbitrary length used to indicate e.g. the axis of a cylinder or the
# axis of cylindrical shell or the normal to the plane of a circle.
#
# IDB Response
# ------------
# Much better than anything I could do.  I have adopted Howard's definition
# with minor editorial changes.
#
data__distributed_density_id
    _name             '_distributed_density_id'
    _category         distributed_density
    _type             char 
    _list             both
    _list_reference   '_distributed_density_id'
    _list_mandatory   yes
    _link_child       '_atom_site_distributed_density_id'
    _example          ?
    _definition       An identifier that links the atom defined by
                      _atom_site_label with a distributed density defined in
                      the distributed_density category.        
;
#
data__distributed_density_length
    _name             '_distributed_density_length'
    _category         distributed_density
    _type             numb
    _type_conditions  esd
    _list             both
    _list_reference   '_distributed_density_id'
    _enumeration_range 0.0:
    _units            A
    _units_detail     Angstrom units
    _example          ?
    _definition
;              The length of the line or cylindrical shell of distributed
               density in Angstrom units.
;
# Howard's comment
# ----------------
# Original definition
#>   _definition
#>;              The length of the line or cylinder of distributed 
density in
#>              Angstrom units.  If this number is set to the translation
#>              repeat in the direction of the axis of the distribution,
#>              it describes an infinite line or cylinder of scattering
#>              density running through the crystal.
#>;
#  These 'distributed densities' do not really occur as either a line or a
# cylinder as they are always fuzzy due to Uiso. If you drop the 'of
# distributed density' from the first line of _definition it makes sense. It
# seems to me that from an operational point of view it is most unwise 
to use
# a translation repeat to indicate infinity. It's better either to use a
# negative value for this purpose (lengths by definition are >= 0) or  
to have
# different 'shapes' in _distributed_density_shape for the 'line 
segment' and
# 'line' {i.e. the one of infinite length} 'cylinder'/'cylindrical 
shell' and
# 'infinite cylinder'/'infinite cylindrical shell' {does it have a 
particular
# name}. The Fourier transforms of the finite/infinite objects have 
different
# functional forms. What does DJW[atkin] think about all of this?
# [DJW's comments are given at the end of this section.]
#
# IDB Response
# ------------
# I have adopted this.  Using a negative number is inelegant.  If the 
shape is
# conceptually different it should have a different name.  See below for the
# revised enumeration for the shape.
#
data__distributed_density_position_
loop_    _name              
                      '_distributed_density_position_x'
                      '_distributed_density_position_y'
                      '_distributed_density_position_z'
    _category         distributed_density
    _type             numb
    _type_conditions  esd
    _list             both
    _list_reference   '_distributed_density_id'
    _example          ?
    _definition
;              The position of the centroid of the distributed density in
               fractions of the unit cell values.
;
#
data__distributed_density_radius
    _name             '_distributed_density_radius'
    _category         distributed_density
    _type             numb
    _type_conditions  esd
    _list             both
    _list_reference   '_distributed_density_id'
    _enumeration_range 0.0:
    _units            A
    _units_detail     Angstrom units
    _example          ?
    _definition
;              The radius of the ring, or of the cylindrical or spherical
               shell, of distributed density in Angstrom units.
;
#
data__distributed_density_shape
    _name             '_distributed_density_shape'
    _category         'distributed_density
    _type             char
    _list             both
    _list_reference   '_distributed_density_id'
loop_   
  _enumeration
  _enumeration_detals
      line            'line segment'
      infline         'an infinite line running through the crystal'
      ring            'a circular ring'
      cylshell        'cylindrical shell of finite length'
      infcylshell     'cylindrical shell running through the crystal'
      sphereshell     'spherical shell'
      other           'Give details in _distributed_density_details'
    _definition
;              A flag that indicates the shape of the distributed density.
               The lines and ring are one dimensional distributions of
               atoms and the cylindrical shell and spherical shell are two
               dimensional distributions. 
               In each case the root mean square thickness of the 
distribution
               is given by the atomic displacement parameter defined in
               _distributed_density_Uiso.
;
#
# Curt's Comment
# --------------
# In the list of shapes, why not include an ellipsoid.  While this may 
not be
# a choice in Crystals it seems like a logical shape to have in the list.
#
# IDB Response
# ------------
# We could include an ellipsoidal shell, but it is not easily described in
# terms of a length, a radius and a direction.  It would need a new set of
# descriptors.  We are better off at this stage sticking with shapes 
that are
# easily described.  Ellipsoidal shells can be added later.  I have added
# infinite lines and cylinders as suggested by Howard and used names for the
# flags that make it clear that the spheres and cylinders are shells.
#
# Howard's comment
# ----------------
# Old definition
#>   _definition
#>;              A flag that indicates the type of distributed density.  The
#>              line and ring are one dimensional arrangements of charge and
#>              the cylinder and sphere are two dimensional charge 
shells.  In
#>              each case the thickness of the distribution is determined by
#>              the scattering factor of the element and the atomic
#>              displacement parameter defined in _distributed_density_Uiso.
#>;
#  I'm happy with 'ring' as it implies a 'thick' or 'fuzzy' circle.
#  I'm most unhappy with 'line' as it has no thickness. As from above you
# really need something inspired from 'line segment'. Likewise I'm unhappy
# with cylinder and sphere as they have such a precise meaning in 
mathematics
# and I rather suspect that what you really wanted was something based on
# 'cylindrical shell' and 'spherical shell'. May be also 'disk' or something
# implying 'fuzzy disk'. I think also that in 'In each case the thickness of
# the distribution' you need to include 'root-mean-square' in front of
# thickness. Also, again DJW[atkin], is there any need for Uaniso.
# [CRYSTALS uses only Uiso.]
#
#  Moreover throughout the text there are confusions concerning the 
geometric
# objects and distributions which are presented. In the last sentence of the
# _definition, neither a ring nor a cylinder nor a sphere is either a 
line or
# a surface. The distributions of the nuclear density described in item 
11 are
# always 'fat' or 'thick' as you specifically allow for this through the 
Uiso
# of the distribution. There are no nuclear-density distributions here which
# are spread along a line or over a surface. You can not really even 
call your
# thick lines as cylinders because the Gaussian distribution associated with
# Uiso gives them a fuzzy nature. How do you square this with 'they are
# distributed uniformly'. Its no good trying to use the mean nuclear 
position
# either because, for the ring, this is the centre of its defining circle
# (where in practice the atoms don't go).
#
# IDB Response
# ------------
# Some modification have been made to the definition to clarify these 
points.
# In all cases the nuclei are confined to a line or surface (the wording is
# changed to cylindrical shell and spherical shell) in the same sense 
that an
# atom is confined to a point in the normal description.  I have removed the
# scattering factor which does not apply to the nuclear distribution, but as
# you point out, the atomic displacement parameter does make the line or
# surface fuzzy, giving it an apparent thickness, in the same way as it 
makes
# the point atom fuzzy.  At the hypothetical classical zero temperature 
where
# U = 0 the atom centers (nuclei) would lie on pure lines or pure surfaces.
#
data__distributed_density_symmetry_multiplicity
    _name             '_distributed_density_symmetry_multiplicity'
    _category         distributed_density  
    _type             numb
    _list             both
    _list_reference   '_distributed_density_id'
    _enumeration_range 1:192
    _example          ?
    _definition
#
# I have extended this definition to show how the
# density must be described depending on whether the distributed density
# shape incorporates the crystallographic site symmetry of its centroid or
# not.
#
;              The number of images of centroid of the distributed density
               that the space group symmetry generates in the unit cell
               reported in the cell category.  It is the number that
               appears in International Tables for Crystallography Vol A for
               the Wyckoff position occupied by the centroid.

               In this treatment the symmetry of the distribution itself is
               ignored, including any operations of its point group that are
               part of the crystallographic site symmetry of the 
centroid.    
               All the atoms that give rise to the distributed density 
should
               therefore be listed in the atom_site category even if 
they, or
               the centroid of the distribution, lie on crystallographic
               special positions.
               E.g., if the distribution is a ring and the centroid of the
               ring lies on a crystallographic mirror plane, all the 
atoms in
               ring are listed if the ring lies either in or 
perpendicular to
               the mirror plane since the mirror image of the ring lies over
               the ring itself. 
               If the ring is at some arbitrary angle to the mirror 
plane, the
               mirror generates a second ring and both rings should be
               described independently. 
               However, because both rings cannot be simultaneously 
occupied,
               the occupation numbers given in the atom_site category must
               have a value equal to or less than 0.5.
;
#
data__distributed_density_Uiso
    _name                '_distributed_density_Uiso'
    _category            distributed_density       
    _type                numb
    _type_conditions     esd
    _list                both
    _list_reference      '_distributed_density_id'
    _enumeration_range   0.0:
    _units               A^2^
    _units_detail        'Angstrom units squared'
    _example             0.018(3)
    _definition
;              The factor exp(-Ux^-2^)is applied to all parts of the
distribution, where U = _distributed_density_uiso and x is the distance from
the ideal 1- or 2- dimensional shape.  This emulates the effects of thermal
motion or static displacement from the ideal positions described in this
category and has the effect of converting the simple 1- or 2-dimensional
geometric shapes into 3-dimensional objects of mean square thickness U.
;
#
# Howard's comment
# -------------
#>  _distributed_density_Uiso
#
# Why limit yourself to isotropic?
#
# IDB Response
# ------------
# For a surface there is only one direction of interest, i.e., normal to the
# surface, so an isotropic U is satisfactory.  The other two components can
# have any value without making a difference except at the end of the
# cylinder.  For a line or ring of charge there are two components of
# interest.  A regular Uaniso could be used for a straight line provided 
that
# one of the axes was directed along the line, for a ring both the 
radial and
# normal components could be defined.  An anisotropic ADP is thus shape
# dependent and I recommend that we get experience with what is proposed 
here
# and revisit this problem when it is clear there is a demand.
#
#Old definition
#>   _definition
#>;              The value of the isotropic atomic displacement parameter
#>              applied to each portion of the distributed density.  This
#>              parameter together with the scattering factor of the atoms
#>              whose density is distributed, indicates the thickness of the
#>              line, ring or shell of density.
#>;
#   In _definition I think it most inappropriate to talk about the atomic
# scattering factor as contributing to the thickness. All of item 11 is only
# concerned with nuclear distributions. Also it is not the VALUE of the
# isotropic atomic displacement which is applied to each portion of the
# distributed density. The Uiso is a parameter of the Gaussian distribution
# describing the spread of each volume or line element of the underlying
# nuclear density distribution described by the chosen geometric object 
i.e. a
# line segment, a cylindrical shell, a spherical shell (or segments 
thereof),
# a circle, a circular segment.  Again I'm convinced there is a use for non
# uniform distribution of atomic centres on these geometric objects even if
# the current programmes can not handle such complexity.
#
# IDB Response
# ------------
# Agreed (except for non-uniform density distribution).  See the new 
wording.
#
# The following is David Watkin's response to the above draft
#------------------------------------------------------------
#    I find following cif-speak very heavy going, and am never really
# convinced that I understand what I read.
#
# If I say as simply as I can what CRYSTALS does, will you be able to 
work out
# if it fits your framework?
#
# CRYSTALS allows the refinement of parameters additional to the normal 
atoms
# centres modified by a form factor, site occupancy and an adp.
#
# These new parameters are:
# Line. centroid located at x,y,z, infinitely thin but of length r, modified
# by a conventional atomic form factor, a normal Uiso, and a site occupancy
# which in the absence of disorder, corresponds to the number of  atoms (of
# only one kind) assumed to be modeled by the line. Orientation of line
# specified by the angles of azimuth and declination of the axis. Note that
# this is NEVER a hollow cylinder.
#
# Ring.  Centroid located at x,y,z, infinitely thin, of radius r, 
modified by
# the conventional form factor, U[iso], occupancy.  Orientation of ring
# specified by the angles of azimuth and declination of the normal. 
(note that
# this does not enable a disk to be modeled except as a series of concentric
# rings)
#
# Sphere.  Centroid located at x,y,z, infinitely thin shell of radius r,
# modified etc....  There are no orientational angles. A solid (or 
otherwise)
# ball can only be modeled as a series of concentric shells.
#
# IDB's response
# --------------
# There are only two differences between what we are specifying and what 
David
# Watkin requires and these differences are essentially compatible.
#
# Firstly we specify the direction (of a line) in terms of the reciprocal
# lattice vector rather than using angles.  The reciprocal lattice vector is
# the natural way of defining a direction in a non-orthogonal coordinate
# system and it avoids the need to arbitrarily define an axis system which
# different applications might define in different ways.  However, the
# transformation between the two should be straightforward.
#
# Secondly, rather than specifying a number of identical atoms as 
belonging to
# the distributed density by using an occupation number greater than 
1.0, the
# CIF draft specifies each atom individually since in CIF the occupation
# number is restricted to values between 0 and 1.  In this respect CIF 
is more
# flexible than CRYSTALS.  The transformation between the CIF and CRYSTALS
# should again be reasonably straightforward though in the case where, e.g.,
# the atoms in a rotating six-membered ring had an occupancy of 0.5, 
CRYSTALS
# would give only the effective total number of atoms as 3 and the CIF 
written
# by CRYSTALS would indicate three atoms of occupancy 1.0 rather than six
# atoms of occupancy 0.5.
#
# David Watkin continues
# ----------------------
#All of these parameters can be freely mixed with other parameters, so that
# partial atoms can be embedded in partially occupied shells. Relationships
# between any parameters (shape or atoms) can be set up either as 
constraints
# or restraints.
#
# David's [i.e. the proposed CIF] definition looks as if it should easily
# encompass our models, though there may be a lot of coding needed to recast
# our variables as he wants them.
#
# The thing I am least happy about are the extra dummy atoms. A single entry
# in the main atom loop at the centroid and with an occupancy equal to the
# number of atoms represented by the shape and a traditional Uiso 
enables the
# correct molecular formula to be computed, and enables existing graphics
# programs to create some kind of representation of the model.  It is not
# clear to me what advantage is obtained by a string of dummies.
#
# IDB's commment
# --------------
# The specification of constraints and restraints belongs in the program and
# is not relevant to the CIF.  The reason for using dummy atoms is given
# above.   One additional reason that the dummy atoms are surrogates for the
# real atoms. There is a group that is currently working on the problem 
of how
# to describe the contents of the crystal as a chemical (i.e., a molecular)
# structure in a way that allows the atoms in the chemical description to b#
# identified with the corresponding atom in the crystal description.  In 
order
# to simplify this identification it is useful to have all the atoms
# explicitly listed in the _atom_site list.  The purpose of introducing the
# chemical description is to allow cross-database searches based on chemical
# structure in a way in which the observed molecular geometry in the crystal
# can be extracted.
#
# David Watkin continues
# ----------------------
# However, as far as CRYSTALS is concerned, the matter is academic, since I
# retire in a few years after which the program will become (even more)
# derelict.  David [Brown] and Brian [McMahon] have seen our proposed 
_oxford_
# data items, which are all we have the manpower to implement.  Since no 
other
# programs have facilities for either using or displaying these special
# shapes, this is not important just now.  If you get a good set of
# definitions published, future programmers will have a clear frame work to
# work to.
#
# We had a plan to implement the Bennett, Foxman & ?? Hindered Rotor code
# (Acta Cryst ????), but that will never be done now.  However, you 
might want
# to look at the paper to see what additional parameters might be wanted at
# some time in the future.
#
# STATUS: Open for discussion
#


 


_______________________________________________
coreDMG mailing list
coreDMG@iucr.org
http://scripts.iucr.org/mailman/listinfo/coredmg

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


Copyright © International Union of Crystallography

IUCr Webmaster