Discussion List Archives

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

coreCIF dictionary 2.4 Discusision #4

  • To: coredmg@iucr.org
  • Subject: coreCIF dictionary 2.4 Discusision #4
  • From: David Brown <idbrown@mcmaster.ca>
  • Date: Thu, 11 Dec 2003 11:52:52 -0500
?December 11, 2003 coreDMG coreCIF.dic2.4 Discussion # 4

Dear Colleagues,

PLEASE RESPOND TO THIS EMAIL BY 31 DECEMBER

This email contains the items that were included in Discussion #3
modified in the light of comments received. Most of these items are 
ready for
approval, but I still need your comments on the last one.

This email starts with a summary of the items it contains. This is
followed by proposed dictionary text with comments received, CAN YOU PLEASE
SEND YOUR FURTHER COMMENTS TO THE 'REPLY TO' ADDRESS ON THIS EMAIL BEFORE 31
DECEMBER? In the absence of comments a statement of agreement with the
proposals will be welcome so that I know that you have read this email.

IF I DO NOT HEAR FROM YOU BY THE DEADLINE, I WILL ASSUME THAT YOU AGREE
WITH EVERYTHING PROPOSED BELOW.

Best wishes for the holiday season and the new year.

David

##################################################

SUMMARY OF THE ITEMS IN THIS EMAIL

1. Definition of the symmetry operations in GEOM.
The suggested dictionary text is ready for approval.

2. Handling of the measured fraction items.
The suggested dictionary text is ready for approval.

3. _diffrn_standards_decay_%_lt
The suggested dictionary text is ready for approval.

4. Extinction
The proposal is to make no changes to the current dictionary.

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
Items transferred from msCIF. The suggested text is ready for approval.

6._atom_site_refinement_flag
These flags should better reflect current practice. Further discussion
is needed.

#######################################

FULL COMMENTS AND DICTIONARY TEXT

#######################################
#
# Item 1.
#
########################################
# The representation of symmetry in GEOM
# --------------------------------------
#
# NOTE: COMMENTS BY HOWARD FLACK (AND THE RESPONSE) HAVE BEEN ADDED.
# IF THERE ARE NO MORE COMMENTS, THE ITEMS IN THIS SECTION WILL BE TAKEN
# AS APPROVED
#
# 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.
#
#
# Comments by Howard Flack 2003-11-12
#------------------------------------
# _symmetry_equiv_pos_as_xyz has become _space_group_symop_operation_xyz as
# you well know.
# I'm somewhat unhappy that it is only in the pdf form of the current core
# dictionary that one is informed that items in the _symmetry section have
# been superseded. This information does not appear either in the text 
file or
# in the HTML form. I also noticed by searching in the text version of the
# core dictionary that there are still references to the _symmetry_* which
# have not be changed to the corresponding _space_group_* form. (It may 
be all
# of these are in _geom in which case they have been left unchanged on 
purpose
# at the moment.)
#
# Reply by David Brown 2003-12-08
#--------------------------------
# The information about _space_group replacing _symmetry is available (sort
# of) in the .txt (and presumably the .html) versions under _related_item.
# _related_function is set to 'replace' in the symmetry category and
# 'alternate' in the space group category.
# Checking the DDL1 dictionary I find that the enumeration list for
# _related_function does not envisage the situation
# where a new name replaces an obsolete name. 'replace' means that the two
# definitions are identical and may be used interchangeably. 'alternate'
# means that the two items convey the same information, but in a different
# form. The best we can do with _related_function is to set it to 'replace'
# in both cases, but ideally we need new enumerations of 'obsolete' and
# 'supercedes' to indicate that the _related_item is being phased out or is
# replacing the defined item.
#
# HDF (continued)
#----------------
# The form of the text and the augumentation make it clear that the one and
# only way of introducing symmetry equivalent information is by way of
# _space_group_symop_operation_xyz. This precludes any automatic 
generation by
# way of the information given through _space_group_name_Hall . As I
# understand it, the Hall space group algorithm does not guarantee an unique
# order or labelling of the symmetry-equivalent positions. However is any
# development already under way or planned? If so, the whole text and
# rationale of Item 1 need rethinking. In any case maybe a more satisfactory
# way would be to generate an unique code from the coordinates of the
# equivalent position itself. This sounds like a perfect application for
# 'Methods'.
#
# Reply by David Brown 2003-12-08
#--------------------------------
# Agreed, but 'methods' are not here yet. Nothing much we can do
# about this point. It is somewhat inelegant, but we have to rely on the 
list
# of symmetry operations in the order in which they are labelled in
# _space_group_symop.
#

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. X', the atom forming the
distances and angles listed in the GEOM categories, is related to X, the
symmetry-related atom in the ATOM_SITE category, by:

X' = SX + T

where S is the identifier of a symmetry operation in the space_group_symop
list 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 by Howard Flack 2003-11-12
#-----------------------------------
# The algebra is a bit wonky here. The symmetry operation S itself, as
# expressed in matrix form through _space_group_symop_operation_xyz, is a
# matrix-vector pair {W,w} of which only the matrix part operates on X, the
# coordinates of the atom. This gives as a matrix/vector equation:
# X' = WX + w + T
# On the other hand David may have had in mind that in X' = SX + T, S and T
# are the operations themselves but then it is not correct to use X and X'
# which represent the coordinates of a point in a particular basis 
rather than
# representing the points themselves.
#
# Reply by David Brown 2003-12-08
#--------------------------------
# The definition has been changed.
#
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. X', the atom forming the distances and angles listed in the GEOM
categories, is related to X, the symmetry-related atom in the ATOM_SITE
category, by:

X' = SX + T

where S is the identifier of a symmetry operation in the space_group_symop
list 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. X', the atom forming the distances and
angles listed in the GEOM categories, is related to X, the symmetry-related
atom in the ATOM_SITE category, by:

X' = SX + T

where S is the identifier of a symmetry operation in the space_group_symop
list 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
#
# Comments received are included above.
#
# STATUS: Open for discussion and recommended for approval.
#
#
########################################
#
# Item 2.
#
########################################
# _diffrn_reflns_measured_fraction_resolution_full
# _diffrn_reflns_measured_fraction_resolution_max
# ------------------------------------------------
#
# NOTE: THE FULL DISCUSSION IS GIVEN. THE PROPOSED TEXT IS READY FOR 
APPROVAL
#
# 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. They
# were 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 these 
names
# 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.
#
# Comment by Howard Flack 2003-11-12
#-----------------------------------
#>> Should the definition of 'symmetry equivalent' be left to the author?
#
# Certainly NOT otherwise the value given is meaningless.
#
# Today's best suggestion from HDF would be to have four data items instead
# of 2; in two of these (one _full and one _max) the definition would read
# "Fraction of unique (symmetry-independent in the Laue group) reflections"
# and in the other two (one _full and one _max)
# "Fraction of unique (symmetry-independent in the crystal point group)
# reflections" to which one should add somewhere that for centrosymmetric
# point group one should only use the items referring to the Laue group.
#
# Does one need to explain that if the crystal point group is non-
# centrosymmetric it does not contain a centre of symmetry?
#
# RESPONSE by David Brown 2003-12-08
#-----------------------------------
# Yes one does. Many people who use CIFs will not know what a Laue group is.
#
# I have now incorporated Howard's suggestion in the draft definitions 
below.
#

Data_diffrn_reflns_Laue_measured_fraction_full
_name '_diffrn_reflns_Laue_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 Laue unique reflections (symmetry-independent in the
Laue group) measured out to the resolution given in
_diffrn_reflns_resolution_full or _diffrn_reflns_theta_full.
The Laue group always contains a centre of symmetry so that the
reflection h,k,l is always equivalent to the reflection -h,-k,-l
even in space groups without a center of symmetry.
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_Laue_measured_fraction_max
_name '_diffrn_reflns_Laue_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 Laue unique reflections (symmetry-independent in the
Laue group) measured out to the resolution given in
_diffrn_reflns_resolution_max or _diffrn_reflns_theta_max.
The Laue group always contains a centre of symmetry so that the
reflection h,k,l is always equivalent to the reflection -h,-k,-l
even in space groups without a center of symmetry.
;
Data_diffrn_reflns_point_group_measured_fraction_full
_name '_diffrn_reflns_point_group_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 crystal point-group unique reflections
(i.e., symmetry-independent in
the crystal point group) measured out to the resolution given in
_diffrn_reflns_resolution_full or _diffrn_reflns_theta_full.
For space groups that do not contain a centre of symmetry the
reflections h,k,l and -h,-k,-l are independent.
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_point_group_measured_fraction_max
_name '_diffrn_reflns_point_group_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 crystal point-group unique reflections
(i.e., symmetry-independent in
the crystal point group) measured out to the resolution given in
_diffrn_reflns_resolution_max or _diffrn_reflns_theta_max.
For space groups that do not contain a centre of symmetry the
reflections h,k,l and -h,-k,-l are independent.
;
#
# Further COMMENT by Howard Flack 2003-11-12
#-----------------------------------
# Secretary please note that once agreement has been achieved on this item,
# that of _diffrn_reflns_resolution_full, ..._resolution_max, 
...._theta_full
# and ..._theta_max only ...._theta_full has a sentence like "The 
fraction of
# unique reflections measured out to this angle is given by
# _diffrn_measured_fraction_theta_full". Either all or none of them should
# have this information and it needs to brought up to date after 
resolution of
# item 2.
#
# STATUS: These four items open for discussion and approval.
#
#####################################
#
# Item 3.
#
######################################
#
# NOTE: IF THERE IS NO FURTHER DISCUSSION OF THIS ITEM, I WILL ASSUME IT TO
# HAVE BEEN APPROVED.
#
# _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_%
#
# Comment by Howard Flack 2003-11-12
#-----------------------------------
# I think my suggestion and David's text are just fantastic.
#

data_diffrn_standards_decay_%
_name '_diffrn_standards_decay_%'
_category diffrn_standards
_type numb
_type_conditions esd
_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: Ready for approval
#
####################################
#
# Item 4.
#
####################################
# Extinction
# ----------
# NOTE: THE FOLLOWING EXTINCTION ITEMS WERE REMOVED FROM VERSION 2.3 AS
# NEEDING MORE THOUGHT. I AM PROPOSING THAT WE MAKE NO CHANGE TO THE CURRENT
# DICTIONARY
#
# 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
# which appeared in full in the last round is omitted here for brevity. It
# shows that the extinction items have been used in a variety of ways, 
not all
# of which make much sense.
#
# Comment by IDB made before the last discussion
#-----------------------------------------------
# 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?
#
# Comment by Howard Flack 2003-11-12
#-----------------------------------
# Please feel free to do whatever you think is appropriate. I'll agree so
# long as I do not have to do anything on Item 4.
#
# Response by David Brown 2003-12-08
#-----------------------------------
# My recommendation is to make no changes to the current version of the
# dictionary and recognize that what is reported may or may not make 
physical
# sense, but does describe a correction the author made. The following draft
# definitions would then be dropped.
#
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.
;
# End of draft definitions that will be dropped unless anyone has further
# suggestions.
#
# STATUS: If there is no further discussion, these changes will be dropped.
#
#####################################
#
#Item 5.
#
#####################################
# five items transferred from cif_ms.dic
# --------------------------------------
#
# NOTE: THE OBJECTIONS RAISED AROUND THESE ITEMS SEEM TO HAVE BEEN 
ADDRESSED.
# IF THERE IS NO FURTHER COMMENT, THESE CAN BE TAKEN AS APPROVED.
#
# COMMENT
# The following five items were originally part of msCIF but were 
transferred
# to the Core for wider application. The first three deal with structure
# factors calculated using non-standard expressions, the last two deal with
# restrained refinements.
#
#---------------------------------------------------------------------
# Item 5a - non-standard expressions for calculating structure factors
#---------------------------------------------------------------------
#

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 electrons
;

_definition
; Details concerning the evaluation of the structure factors using the
expression given in _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 factors.
;

data_refine_ls_F_calc_precision
_name '_refine_ls_F_calc_precision'
_category refine
_type numb
_enumeration_range 0.0:
_definition
; This item gives an estimate of the precision resulting from the
numerical approximations made during the evaluation of the structure
factors using the expression given in _refine_ls_F_calc_formula
following the method outlined in _refine_ls_F_calc_details. For x-ray
diffraction the result is given in electrons.
;
# COMMENT: Changes have now (2003-12-08) been made in the above item to
# reflect the following discussion.
#
# From Howard Flack before Discussion #3:
#-----------------------------------------------
# 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.
#
# Comment by Howard Flack 2003-11-12
#-----------------------------------
# I suggest that in the definition "The estimated accuracy in electrons (for
# X-ray diffraction)" be changed to "The estimated accuracy in electrons 
(for
# X-ray diffraction) due to numerical approximations"
#
# STATUS: These items should be ready for approval.
#
#--------------------------------------------------
# Item 5b. items dealing with restrained refinement
#--------------------------------------------------
# 2003-12-08 Corrections have been made in the next item in the light of the
# discussion which follows.
#

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 factor, wR, for all observations used in the
least-squares refinement, including explicitly the intensities
of reflections and the restraints applied in the least-squares
process and described in _refine_ls_restraints_weighting_scheme. The
reflections also satisfy the resolution limits established by
_refine_ls_d_res_high and _refine_ls_d_res_low if given.

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
;
#
# COMMENT
# (Earlier comments deleted)
#
# Comment by Howard Flack 2003-11-12
#-----------------------------------
# OK apart from
#
#>> sum(wY(obs)2^+ sum~r~(w~r~P(targ)2^) ]^1/2^
#
# should be
# {sum(wY(obs)2^) + sum~r~(w~r~P(targ)2^)} ]^1/2^
#
#
# --------------------------------------
# COMMENT: 2003-12-08 The following item has been modified in the light 
of the
# discussion below.
#
data_refine_ls_restraints_weighting_scheme
_name '_refine_ls_restraints_weighting_scheme'
_category refine
_type char
_definition
; A description of the restraints applied during the least square
refinement and the weight assigned to each.
;
#
# IDB: Are the restraints mentioned in this item specified
# anywhere? Can one describe the weights assigned to each restraint when the
# restraints themselves are not defined?
#
# Comment by Howard Flack 2003-11-12
#-----------------------------------
# Very pertinent questions. I do not know the answer to either.
# I made a similar mess with _chemical_absolute_configuration . It does not
# allow you to indicate to which molecule it applies. When I discovered my
# mistake, I then discovered that CIF does not currently allow one to 
describe
# molecules. David's revenge was to put me on coreCIFchem.
#
# Response 2003-12-08
#--------------------
# The definition of the above item has been changed to include a description
# of both the restraint and its weight.
#
# STATUS: Open for discussion and awaiting approval
#
##########################################
#
# Item 6.
#
##########################################
#
# _atom_site_refinement_flag_adp
#
# NOTE: THE SUGGESTION IS TO KEEP THIS SIMPLE. DOES ANYONE HAVE A BETTER
# IDEA? FURTHER DISCUSSION NEEDED.
#
# 2002-09-23 provisional approval, subsequently withdrawn for further
# discussion. This item is used to indicate if a constraint or restraint was
# applied to this particular atom. The draft dictionary text below reflects
# the currently enumeration list. I have not yet changed it to accommodate
# the suggestions made below.
#
# 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 )'
#
# Comment by Howard Flack 2003-11-12
#-----------------------------------
# Curt's proposals sound very reasonable indeed. Has he had any further
# thoughts on the matter. I'm happy with the general thrust of his comments.
# In case you had forgotten, I enjoyed that meal in the Chinese 
restaurant in
# LA.
#
# Comment by David Brown 2003-12-08
#----------------------------------
# This enumeration list could easily get out of hand as different programs
# devise new and exciting ways of restraining the refinement. Furthermore,
# if, for example, E from Curt's list were chosen, one should also identify
# which atom the adp is tied to. I propose that the list be kept short,
# leaving a detailed description of the restraints and constraints to a
# _*_details item (see for example _refine_ls_restraints_weighting_scheme
# above). There is no way we are going to be able to encode this information
# in the CIF in a way that would allow a program to automatically repeat the
# final round of refinement.
#
# I propose that we should have five items:
# . No ADP constraint or restraint applied to this atom.
# C Constraint unrelated to symmetry applied to ADP.
# T Symmetry imposed constraint applied to ADP.
# U Restraint applied to ADP.
# CT Combination of the above.
# CU Combination of the above.
# TU Combination of the above.
#
# The definition should make it clear (as it is elsewhere in the dictionary)
# that a constraint is the assignment of a preselected value to an unrefined
# parameter. The value may be fixed, or it may be determined by the value of
# some other refined parameter. A restraint is the assignment of a target
# value and its notional standard uncertainty to a refined parameter. 
Such an
# target value is treated as an observation in the least squares analysis.
#

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