Discussion List Archives

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

RE: CIF Core DMG Discussion #5

  • To: Distribution list of the IUCr COMCIFS Core Dictionary Maintenance Group <coredmg@iucr.org>
  • Subject: RE: CIF Core DMG Discussion #5
  • From: "Haltiwanger, Curt" <CHaltiwanger@bruker-axs.com>
  • Date: Fri, 27 Feb 2004 15:08:30 -0600
Colleagues,
I must apologize for my lack of input on the last set of discussions,
especially since I contributed to the thermal restraints discussion before.


My perspective on cifs in general is  - 
The cif should be a useful tool that allows a crystallographer to store
details of the experiment and to evaluate the quality of a reported result.
The cif must also allow crystallographers and other scientists access to the
data in a useful interpretable way for statistical studies.

My responses are driven by this perspective and my experience in single
crystal x-ray diffraction. I'd be interested in hearing the official mission
statement.  I wonder how close I am.  ???

Back to the point. 

Item 6

In general I agree with David that the task of coming up with a complete
list of constraints and restraints could be a never ending and thankless
task.   David's suggestion addresses my main objection, that a list that
dealt only with special positions and Uiso or Uij was incomplete given the
refinement programs that exist today.   Using .CTU as described by David,
takes care of most of the usual situations. 
However 
I am having trouble figuring out what the U on a hydrogen atom that is set
to 1.2 time the Ueq of the atom it is attached to would be constraint or a
restraint or something else.   This is common situation in many or most
structures with C-H's refined with SHELXL.  As I see it this treatment of
hydrogen atoms does not fit either of the definitions for constraints and
restraints.  I think it is important that we provide data items that allow
users to report what they actually do.

Using .CTU means that detailed information that the scientist put into the
refinement input file is lost.  If I were to try to repeat the refinement or
learn from the cif how a particular disorder or problem was handled some of
the information would be unavailable.  To avoid this loss of data and to
avoid having to come up with a complete and constantly evolving definition
of restraints and constraints, I think it would be quite useful to have an
official cif entry similar to _refinement_special_details, that would
contain a copy of the refinement input file.  Would _refinement_input_file
be a possibility?  I realize that this file would be of no use to anyone who
did not have access to that particular program or to a users manual for the
program.  I think it is much more significant that the scientist who did
have access to the program or manuals would have access to the information
that it is almost impossible for the cif to capture.  If someone did not
have immediate access, they would still have the option of getting a version
of the program.  At least the details would be present and the devil is in
the details.

So I don't think that we have exactly the right definition yet.  And I think
that we need a way of including input files in the cif.

Item 7

I add my vote in favor of Howard's redefinition if we must have
_diffrn_refln_status and I join both Howard and David's questioning of the
usefulness of the data item.   What knowledge that is not already in the CIF
is added.  Area detectors have huge amounts of information regarding on
systematic absences, but in most cases only those resulting from glides and
screws are processed during the integration, absences from centering are
typically not processed.  

As I write this, the most probable use that occurs to me would be if someone
was using the cif to store all of the reflection data as input to the next
step in the data processing and structure solution process.  If that is the
case then there are other items that would be interesting, x,y position on
the detector, frame and angle info, etc. I don't think that is a direction
that we want to go. 

Item 8

I associate bond multiplicity with single and double bonds.  Perhaps that is
more correctly referred to as bond order, but multiplicity seems to have the
possibility of being confusing. IUPAC defines Multiplicity as "The existence
of several degenerate wavefunctions distinguished only by the relative
orientation of the angular spin momentum. Defined by the total angular spin
momentum S, it is given by 2S+1."  Whatever that means.
How about _geom_bond_symm_count instead of _geom_bond_multiplicity 

Item 9

It is important to distinguish between electron density and electron density
map peaks.  Most programs and their users look only at peaks.  Large regions
of diffuse electron density (solvent columns and solvent molecules in large
holes come to mind) can be very hard to identify and describe.  If we are
going to come up with definitions to describe electron density, we need to
consider ways to deal with diffuse density.
I can not tell from the discussion here so far what information we are
trying to capture.  I thought initially that this would be a way to give
more details regarding residual difference electron density peaks, but from
the definitions difference density peaks are not included at all.  Does
anyone calculate refined scattering density?  Is this essentially what x-ray
folks would call an electron density map or an Fo map?  
I believe current accepted practice is to calculate a final difference map.
It makes sense to me to report the position and height of the largest peaks
and holes.  I look forward to hearing more discussion of this.  

Answers to explicit questions.
# -----
# _diffrn_radiation_probe is not always given. Should it have a default 
>>>>> Is a wavelength always for x-ray experiments?  
>>>>> Could the default be determined on the basis of the wavelength or lack
thereof?
# We need to add units above for neutron and electron diffraction. Is 
any one
# familiar with these units?
>>>>> I am not 
# 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?
>>>>> I would say yes definitely.  I think this is the most likely use of
such data. 
# Should there be provision for partial difference maps, i.e., maps with
only
# some atoms removed? How should this be done?
>>>> I don't think this is needed as a separate definition.  If the cif has
a list of atoms and a difference density peaks are reported then the
difference peaks are what is left.  If electron density peaks are reported
then they should be for all reported atoms plus any big peaks that are in
the list.  But doesn't this open up another of these things that could get
out of hand.  What about 2Fo - Fc maps?  Do we expect the user to report the
cut off criteria.  I think it goes back to who is going to use this for
what.  For the majority of small molecule scientists, this will never get
used or will be used only for difference peaks.

Again I am sorry for more poor record of response recently and for the fact
that this one is late too.  
Curt



-----Original Message-----
From: David Brown [mailto:idbrown@mcmaster.ca]
Sent: Friday, January 09, 2004 2:21 PM
To: coredmg@iucr.org
Subject: CIF Core DMG Discussion #5


?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
_______________________________________________
coreDMG mailing list
coreDMG@iucr.org
http://scripts.iucr.org/mailman/listinfo/coredmg

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