[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Send comment to list secretary]
[Reply to list (subscribers only)]
cif_core_2.4 discussion 1
- To: <coredmg@iucr.org>
- Subject: cif_core_2.4 discussion 1
- From: "I. David Brown" <idbrown@mcmail.cis.mcmaster.ca>
- Date: Wed, 15 Oct 2003 15:43:37 -0400 (EDT)
October 15, 2003
Dear Colleagues,
PLEASE RESPOND TO THIS EMAIL BY NOVEMBER 30
The items we approved earlier have now been incorporated into
cif_core_2.3 and have been approved by COMCIFS except for a few items that
have been referred back for further consideration by the Dictionary
Maintenance Group (DMG, of which you are a member if you received this message
in your email). These items are presented in this email for discussion.
To bring you up to date on activities of the DMG, I have set up two
subgroups to look at two specialized areas, the best way of incorporating
TWINNING information into CIF, and how to include a CHEMICAL DESCRIPTION of
the contents of a crystal. A chemical description is needed because the
points defined in the atom_site category are points with crystallographic
properties (e.g. symmetry) but not strictly-speaking chemical properties. For
example, the points defined are not necessarily occupied by atoms, nor is
atom_site an appropriate category for defining the molecule or complex to
which these atoms belong. Related to these concerns is the best way to
describe rigid bodies and disorder. Both subgroups have been asked to come up
with proposals for the DMG to consider. Let me know if you would like to join
either of these groups.
This round of discussions focuses on the items that were referred back
from our previous submission to COMCIFS. I give first a list of the items
with a brief description of the problems that were identified, followed by
detailed comments, and in some cases a proposal for new dictionary text to
accommodate the suggestions. CAN YOU PLEASE COMMENT ON THESE ITEMS BY USING
THE 'REPLY TO' ADDRESS ON THIS EMAIL BEFORE 30 NOVEMBER? IN THE ABSENCE OF
COMMENTS, A STATEMENT OF AGREEMENT WITH THE PROPOSALS WILL ALSO BE WELCOME
so that I know that you have read this email.
Best wishes
David
Rest of the message below
*****************************************************
Dr.I.David Brown, Professor Emeritus
Brockhouse Institute for Materials Research,
McMaster University, Hamilton, Ontario, Canada
Tel: 1-(905)-525-9140 ext 24710
Fax: 1-(905)-521-2773
idbrown@mcmaster.ca
*****************************************************
SUMMARY OF THE ITEMS IN THIS DISCUSSION EMAIL
1. Definition of the symmetry operations in GEOM.
The replacement of the _symmetry items by _space_group items raises a
number of questions about the way symmmetry is described in the GEOM
categories.
2. _diffrn_reflns_measured_fraction_resolution_full
_diffrn_reflns_measured_fraction_resolution_max
Some questions were raised about the definitions and the names of these
quantities. The word 'resolution' is redundant, and if values less than
1.0 are acceptable, a lower limit should be specified.
3. _diffrn_standards_decay_%_lt
This value could be more elegantly expressed by allowing an SU to be
added to _diffrn_standards_decay_%.
4. Extinction
Our attempts to tighten the definition of extinction has been criticized
by Howard Flack on the grounds that the refined extinction correction is
a fudge factor and does not truly reflect the extinction in the crystal.
5. _refine_ls_F_calc_accuracy
_refine_ls_F_calc_details
_refine_ls_F_calc_formula
_refine_ls_restrained_wR_factor_all
_refine_ls_restraints_weighting_scheme
These five items were originally proposed for msCIF but were transferred
as being more appropriate for the coreCIF. Questions were raised about
the definitions of these items.
6._atom_site_refinement_flag
These flags should better reflect current practice.
FULL COMMENTS AND DICTIONARY TEXT
#######################################
#
# Item 1.
#
########################################
# The representation of symmetry in GEOM
# --------------------------------------
# Background:
# The symmetry operations that need to be applied to the atoms listed in
# the GEOM categories are given by a concatenation of a number representing
# the number of the symmetry operation in the _symmetry_equiv_pos_as_xyz loop
# followed by an underline and three digits indicating the lattice
# translation. There are several problems here.
#
# 1. The _geom_*_site_symmetry_* items contain a parsable string that must be
# decoded before the positions of the atoms can be determined. Since the
# original version of CIF, our standards have tightened and we have tended to
# discourage the introduction of values that need to be decoded, favouring
# instead using separate datanames for each of the components. This allows
# for automatic checking of the validity of the values.
#
# 2. The original intention was that the symmetry operations were implicitly
# numbered by their position in the SYMMETRY_EQUIV list. Since the original
# version of CIF, it has become customary to include a unique identifier
# explicitly in each loop. This is why we added _symmetry_equiv_pos_site_id
# as a numerical field. In the SPACE_GROUP_SYMOP loop which replaces the
# SYMMETRY_EQUIV loop this identifier is replaced with _space_group_symop_id
# which has the type 'char' and is therefore not restricted to a numerical
# value. This implies a change in the structure of the
# _geom_*_site_symmetry_* values which now may contain a character string.
#
# 3. The lattice translations in the current _geom_*_site_symmetry_* items are
# created by adding 5 to the actual translation, thereby allowing translations
# between -5 and +4 to be given by a single integer. Occasions have arisen in
# which this range is not large enough.
#
# The proposed solution is to replace each of the _geom_*_site_symmetry_*
# items with four new items:
# _geom_*_site_symmetry_symop_*
# _geom_*_site_symmetry_trans_a_*
# _geom_*_site_symmetry_trans_b_*
# _geom_*_site_symmetry_trans_c_*
# The first item would have the type 'char' which would allow any character
# string, including numbers, to be used. It would be a child of
# _space_group_symop_id, allowing its value in a given CIF be automatically
# checked for validity without the need for the string to be parsed.
# Automatic parsing is not possible in DDL1 without using knowledge that is
# not accessible to the computer. The symmetry translations would still
# normally be integers but their values would not be restricted and would not
# have 5 added to them.
#
# The following is suggested code for these items. The values * would be
# replaced by 'bond', 'contact', 'angle' or 'torsion' when they follow _geom_,
# and by 1, 2, 3 or 4 when they occur at the end of the name. _related_item
# and _related_function 'replace' should be added to the definitions of the
# items whose names are shown as alternates below.
#
data_geom_*_site_symmetry_symop_1
_name '_geom_*_site_symmetry_symop_1'
_category geom_*
_type char
_list yes
_list_reference '_geom_*_id'
_related_item '_geom_*_site_symmetry_1'
_related_function alternate
_link_list_parent '_space_group_symop_id'
_example ?
_definition
; An identifier that points to the symmetry operation S in the
space_group_symop list. S is defined in the expression below for the symmetry
operation applied to the first listed atom. The coordinates X' of an atom
forming the distances and angles listed in the GEOM categories is given by:
X' = SX + T
where X gives the coordinates of the symmetry-related atom in the ATOM_SITE
category, S is the identifier of a symmetry operation in the space_group_symop
loop and T is a vector giving the translation in lattice units. The
components of this vector are given in the three items
_geom_*_site_symmetry_trans_* (* = a, b, c).
;
#
#
data_geom_*_site_symmetry_symop_2
_name '_geom_*_site_symmetry_symop_2'
_category geom_*
_type char
_list yes
_list_reference '_geom_*_id'
_related_item '_geom_*_site_symmetry_2'
_related_function alternate
_link_list_parent '_space_group_symop_id'
_example ?
_definition
; An identifier that points to the symmetry operation S in the
space_group_symop list in the expression below applied to the second listed
atom. The coordinates X' of an atom forming the distances and angles listed
in the GEOM categories is given by:
X' = SX + T
where X gives the coordinates of the symmetry-related atom in the ATOM_SITE
category, S is the identifier of a symmetry operation in the space_group_symop
loop and T is a vector giving the translation in lattice units. The
components of this vector are given in the three items
_geom_*_site_symmetry_trans_* (* = a, b, c).
;
# COMMENT: The above item would have to be repeated with suitable changes once
# more for angles and twice more for torsion angles.
#
data_geom_*_site_symmetry_trans_*
loop_ _name '_geom_*_site_symmetry_trans_a_1'
'_geom_*_site_symmetry_trans_b_1'
'_geom_*_site_symmetry_trans_c_1'
'_geom_*_site_symmetry_trans_a_2'
'_geom_*_site_symmetry_trans_b_2'
'_geom_*_site_symmetry_trans_c_2'
_category geom_*
_type numb
_list yes
_list_reference '_geom_*_id'
_related_item _geom_*_site_symmetry_*
_related_function alternate
_example ?
_definition
; The translations T in the equation below applied to the different
atoms forming the distance or angle. The coordinates X' of an atom forming
the distances and angles listed in the GEOM categories is given by:
X' = SX + T
where X gives the coordinates of the symmetry-related atom in the ATOM_SITE
category, S is the identifier of a symmetry operation in the space_group_symop
loop and T is a vector giving the translation in lattice units. The
components of this vector are given in the three items
_geom_*_site_symmetry_trans_* (* = a, b, c).
;
# COMMENT: three more names would be needed for angles and six more for
# torsion angles.
#
# STATUS: The above items are open for discussion.
#
data_geom_*_id*
_name '_geom_*_id'
_category geom_*
_type char
_list yes
_list_mandatory yes
_example ?
_definition
; A unique identifier for each of the items in the geom_* list.
;
# COMMENT: needed for file management but not presently defined. See above
#
# STATUS: Open for discussion
#
#
########################################
#
# Item 2.
#
########################################
# _diffrn_reflns_measured_fraction_resolution_full
# _diffrn_reflns_measured_fraction_resolution_max
# ------------------------------------------------
# COMMENT: These items were recommended as a replacement for
# _diffrn_measured_fraction_theta_full when we decided that the resolution was
# best expressed in reciprocal angstroms rather than as a theta angle. It was
# moved from the diffrn category to a more appropriate category.
#
# 2002-11-11 Preliminary approval given but the item was subsequently
# returned for further discussion (see below).
#
# 2003-06-26 _related_function 'replace' changed to 'alternate'
#
# Subsequently Curt Haltiwanger pointed out that '_resolution' in this name
# was unnecessary as the measured fraction did not depend on whether the
# the resolution of the measured diffraction pattern was expressed as a theta
# angle or reciprocal Angstroms.
#
# Ralf Grosse-Kunstleve suggested that imprecise wording like 'very close to
# 1.0' should be replaced by a precise value such as 'no less than 0.95' which
# could be given in the enumeration range, allowing the value to be checked
# automatically for validity.
#
# The question of whether reflections related by the center of symmetry in a
# non-centrosymmetric space group are 'symmetry equivalent' is not specified
# in the definition. Should the definition of 'symmetry equivalent' be left
# to the author? If not, and reflections related by the center of symmetry
# are always considered equivalent, the enumeration range might have to be
# extended to 2.0 to cover the case where the author measured all reflections
# in a P1 crystal. On the other hand if the reflections related by the center
# of symmetry were never to be considered equivalent in a non-centrosymmetric
# space group and author only measured one half of the full diffraction
# pattern, the _*_measured_fraction_full might legitimately be set to 0.5.
# Our decision on this matter might be of significance is assessing the value
# of the Flack parameter. We should specify how reflections related by the
# center of symmetry are to be handled. Suggestions are welcome.
#
data_diffrn_reflns_measured_fraction_full
_name '_diffrn_reflns_measured_fraction_full'
_category diffrn_reflns
_type numb
_enumeration_range 0.95:1.0
_related_item '_diffrn_measured_fraction_theta_full'
_related_function alternate
_definition
; Fraction of unique (symmetry-independent) reflections measured
out to the resolution given in _diffrn_reflns_resolution_full or
_diffrn_reflns_theta_full.
This number should not be less than 0.95, since it represents the
fraction of reflections measured in the part of the diffraction
pattern that is essentially complete.
;
data_diffrn_reflns_measured_fraction_max
_name '_diffrn_reflns_measured_fraction_max'
_category diffrn_reflns
_type numb
_enumeration_range 0:1.0
_related_item '_diffrn_measured_fraction_theta_max'
_related_function alternate
_definition
; Fraction of unique (symmetry-independent) reflections measured
out to the resolution given in _diffrn_reflns_resolution_max or
_diffrn_reflns_theta_max.
;
#
# COMMENT: How should reflections related by a center of symmetry be handled?
#
# STATUS: These two items open for discussion
#
#####################################
#
# Item 3.
#
######################################
# _diffrn_standards_decay_%_lt
# ----------------------------
# COMMENT: Many experiments show no detectable decay and there is no provision
# currently for entering anything other than 0.000, but this does not indicate
# correctly the upper limit on the decay.
#
# 2002-11-11 Preliminary approval given
#
# Subsequently Howard Flack suggested that this case could more elegantly be
# handled by giving the SU for _*_decay_%
#
# e.g., 0.0(1) would be equivalent to <0.3% using our rule that the true
# value of an item may lie within three SUs of the given value.
#
# The following gives a revised dictionary entry for
# _diffrn_standards_decay_%
#
data_diffrn_standards_decay_%
_name '_diffrn_standards_decay_%'
_category diffrn_standards
_type numb
_type_conditions esd
_related_item '_diffrn_standards_decay_%'
_related_function alternate
_enumeration_range :100
loop_ _example
_example_detail
0.5(1) 'represents a decay between 0.2% and 0.8%'
-1(1)
; The change in the standards lies between a decay of
2% and an increase of 4%.
;
0.0(2)
; The change in the standards lies between a decay of
0.6% and an increase of 0.6%.
;
_definition
; The percentage decrease in the mean
intensity of the set of standard reflections measured at the
start of the measurement process and at the finish. This value
usually affords a measure of the overall decay in crystal
quality during the diffraction measurement process. Negative
values are used in exceptional instances where the final
intensities are greater than the initial ones. If no
measurable decay has occurred, the standard uncertainty should
be quoted to indicate the maximum possible value the decay
might have. Thus 0.0(1) would indicate a decay of less than
0.3% or an enhancement of less than 0.3%.
;
#
# STATUS: Open for discussion
#
####################################
#
# Item 4.
#
####################################
# Extinction
# ----------
# The following extinction items were removed from version 2.3 as needing more
# thought. See Brian M's review of the current reporting of extinction
# at the end of this file.
#
# Howard Flack's comments 2003-06-27
# The truth of the matter is that extinction parameters are junk.
# Junk*10**5 is just the same amount of junk. Also 'tidy junk' is more
# junky than 'untidy junk' because the neatness tempts you to believe that
# there is some true order or meaning. There is no decent routine physical
# experiment that one can do on a crystal that depends on the same things
# which are critical to extinction. You hence have no way of knowing
# whether the values of the parameters of an extinction model are
# reasonable for the crystal under study.
#
# My recommendation is to stop any further discussion within CoreDmg on
# extinction parameters whilst awaiting a significant theoretical or
# experimental breakthrough.
#
# Brian McMahon's report on the use of extinction in Acta Cryst. archive
# follows.
loop_ _refine_extinction_method
none
'B-C type 1 Gaussian isotropic (Becker & Coppens, 1974)'
'B-C type 1 Lorentzian isotropic (Becker & Coppens, 1974)'
'Larson (1970)'
'Larson 1970 Crystallographic Computing eq 22'
'shelxl'
SHELXL
# plus many other variations on SHELX
'Zachariasen (1967)'
'Zachariasen (1967) type 2 Gaussian isotropic'
'Zachariasen_type_2_Gaussian_isotropic (Zachariasen, 1967)'
'secondary Zachariasen'
Zachariasen
Zachariasen_type_2_Gaussian_isotropic
'F*=F(1+0.002xF^2^(sin(2\q))^-0.25^'
# The last of course really should be in _refine_ls_extinction_expression
#
# There are also surprisingly few distinct expressions given; the ones I
# have found are:
loop_ _refine_extinction_expression
'Eq22 p292 "Cryst. Comp." Munksgaard 1970'
'Eq22 p292 Cryst. Comp. Munksgaard 1970'
Fc^*^=kFc[1+0.001xFc^2^\l^3^/sin(2\q)]^-1/4^
'FC^*^=KFC[1+0.001XFC^2^\L^3^/SIN(2\Q)]^-1/4^'
'Fc^*^ = kFc[1+0.001xFc^2^\l^3^/sin(2\q)]^-1/4^'
'Fc^*^=3DkFc[1+0.001xFc^2^\l^3^/sin(2\q)]^-1/4^'
'Fc^*^=KFc[1+0.001xFc^2^\1^3^/sin(2\q)]^-1/4^'
'Fc^*^=kFc[1+0.001xFc^2^\l^3^/sin(2\q)]^-1/4^'
'Fc^*^=kFc[1+0.001xFc^2^l^3^/sin(2q)]^-1/4^'
'F~c~^*^ = kF~c~[1+0.001xF~c~^2^\l^3^/sin(2\q)]^-1/4^'
Fc^*^=kFc[1+0.001xFc^2^\l^3^/sin(2\q)]^-1/4^
'equation (22) of Larson (1970)'
?
none
not_defined
not_refined
# These appear all to be attempts to express equation 22 of the cited
# reference, which in TeX is
# $$ F^*_c = k |F_c| (1 + 2 r^* |F_c|^2\delta) ^{-1/4} $$
# and is presumably what is meant by the "Zachariasen" method. According to
# the existing core definition, _refine_ls_extinction_coef should supply the
# r* value in this case, the magnitude of which should be ~10000.
#
# The values of _refine_ls_extinction_coef in our collection of CIFs are
# given below. One would of course expect a range of numeric values, since
# r* is related to the mean path length through a domain in the crystal and
# the mosaic spread; but the vast majority of reported values are 8 or more
# orders of magnitude lower than the suggested range, so clearly something
# is wrong.
loop_ _refine_ls_extinction_coef
'8.3(5) \\times 10^-5^'
'Not refined'
'not applicable'
'x = 0.0007'
.
0
0.0
0.0000
0.0000(2)
0.00000
0.00000(1)
0.000000(10)
0.00000056
# many other values in between have been deleted to save space
1630(119)
163E1(12)
17.4(3)
3.43(19)
3.91804
5.64E-7(6)
6.3(7)
6511(437)
6E-6(1)
?
no
none
not_refined
#
# Comment by IDB
# Even if misused, this parameter does describe a correction that was made
# to the observations and should be reported. The definitions below are the
# ones we approved earlier but which have been referred back. Any suggestions
# of what we should do? Should we leave this item as it is in the
# current dictionary and not try to refine it further?
#
data_refine_ls_extinction_coef
_name '_refine_ls_extinction_coef'
_category refine
_type numb
_type_conditions esd
_example 3472(52)
_example_detail 'Zachariasen coefficient r* = 0.347(5) E04'
_definition
; The extinction coefficient used to calculate the correction
factor applied to the structure-factors. The nature of the
extinction coefficient is given in the definitions in
_refine_ls_extinction_flag or refine_ls_extinction_method.
Note that the magnitude of these values is usually of the
order of 10000.
;
data_refine_ls_extinction_expression
_name '_refine_ls_extinction_expression'
#
# this item is no longer needed and can be retired.
#
data_refine_ls_extinction_flag
_name '_refine_ls_extinction_flag'
_category refine
_type char
_definition
; A flag identifying the expression used for the extinction
correction applied using the parameter given in
_refine_ls_extinction_coef.
;
loop_
_enumeration
_enumeration_details
Zach
; Zachariasen formula:
(details of formula needed here - if more than one formula is in use, each
should be given a separate enumeration name)
Zachariasen, W. H. (1967). Acta Cryst. 23, 558-564.
Larson, A. C. (1967). Acta Cryst. 23, 664-665.
;
BC_1_L
; Becker-Coppens type 1 with Lorentzian mosaic spread
(details of formula needed here)
Ref: Becker, P. J. & Coppens, P. (1974). Acta Cryst.
A30, 129-153.
;
BC_1_G
; Becker-Coppens type 1 with Gaussian mosaic spread
(details of formula needed here)
Ref: Becker, P. J. & Coppens, P. (1974). Acta Cryst.
A30, 129-153.
;
BC_2_L
; Becker-Coppens type 2 with Lorentzian mosaic spread
(details of formula needed here)
Ref: Becker, P. J. & Coppens, P. (1974). Acta Cryst.
A30, 129-153.
;
BC_2_G
; Becker-Coppens type 2 with Gaussian mosaic spread
(details of formula needed here)
Ref: Becker, P. J. & Coppens, P. (1974). Acta Cryst.
A30, 129-153.
;
data_refine_ls_extinction_method
_name '_refine_ls_extinction_method'
_category refine
_type char
loop_ _example ?
_definition
; A description of the extinction correction method applied when
the method used cannot be identified by one of the flags in
_refine_ls_extinction_flag. The description should contain
all the details needed to repeat the correction.
;
#
# STATUS: Open for discussion
#
#####################################
#
#Item 5.
#
#####################################
# five items transferred from cif_ms.dic
# --------------------------------------
# COMMENT
# The following five items were originally part of msCIF but were transferred
# to the Core for wider application. There are some questions that need
# answering.
data_refine_ls_F_calc_accuracy
_name '_refine_ls_F_calc_accuracy'
_category refine
_type numb
_enumeration_range 0.0:
_definition
; The estimated accuracy in electrons (for X-ray diffraction)
reached during the evaluation of the structure factor given
by _refine_ls_F_calc_formula following the method outlined
in _refine_ls_F_calc_details.
;
# COMMENT
#
# From Howard Flack:
# It is not at all clear to me from the definitions that are
# given whether the accuracy is meant to apply only to numerical
# approximations (e.g. rounding) or whether the 'accuracy' also
# includes an estimation of known deficiencies in the physical
# model expressed by data_refine_ls_F_calc_formula.
#
# Response of Gotzon Madariaga
# The aim of this item was to reflect the estimated numerical
# accuracy of the structure factors given that their calculation,
# in the case of modulated structures, involves numerical integrations
# or (in simpler cases) the evaluation of Bessel functions.
# Should other sources of systematic error (perhaps "precision" is
# better than "accuracy") be added?. The problem I see here is
# the estimation of such additional terms.
#
# IDB: No change has yet been made to the definition given below. I await
# your comments and suggestions.
#
data_refine_ls_F_calc_details
_name '_refine_ls_F_calc_details'
_category refine
_type char
loop_ _example 'Gaussian integration using 16 points'
; Bessel functions expansion up to 5th-order. Bessel
functions estimated accuracy: better than 0.001
;
_definition
; Details concerning the evaluation of the structure factor given
by _refine_ls_F_calc_formula.
;
data_refine_ls_F_calc_formula
_name '_refine_ls_F_calc_formula'
_category refine
_type char
_definition
; Analytical expression used to calculate the structure factor.
;
#
# _refine_ls_restrained_wR_factor_all
# -----------------------------------
# COMMENT
# From Howard Flack
# Is there any theory around that says one should
# calculate like this? I mean specifically adding the square
# roots of the two quotients together, rather than, for example,
# adding the two quotients and then taking the square root, or
# even adding the two divisors, adding the two dividends, forming
# the quotient and then taking the square root.
#
# Response of Gotzon Madariaga
# Since restraints are considered observations the correct form
# is the last one. I think it is the approach followed in the
# definition of _refine_ls_restrained_S_all.
#
# IDB: I have modified the formula in the following definition to correspond
# to to Gotzon's reply, and recommend that we adopt this form.
#
data_refine_ls_restrained_wR_factor_all
_name '_refine_ls_restrained_wR_factor_all'
_category refine
_type numb
_enumeration_range 0.0:
_definition
; The weighted residual factors for all observations used in the
least-squares refinement, including explicitly the intensities
of reflections and the restraints applied in the least-squares
process. The reflections also satisfy the resolution limits
established by _refine_ls_d_res_high and _refine_ls_d_res_low.
wR = [ {sum(w[Y(obs)-Y(calc)]^2^)+ sum~r~(w~r~[P(targ)-P(calc)]^2^)}/
sum(wY(obs)^2^+ sum~r~(w~r~P(targ)^2^) ]^1/2^
Y(obs) = the observed amplitude specified by
_refine_ls_structure_factor_coef,
Y(calc) = the calculated amplitude specified by
_refine_ls_structure_factor_coef,
w = the least-squares weight,
P(targ) = the target restraint values,
P(calc) = the calculated restraint values,
w~r~ = the restraint weight specified in
_refine_ls_restraints_weighting_scheme
sum is taken over the specified reflections
sum~r~ is taken over the restraints
;
#
# STATUS: open for discussion
#
# _refine_ls_restraints_weighting_scheme
# --------------------------------------
# COMMENT: IDB: Are the restraints mentioned in the following item specified
# anywhere? Can one describe the weights assigned to each restraint when the
# restraints themselves are not defined? The following item is in the form
# originally proposed by Gotzon.
#
data_refine_ls_restraints_weighting_scheme
_name '_refine_ls_restraints_weighting_scheme'
_category refine
_type char
_definition
; The weighting scheme applied to restraints in the least-squares
process.
;
#
# STATUS: Open for discussion
#
##########################################
#
# Item 6.
#
##########################################
#
# _atom_site_refinement_flag_adp
#
# 2002-09-23 provisional approval, subsequently withdrawn for further
# discussion.
#
# Comment by Curt Haltiwanger on the enumeration list.
# There are at least three common restraints for adp's
#
# 1. 'rigid bond' [SHELXL - DELU] restraint - i.e. the components of the
# ADP in the direction of the bond are restrained to have similar numerical
# values
#
# 2. 'near neighbor' (My term) [SHELXL - SIMU] restraint - Atoms closer
# than a specified distance are restrained to have the same Uij components.
#
# 3. 'approximate isotropic' (My term) [SHELXL - ISOR] restraint - atoms
# are restrained so that their Uij components approximate to isotropic
# behavior
#
# The enumeration detail should reflect these possibilities and those in other
# refinement packages.
#
# In addition, SHELXL can have the provision for several atoms to have exactly
# the same adp's or some multiplier times this. These would also be
# candidates for enumeration. I have no knowledge of the restraints and
# constraints used in other programs.
#
# S 'special-position constraints on atomic displacement parameters'
# R 'adp in the direction of connecting bond are restrained to be similar
# (rigid bond)'
# N 'adp of nearby atoms are restrained to have similar Uij's
# I 'adp restrained to approximate isotropic behavior'
# E 'adp exactly tied to adp of another atom'
# M 'adp based on a multiple of the adp of another atom'
# SR 'combination of the above constraints'
# SN 'combination of the above constraints'
# SI 'combination of the above constraints'
# SE 'combination of the above constraints'
# etc
#
# Alternatively remove rigid bond from the definition
# U 'Uiso or Uij restraint'
# or add other possibilities
# U 'Uiso or Uij restraint ( rigid bond, approximate isotropic, tied )'
#
# End of Curt's comments
#
# IDB: The dictionary text below is the text that we originally approved and
# later withdrew for further consideration. If we adopt Curt's enumaration
# list presumable R, N, I, E and M are mutually exclusive and so can only
# occur in combination with S. Are there any other restraints we should
# enumerate or should be just keep the simple enumeration we already have in
# the dictionary definition given below?
#
data_atom_site_refinement_flags_adp
_name '_atom_site_refinement_flags_adp'
_category atom_site
_type char
_list yes
_list_reference '_atom_site_label'
loop_ _enumeration
_enumeration_detail
. 'no constraints on atomic displacement parameters'
T 'special-position constraints on atomic displacement parameters'
U 'Uiso or Uij restraint (rigid bond)'
TU 'Both constraints applied'
_definition
; A code which indicates the refinement restraints or constraints
applied to the atomic displacement parameters of this site.
;
#
# STATUS: Open for discussion
#
################## End of document ###############
_______________________________________________
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: cif_core_2.4 discussion 1 (Howard Flack)
- Re: cif_core_2.4 discussion 1 (Owen Johnson)
- Prev by Date: Re: update / Twinning
- Next by Date: Re: cif_core_2.4 discussion 1
- Prev by thread: Re: IUPAC workshop on XML and IChI
- Next by thread: Re: cif_core_2.4 discussion 1
- Index(es):