[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Send comment to list secretary]
[Reply to list (subscribers only)]
Comments on CIF core changes for 2.3
- To: Multiple recipients of list <[email protected]>
- Subject: Comments on CIF core changes for 2.3
- From: "Haltiwanger, Curt" <[email protected]>
- Date: Sat, 12 Jul 2003 18:28:35 +0100 (BST)
I have the following comments and questions based on the
cifCoreDic-2.3approved.txt attached to Brian's e-mail of July 10
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.
;
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 has the provision for several atoms to have exactly
the same adp's or some multiplier times the These would also be a
candidate for enumeration. I have no knowledge of the restraints and
constraints used in other programs.
So
S 'special-position constraints on atomic displacement
parameters'
R 'adp in the direction of connecting bond are restrained to
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 multiplication factor 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 )'
######################################################################
data_atom_site_refinement_flags_occupancy
_name '_atom_site_refinement_flags_occupancy'
_category atom_site
_type char
_list yes
_list_reference '_atom_site_label'
loop_ _enumeration
_enumeration_detail . 'no constraints on site occupancy
parameters'
P 'site occupancy constraint'
_definition
; A code which indicates that refinement restraints or
constraints were applied to the occupancy of this site.
;
What is partial occupancy constraint?
The most common restraint to occupancy is that the occupancies two partial
occupancy sites sum to a constant (usually 1. but 0.5 etc for special
position sites) Also if the disorder is over three or more positions the
sum of the occupancies can restrained to be a constant.
######################################################################
data_diffrn_reflns_measured_fraction_resolution_full
_name '_diffrn_reflns_measured_fraction_resolution_full'
_category diffrn_reflns
_list yes
_type numb
_enumeration_range 0: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.
This number should be very close to 1.0, since it represents the
fraction of reflections measured in the part of the diffraction
pattern that is essentially complete.
;
# COMMENT: Replacement for _diffrn_measured_fraction_theta_full, moved to a
# more appropriate category and defined in terms of resolution rather than
# angle which depends on the radiation used.
# 2003-06-26 _related_function 'replace' changed to 'alternate'
# STATUS: Preliminary approval 2002-11-11
There is the potential for confusion here.
We currently have
_diffrn_measured_fraction_theta_full
_diffrn_measured_fraction_theta_max
_diffrn_reflns_theta_full
_diffrn_reflns_theta_max
and we are adding
_diffrn_reflns_measured_fraction_resolution_full
_diffrn_reflns_measured_fraction_resolution_max
_diffrn_reflns_resolution_full
_diffrn_reflns_resolution_max
In the experiment, I would think that
_diffrn_reflns_measured_fraction_resolution_full (or _max)
will be the same as the _diffrn_measured_fraction_theta_full (or _max). I
can see the value of talking in terms of resolution rather than theta,
(although I am more comfortable with angles) but why have two data names
that describe the same number. Why not define terms
_diffrn_reflns_measured_fraction_full and
_diffrn_reflns_measured_fraction_max
leaving out all reference to whether it is based on resolution or theta
In addition the numbers currently being reported by a popular refinement
program are based on what that refinement program is receiving as input, not
what the data reduction program (integration program) had as input or
output. Do we need or want entries similar to what currently exists in the
dictionary for this situation.
For example reflns_limit_ and diffrn_reflns_limit_ where the two values do
not need to be the same as the first refers to the values used for
refinement and the second to values in the data collection.
Which are the more relevant numbers, the numbers related to refinement, or
measurement, or both?
######################################################################
data_diffrn_standards_decay_%_lt
_name '_diffrn_standards_decay_%_lt'
_category diffrn_standards
_type numb
_related_item '_diffrn_standards_decay_%'
_related_function alternate
_enumeration_range :100
_definition
; An upper limit on the percentage decrease in the mean
intensity of the set of standard reflections measured at the
start of the measurement of the diffraction pattern and at
the
end. This value is used when the decay is too small to be
detected.
;
# COMMENT: Many experiments show no detectable decay and there is no
provision
# for this at the moment other than to enter 0.0.
# STATUS: Preliminary approval 2002-11-11
I like the concept, but I wonder about its usage to create tables. I have
never written
such programs, but seems complicated to me to have a table entry for crystal
decay that looks at two different cif items to decide which one to use.
I would guess that this item is being introduced because crystal decay is
almost certainly never 0.0%. Wouldn't it be simpler to change the
definition of '_diffrn_standards_decay_%' to reflect that decay corrections
are approximate, not exact numbers.
######################################################################
data__diffrn_reflns_measured_fraction_resolution_max
_name '_diffrn_reflns_measured_fraction_resolution_max'
There is a double __ here.
######################################################################
#
# THE PREVIOUS ITEM REPLACES _symmetry_cell_setting. The definition of the
old
# item should be modified to make it clear that the old name is discontinued
# (the name is crystallographically incorrect and therefore misleading).
The
# following items should be added to the dictionary entry for
# _symmetry_cell_setting:
#
# _related_item '_space_group_crystal_system'
# _related_function replace
#
# Incidentally I have removed the _related_item and _related_function from
the
# definition of _space_group_crystal_system because they are incorrect. It
is
# the _related_item that should 'replace' the item being defined, not the
other
# way around.
#
So what happens to _space_group_crystal_system?? Should there be a
replaced or obsolete.
######################################################################
data_space_group_symop_operation_xyz
_name '_space_group_symop_operation_xyz'
_category space_group_symop
_list both
_list_mandatory no
_list_reference '_space_group_symop_id'
loop_
_example
_example_detail
'x,1/2-y,1/2+z' 'c glide reflection through the plane
(x,1/4,z)'
_definition
; A parsable string giving one of the symmetry operations of
the
space group in algebraic form. If W is a matrix
representation
of the rotational part of the symmetry operation defined by
the
positions and signs of x, y and z, and w is a column of
translations defined by the fractions, an equivalent
position
X' is generated from a given position X by the equation:
X' = WX + w
(Note: X is used to represent bold_italics_x in
International
Tables for Crystallography Vol. A, Section 5)
When a list of symmetry operations is given, it is assumed
that the list contains all the operations of the space
group (including the identity operation) as given by the
representatives of the general position in International
Tables for Crystallography Vol. A.
;
_type char
_enumeration_default 'x,y,z'
# STATUS: Preliminary approval 2003-03-11
Doesn't c-glide define reflection and if so isn't reflection redundant?
I don't see how the example detail helps the definition. I would like to
see a fuller example but I do not know how to set it up to give something
that looks like this.
Thus for the symmetry operators for
P212121 should be
x,y,z
-x,1/2+y,1/2-z
1/2-x,-y,1/2+z
1/2+x,1/2-y,-z
and for C2/m (setting ???? )
x,y,z
x,1/2-y,z
or should it be
and for C2/m (setting ???? )
x,y,z
-x,-y,-z
x,1/2-y,z
-x,1/2+y,-z1/2+x,1/2+y,z
1/2-x,1/2-y,-z
1/2+x,-y,1/2+z
1/2-x,y,1/2-z
I must admit that until I read (or misread) Howard's comments I would have
made C2/m look like the simpler example.
The suggested extended examples could help resolve ambiguities. Perhaps the
extended example could also include a non standard setting.
######################################################################
[Send comment to list secretary]
[Reply to list (subscribers only)]
- Prev by Date: Re: Approval of CIF core changes for 2.3
- Next by Date: Re: Comments on CIF core changes for 2.3
- Prev by thread: Re: update / Twinning
- Next by thread: Re: Comments on CIF core changes for 2.3
- Index(es):

