Discussion List Archives

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

CIF Core DMG Discussion #5

  • To: coredmg@iucr.org
  • Subject: CIF Core DMG Discussion #5
  • From: David Brown <idbrown@mcmaster.ca>
  • Date: Fri, 09 Jan 2004 15:21:00 -0500
?2004-01-06 Core CIFdic2.4 Discussion #5

Dear Colleagues,

I would like to take this opportunity to thank you all for your
contributions to the revision of the core CIF dictionary during 2003 and to
wish you an enjoyable and successful 2004.

The last discussion document, #4, whose deadline for comments was 2003-
12-31 produced two responses containing only one reservation, namely for 
item
6 which is therefore included in this list for further discussion. Items 1 -
5 in discussion #4 have been marked as approved and added to the list of
changes that will be included in the core CIF dictionary version 2.4.

I look forward to receiving your comments on the items included on this
Discussion (#5). I would appreciate it if you could respond by Feb 15, 2004,
but let me know if you need more time - the deadline can be extended.

Best wishes

David

##########################################
#
# Items included in the Discussion # 5
#
# Item 6. _atom_site_refinement_flag_adp (transferred from #4)
#
# Item 7. _diffrn_refln_status
#
# Item 8. _geom_bond_multiplicity
#
# Item 9. refine_scattering_density (New Category)
#
# Item 10. _atomic_sites_solution_hydrogens
#
##########################################
#
# Item 6.
#
##########################################
#
# _atom_site_refinement_flag_adp
#
# Carried over from discussion #4
#
# NOTE: THE SUGGESTION IS TO KEEP THIS SIMPLE. DOES ANYONE HAVE A BETTER
# IDEA? FURTHER DISCUSSION NEEDED.
#
# 2003-12-19 Howard Flack's comment:
# ----------------------------------
# Whose suggestion? Can't they come up with
# a proposal. Curt's comments are very pertinent.
#
# 2004-01-06 Response by David Brown.
# -----------------------------------
# This was my suggestion and I made a simple proposal which is given below.
# Curt's suggestions (see below) may well be pertinent but I can foresee an
# endless enumeration list of the different kinds
# of restraints and constraints that are available to users. Curt's list
# makes no distinction between constraints and restraints and identifies 
only
# those currently available in SHELX. Further, constraints may be of two
# kinds, those required by symmetry (zero cross terms, for example) and 
those
# selected by the user (two atoms assigned exactly the same ADPs because,
# e.g., they occupy the same site). We have also just approved a new item:
# _refine_ls_restraints_weighting_scheme which provides for a description of
# the restraints used and their relative weights (though this item refers to
# the refinement as a whole whereas the item under discussion identifies the
# restraints applied to the ADPs of individual atoms).
#
# We either need to expand Curt's list to distinguish between different 
kinds
# of constraints and include all the possible restraints currently available
# (with a catch-all category for restraint not yet listed) or we should
# recognize that the flag is only meant to draw attention to the fact that
# this atom was not freely refined and further details of the restraint or
# constraint can be found in one of the text fields. I favour the latter
# approach but I am willing to entertain any other suggestions.
#
# THE EARLIER DISCUSSION FOLLOWS:
#
# 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 the following 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
#
#
#######################################
#
# Item 7
#
#######################################
#
# _diffrn_refln_status
#
# COMMENT: The purpose of this proposed item is to allow reflections 
that are
# believed to be systematically absent to be flagged. Although the 
assumption
# of a particular space group belongs properly to the refinement rather than
# the measurement stage of structure determination, a space group is usually
# assumed early in the measurement process and is used to direct the
# measurement strategy. There are occasions when some or all the systematic
# absences are measured in order to confirm the space group. This flag 
allows
# them to be identified either for further examination, or for exclusion 
from
# the reflection count.
# Note that there is already an item _refln_refinement_status with 
values of:
# incl(uded in refinement), excl(uded from refinement) and extn 
(extinguished,
# i.e. systematically absent.
#

data_diffrn_refln_status
_name '_diffrn_refln_status'
_category diffrn_refln
_type char
_list yes
_list_reference '_diffrn_refln_index_'
loop_
_enumeration
_enumeration_detail
incl 'Reflection expected to have non-zero intensity'
sysabs 'Reflection considered to be systematically absent'
_example
_definition
; A flag indicating whether a reflection was assumed to be
systematically absent during the measurement of the diffraction
intensities.
;
#
# COMMENT from Howard Flack 2003-06-27
# --------------------------------------
# What data item is used to record the "space group assumed during the
# measurement of the diffraction intensities." It does not make sense to
# flag the reflections unless you are told the 'assumed space group'.
# Indeed I have semantic problems with your 'assumed space group'. If you
# assumed a space group, you would have used this hypothesis not to
# measure the assumed space-group-absent reflections. In which case there
# are no reflections to flag. If you measured all reflections during data
# collection, you did not assume a space group. It sounds to me, according
# to your comment, that this is a flag for use in hypothesis testing in
# the style: If I assume such-and-such a space group, which reflections
# are systematically absent. However if you have trouble identifying the
# space group, it means that there are several competing hypotheses to
# take into account but the proposed data item only allows one hypothesis
# to be used.
#
# > incl
# > 'Reflection expected to have non-zero intensity'
#
# How about:
#
# notsysabs
# 'Reflection considered not to be systematically absent
# under the assumed space group'
# is much better. Where does 'incl' come from?
# Likewise:
#
# sysabs
# 'Reflection considered to be systematically absent under
# the assumed space group'
#
# How about:
#
# _definition
#; A flag indicating whether a reflection would be
# systematically absent under the assumed space group.
#;
# I think the proposed data item does not sound to be of much practical
# use. One would really want a table of statistics and a list of offending
# reflections for a collection of different space group hypotheses.
#
# COMMENT BY David Brown 04-01-07
# -------------------------------
# CIFs are not the place for working out hypotheses so we should not have
# several assumed space groups. Should this flag refer to the space group
# adopted used in the refinement and reported in the space_group category so
# that the user can scan the systematic
# absences to assess the validity of the assumed space group? Or is this a
# flag that is not really needed given that we already have
# _refln_refinement_status? Please let the group know your views.
#
# STATUS: Open for discussion.
# ----------------------------
#
#
##########################################
#
# Item 8
#
##########################################
#
# _geom_bond_multiplicity
#
# 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_multiplicity
_name '_geom_bond_multiplicity'
_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_multiplicity
Ni1 O1 1.789(3) 4
Ni1 O2 2.134(3) 2
;
'Gives the lengths of the six bonds around Ni1'

_enumeration_range 0:
_definition
; The number of times the given bond appears 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: Open for discussion
#
#
##########################################
#
# Item 9
#
##########################################
#
# Category refine_scattering_density
#
# COMMENT
# -------
# The current dictionary has items that give the maximum and minimum 
values of
# the difference scattering density. Users are encouraged to identify the
# positions of this maximum and minimum in a _*_details item.
#
# There are occasions when one might wish to give a list of peaks in an 
x-ray,
# electron or neutron scattering density map together with their positions.
# This category is designed to hold this information.
#

data_refine_scattering_density_[]
_name refine_scattering_density
_category null
_type category_overview
_example
; loop_
_refine_scattering_density_id
_refine_scattering_density_position_x
_refine_scattering_density_position_y
_refine_scattering_density_position_z
_refine_scattering_density_peak
_refine_scattering_density_details
1 0.0743 0.3568 0.4215 45.6 'probably Mo'
2 0.7358 0.2987 0.8932 43.2 'probably Mo'
3 0.8657 0.4518 -0.0654 25.8 ?
;
_definition
; This is a category in which the peak positions and heights in
the experimental scattering density map can be reported. The
nature of the scattering density is determined by the radiation
given in _diffrn_radiation_probe.
;
#
# QUERY
# -----
# _diffrn_radiation_probe is not always given. Should it have a default 
value
# of 'x-ray'?
#

data_refine_scattering_density_details
_name '_refine_scattering_density_details'
_category refine_scattering_density
_type char
_list yes
_list_reference '_refine_scattering_density_details
loop_ _example 'Probably Mo'
'Uncertain peak'
'Broad diffuse peak'
_definition
'A description of the scattering density peak'


data_refine_scattering_density_id
_name '_refine_scattering_density_id'
_category refine_scattering_density
_type char
_list yes
_list_mandatory yes
_example ?
_definition
; A code identifying this particular scattering density peak
;


data_refine_scattering_density_peak
_name '_refine_scattering_density_peak'
_category refine_scattering_density
_type numb
_list yes
_list_reference '_refine_scattering_density_id'
loop_
_units
_units_detail
e.A-3 'electrons per cubic angstrom for x-ray diffraction'
? 'for neutron diffraction'
? 'for electron diffraction'
e.A-3 'electrons per cubic angstrom for gamma ray diffraction'
_example ?
_definition
; The measured scattering density at the given position. The
units are determined by the value of _diffrn_radiation_probe.
;
#
# We need to add units above for neutron and electron diffraction. Is 
any one
# familiar with these units?
#

data_refine_scattering_density_position_
loop_
_name _refine_scattering_density_position_x
_refine_scattering_density_position_y
_refine_scattering_density_position_z

_category refine_scattering_density
_type num
_type_conditions esd
_list yes
_list_reference _refine_scattering_density_id
_example ?
_definition
; The positional coordinates in fractions of the unit cell at
which the electron density peak occurs.
;
#
# QUERY: The definitions above imply the full scattering density. Should we
# make provision of the difference density to be given instead or as 
well as?
# Should there be provision for partial difference maps, i.e., maps with 
only
# some atoms removed? How should this be done?
#
# STATUS: Open for discussion

#
#################################
#
# Item 10.
#
#################################
#
# _atomic_sites_solution_hydrogens
#
# COMMENT: This item is bundled with primary and secondary solution methods
# and for this reason there is no flag to indicate that the hydrogen atoms
# were not 'solved' i.e., located. We need a new flag for this case.
#
# Add to the enumeration, enumeration_detail loop the following

notdet 'coordinates were not determined'

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