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

[ddlm-group] How should we handle alternative models for F_calc?

  • To: ddlm-group <ddlm-group@iucr.org>
  • Subject: [ddlm-group] How should we handle alternative models for F_calc?
  • From: James Hester <jamesrhester@gmail.com>
  • Date: Wed, 23 Nov 2016 12:18:20 +1100
  • DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;h=mime-version:from:date:message-id:subject:to;bh=tSfjPBXAL1EAkWnK+goYZNsMgnnVD9gS0Gb5OO0zJIM=;b=DW7TgzovJzwD/FInUcz7qqN0Xwp5aUx/C0pJ4ul6pk5ogVnCDSPUmzdzfLug2nSP340aVxfs3CDbG1evZyVQ5+IgcolbAu2yEP8H3w7fhzDJbRWSTcSTvuJDVoS1q4z5slFL6ld4gTTo/i7eXROXwrKfI8yGmL0dJb2g8Oqhld1O2MiTjwOrK6WdCsrTsQGK7avCL5OLsHIdKCCjaGSKiTfj3HZe+G/9DMaO4J9toK0yE7KoUjyHIJUd8ArXEEC0JmEh3M5Jvc4xedW96NDowteJYyGvM6EueMzJevjrIIAhGymN6K493CgqllNYTjQ3nGDeySuX6k69LSmelL5ihQ==
Dear DDLm-group,

My current preparation of the DDLm version of the modulated structure dictionary has revealed a troublesome, and in hindsight obvious, fact: this dictionary redefines F_calc through its use of a more sophisticated structural model. This runs counter to our undertaking to never redefine a dataname. I cannot find any public discussion of this from around the time that msCIF was introduced, so I assume that F_calc is seen as "the model structure factor", with "the model" being determined by context.  However, if we adopt this approach a standard structural program, written without knowledge of msCIF and fed with an msCIF-conformant datafile would calculate incorrect F_calcs despite a correct understanding of the meanings of datanames defined in core CIF.  Note that several other quantities in the REFLN category are in the same boat, e.g. refln.d_spacing.

This issue is not restricted to modulated structures. The new magnetic dictionary, which provides parameters for modelling the additional magnetic contribution to the structure factor, has also left F_calc untouched. As it is entirely possible that further new models will be incorporated into CIF over the coming years, we need to find a way to handle this explicitly.  I am appealing to this group in the hope that we can develop a proposal that we can present to COMCIFS.

In our considerations, we need to ponder how we would handle combinations of various models. Strictly speaking, we have powder, twinned, modulated, (multipole?) and magnetic models at present.  While twinning and powder cannot be mixed, all combinations of the others are quite common. For example, how do we handle the REFLN category for a twinned modulated magnetic structure?  Or a powder diffraction experiment on a modulated magnetic structure?  (Incidentally, both of these are routine experiments in the guide hall outside my window).

A few of the alternatives that I can see:

(1) An obvious and easy to understand solution is to define new datanames, perhaps belonging to new categories, for each alternative model, so for a modulated structure we might have _refln_modulated.F_calc,  _refln_modulated.d_spacing etc.  An immediate consequence of this approach would be to require a new set of refinement statistics in refine_ls, as the current statistics are based on the match between refln.F_calc and refln.F_meas - so for each model, we would have a set of refinement statistic datanames. This would also be true for any other datanames that are derived from F_calc, e.g. difference density.  All of these datanames would be defined in the appropriate specialist dictionary.  Under such an approach, non msCIF-aware software would calculate F_calc and associated refinement statistics correctly, although these "average structure" values would be less useful for assessing data quality. 

(2) An approach that captures the current behaviour is to define a new dataname that labels the particular model used in a datablock (e.g. _audit.model).  As with _audit.schema, we advise all CIF input software authors to check the value of this dataname, and if it does not conform to the model that the software expects, then the software may exit or otherwise avoid silently performing an incorrect calculation.  This of course requires that authors of CIF output software include a value for this new dataname if they are using any model that is non-standard (i.e. not core CIF).  The two fundamental issues with this approach are (i) that it essentially redefines at least F_calc (although this is what is happening at the moment anyway) and (ii) that it contradicts a CIF principle that the value of one dataname should not change the way in which another is interpreted.  I believe that this principle is intended to encourage identifying separate concepts with separate datanames (i.e. approach (1)), although long-term COMCIFS observers may be able to shed more light on it.  In any case, COMCIFS, in its wisdom, may like/not like to consider overriding this principle for something as fundamental as the structural model. 

In the case of _audit.schema, the _audit.schema dataname is just shorthand for information that could be gleaned from the actual dictionaries themselves. Likewise, if we go with approach (2) I think it is worthwhile making sure that we specify what is happening semantically when _audit.model is changed. My initial stab at this is that a given value for _audit.model implies replacing (at least) the REFLN category, where values of datanames from the old category must be obtainable from the new category by setting a specified set of parameters to default values.  This latter stipulation captures the fact that all of these models expand the basic model.  Indeed, instead of 'replacement' maybe we can think in terms of 'overlays' where the final REFLN category is the result of summing the F_complex datanames of the individual models used - so a twinned modulated magnetic structure would conform to the twinning, magnetic and modulated dictionaries, each one of which would contribute something additional to the core CIF REFLN category.  Some new category-level DDLm attributes would be needed to express this.

I look forward to your thoughts on this.

best wishes,

T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148
ddlm-group mailing list

Reply to: [list | sender only]