[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Send comment to list secretary]
[Reply to list (subscribers only)]
core_CIF_2.4 Discussion #7
- To: Distribution list of the IUCr COMCIFS Core Dictionary Maintenance Group <coredmg@iucr.org>
- Subject: core_CIF_2.4 Discussion #7
- From: David Brown <idbrown@mcmaster.ca>
- Date: Thu, 12 Aug 2004 11:41:05 -0400
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)]
- Follow-Ups:
- Re: core_CIF_2.4 Discussion #7 (Howard Flack)
- Prev by Date: Re: Geodesic coordinates
- Next by Date: Re: core_CIF_2.4 Discussion #7
- Prev by thread: Re: 4 new proposed data items for the core CIF DIC
- Next by thread: Re: core_CIF_2.4 Discussion #7
- Index(es):