[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Send comment to list secretary]
[Reply to list (subscribers only)]
Re: Draft changes to Core data names for multiplicity etc.
- To: email@example.com
- Subject: Re: Draft changes to Core data names for multiplicity etc.
- From: George Sheldrick <firstname.lastname@example.org>
- Date: Thu, 17 May 2012 09:59:31 +0200
- In-Reply-To: <20120516103234.GA13856@emerald.iucr.org>
- References: <20120516103234.GA13856@emerald.iucr.org>
Dear Brian et al., I am planning to release a new version of SHELXL this summer (in time for the ACA Meeting) so your email was timely. I do not like to release a new version more than about once a decade, but I try to debug that version properly before releasing it. To correct my misunderstanding of the 'multiplicity' I have changed '_atom_site_symmetry_multiplicity' to '_atom_site_site_symmetry_order' as you suggest, which will also be consistent with remediated CIFs. However I would like a guarantee that this will not generate an Alert A because _atom_site_site_symmetry_multiplicity is missing (it really isn't necessary to give both). However this does not solve a closely related problem, namely how to define these terms when a disordered atom or molecule is close to but not precisely on a special position. A very common example is a toluene solvent molecule trying to sit on an inversion center. In the SHELX world, the solution is to set the occupancy of all the toluene atoms to the value appropriate to the special position, e.g. 0.5. This has worked well without any problems in SHELX refinements for the last 40 years, the unit-cell contents and structure factors are calculated correctly. It is less clear what to do in the CIF file which defines occupancy differently and so also had to introduce the concept of multiplicity that is not used by SHELX. One needs to take into account that one of the toluene atoms might accidentally be almost exactly on the inversion center, and so might be assigned a different multiplicity and occupancy than the other atoms in the toluene molecule. How close should an atom be to a special position to be assigned its multiplicity? To make it more complicated, a toluene molecule trying to sit on a position of mmm symmetry might have exact mm2 but not mmm symmetry. etc. The situation may be clear to a chemist but not easy to code in a completely robust and general way. There is a possible (even elegant) solution but I will only implement it if you agree, but if not please suggest a better alternative! In a SHELX refinement, a (solvent) molecule trying to occupy a position that has higher symmetry than the molecule itself is invariably assigned a negative PART number to suppress the generation of meaningless bonds etc. It would be possible for me to use this information to assign the whole (e.g. toluene) molecule the CIF _order (or _multiplicity) appropriate to the special position, the (CIF) occupancy of all its atoms would then be 1. This would merely require a slight extension to the CIF definitions of multiplicity and order, namely that they can be applied either to atoms or to groups of atoms. I have already implemented two new further CIF names that I did not preface with 'shelx' because I would like COMCIFS to consider them for general use. They are: _reflns_Friedel_fraction_max and _reflns_Friedel_fraction_full They are defined as the number of Fiedel pairs measured divided by the number theoretically possible (ignoring reflections in centric projections and systematic absences throughout); _max and _full have their usual meanings. In contrast to _reflns_Friedel_coverage they can take values in the full range 0 to 1 for any non-centrosymmetric space group, and so one can see at a glance how completely the Friedel pairs have been measured. For centrosymmetric space groups they would be 0/0 and so are given as '.'. I have also implemented a change, suggested by Ton Spek, that has far-reaching consequences but also resolves some long-standing problems. It is often difficult to decide when to refine a non-centrosymmetric structure against data averaged according to the Laue group or the point group, especially in view of improvements in data quality. The problem is that the least-squares standard uncertainties are proportional to 1/sqrt(N-P), where N is the number of observations and P the number of parameters refined. The same problem arises in refinements against twinned data, where one unique reflection may contribute to several 'observations'. This even leads to carefully measured experimental data being thrown away, which is clearly not good science. Ton's solution was to always make N equal to the number of unique Laue averaged data (rather than the number of 'observations') when estimating the standard uncertainties. It is important that referees and editors are made aware of this change, which will mean that it will no longer matter whether the data used in the refinement are redundant or not. A possible side-effect is that in some cases the su's may increase a little, but they tended to be underestimated anyway. In answer to your question, I have no objection to a su being allowed for the wavelength, provided that it is not obligatory (i.e. would generate a CheckCIF Alert A if absent). Best wishes, George On 05/16/2012 12:32 PM, Brian McMahon wrote: > Dear Colleagues > > This message is being sent to members of the CIF Core Dictionary > Management Group, who are requested to respond to it at your > earliest convenience. A copy will also be sent to other software > developers for their early information. > > Some programs have output values for the core data item > _atom_site_symmetry_multiplicity that are actually the order > of the space-group site symmetry and not the multiplicity as > defined in International Tables. As a result, the values given > in CIFs in the IUCr archive and elsewhere are ambiguous. > > It is proposed to remove this ambiguity by deprecating the > existing data name _atom_site_symmetry_multiplicity and replacing it > with two new names, > _atom_site_site_symmetry_multiplicity > _atom_site_site_symmetry_order > formal definitions of which are given below. > > This will allow future "remediation" of the IUCr CIF archive to > remove this ambiguity; and software authors may cleanly update their > output in the next release cycle of their programs. In practice, > we think that the usage of existing CIFs will not be greatly affected, > since most programs do not import and use the site multiplicities > directly; but by making this formal change we will also be drawing > attention to the need for end-users who do rely on this value to > validate it before use. > > Please let us know whether you agree to, or have any objections to > this approach, as soon as possible. > > For your information, it is proposed also to make two small editorial > changes to other data items (clarifying that F(000) may be given > in the case of neutron diffraction experiments, and sanctioning the > use of standard uncertainties when quoting the wavelength, as is > practice in powder diffraction). The details are also included below. > > Best wishes > Brian McMahon > COMCIFS Coordinating Secretary > > ------------------------------------------------------------------- > > _dictionary_history > ; > (extract) > 2012-05-15 BMcM: Deprecated _atom_site_symmetry_multiplicity; > replaced with _atom_site_site_symmetry_multiplicity > and added _atom_site_site_symmetry_order (IDB) > Reworded _exptl_crystal_F_000 definition to take > account of neutron diffraction and removed > _enumeration_range (can be negative for neutrons) > Added '_type_conditions su' to _diffrn_radiation_wavelength > ; > > data_atom_site_symmetry_multiplicity > _name '_atom_site_symmetry_multiplicity' > _category atom_site > _type numb > _list yes > _list_reference '_atom_site_label' > _related_item '_atom_site_site_symmetry_multiplicity' > _related_function replace > _enumeration_range 1:192 > _definition > ; The multiplicity of a site due to the space-group symmetry as > given in International Tables for Crystallography Vol. A (2002). > > Use of this data name is deprecated because of > inconsistencies in practice among structure refinement > software packages. The number of positions given for > this Wyckoff site in International Tables for > Crystallography Vol. A (2002). should now be expressed > using the data name _atom_site_site_symmetry_multiplicity. > In the historic archive some CIFs use this item to give values > that belong in _atom_site_site_symmetry_order. > ; > > data_atom_site_site_symmetry_multiplicity > _name '_atom_site_site_symmetry_multiplicity' > _category atom_site > _type numb > _list yes > _list_reference '_atom_site_label' > _related_item '_atom_site_symmetry_multiplicity' > _related_function alternate > _enumeration_range 1:192 > _definition > ; The number of different sites that are generated by the > application of the space-group symmetry to the > coordinates given for this site. It is equal to the > multiplicity given for this Wyckoff site > in International Tables for Crystallography Vol. A (2002). > It is equal to the multiplicity of the general position > divided by the order of the site symmetry given in > _atom_site_site_symmetry_order. > ; > > data_atom_site_site_symmetry_order > _name '_atom_site_site_symmetry_order' > _category atom_site > _type numb > _list yes > _list_reference '_atom_site_label' > _enumeration_range 1:48 > _definition > ; The order of the site symmetry of the site identified by > _atom_site_label. > > This is the number of times application of the > crystallographic symmetry to the coordinates given for > this site generates the same set of coordinates. > It is equal to: > > multiplicity of the general position > ------------------------------------ > multiplicity of this site > > where 'multiplicity of this site' is > given in _atom_site_site_symmetry_multiplicity. > ; > > data_diffrn_radiation_wavelength > _name '_diffrn_radiation_wavelength' > _category diffrn_radiation_wavelength > _type numb > _type_conditions su > _list both > _list_reference '_diffrn_radiation_wavelength_id' > _enumeration_range 0.0: > _units A > _units_detail 'angstroms' > _definition > ; The radiation wavelength in angstroms. > ; > > data_exptl_crystal_F_000 > _name '_exptl_crystal_F_000' > _category exptl_crystal > _type numb > _list both > _list_reference '_exptl_crystal_id' > _definition > ; The expression for a structure factor evaluated in the > zeroth-order case h = k = l = 0, F(000). This may contain > dispersion contributions and is calculated as > > F(000) = [ (sum f~r~)^2^ + (sum f~i~)^2^ ]^1/2^ > > f~r~ = real part of the scattering factors at theta = 0 > f~i~ = imaginary part of the scattering factors at theta = 0 > > the sum is taken over each atom in the unit cell > > For X-rays, non-dispersive F(000) is a positive number > and counts the effective number of electrons in the unit cell; > for neutrons, non-dispersive F(000) (which may be negative) > counts the total nuclear scattering power in the unit cell. See > http://reference.iucr.org/dictionary/F(000) > ; > > ------------------------------------------------------------------------------ > Brian McMahon tel: +44 1244 342878 > Research and Development Officer fax: +44 1244 314888 > International Union of Crystallography e-mail: email@example.com > 5 Abbey Square, Chester CH1 2HU, England > _______________________________________________ > coreDMG mailing list > coreDMG@iucr.org > http://mailman.iucr.org/mailman/listinfo/coredmg > -- Prof. George M. Sheldrick FRS Dept. Structural Chemistry, University of Goettingen, Tammannstr. 4, D37077 Goettingen, Germany Tel. +49-551-39-3021 or -3068 Fax. +49-551-39-22582 _______________________________________________ coreDMG mailing list coreDMG@iucr.org http://mailman.iucr.org/mailman/listinfo/coredmg
[Send comment to list secretary]
[Reply to list (subscribers only)]
- Draft changes to Core data names for multiplicity etc. (Brian McMahon)
- Prev by Date: Re: Draft changes to Core data names for multiplicity etc.
- Next by Date: Re: Draft changes to Core data names for multiplicity etc.
- Prev by thread: Re: Draft changes to Core data names for multiplicity etc.
- Next by thread: Re: Draft changes to Core data names for multiplicity etc.