[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 <coredmg@iucr.org>
- Subject: Comments on CIF core changes for 2.3
- From: "Haltiwanger, Curt" <CHaltiwanger@bruker-axs.com>
- 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):