Discussion List Archives

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

Re: [pdDMG] DDLm pdCIF Issue 3: pd_refln should not add phase_id tothe main dictionary REFLN category

  • To: pddmg@iucr.org
  • Subject: Re: [pdDMG] DDLm pdCIF Issue 3: pd_refln should not add phase_id tothe main dictionary REFLN category
  • From: James Hester <jamesrhester@gmail.com>
  • Date: Thu, 3 Nov 2016 16:21:11 +1100
  • DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;h=mime-version:in-reply-to:references:from:date:message-id:subject:to;bh=2Wimsqsu77/KjFijeowdJBIRlXifTsBybZkjm03t3EY=;b=DsBVE+huFfYE+8FWyOmdIdWWeGE8rpm7yVYeNyjEsIFgedipymHUQKncRu/yoGG+c4ry1Qb/THZVWMrQ3vA2K2wRmIhqxk6GbYTDScmcoPwWDHIIfZvUptI/RpmRKuQc/Lm4ipZnsxX7qa8SusXYJCbqQ2nVbiw9VzJ4Ac1TEnWa/8GU2VgdZBDz3X0yUyCGeN/yYqOhxWV3AighcbiVNgs8Yi7cMWv2DnC6slT/tDUr6j5EH6ldavciQ/WBodsVwuEJTLPI0wTQBAiD8hYgQPobTQqVYAgFw5wIkUQei/v3AZZ9KbIpxnlsh3+B11WPDEgOswGAZEH/n709XqMgMQ==
  • In-Reply-To: <3D7647FC-9B8C-4C80-9011-09E12F054C10@anl.gov>
  • References: <EBC46265-7986-4F4C-A693-3FEEDAF7B8EF@anl.gov><3D7647FC-9B8C-4C80-9011-09E12F054C10@anl.gov>
(Brian's message was lost to the pd DMG in the IUCr servers somewhere - see below for the message itself)

It is clear from Brian's message that my option (1) of simply splitting out the hkl values into the phase-specific blocks is impractical, and I share Brian's dislike of (3). We are therefore left with alternative (2).  In practical terms, this means that any datablock that uses '_pd_refln.phase_id' in a reflection loop should also set the value of dataname _audit.schema to something that is not 'Base': possibly 'Multiphase' (any suggestions? 'Powder'?). 

The intent of the new _audit.schema approach is to allow for single-valued core CIF datanames to vary (such as phase), but to protect legacy software from misinterpreting these data files.  This means that we thankfully don't have to rethink the core CIF universe as a whole.

I will edit the draft cif_pow according to (2) and develop a remarkably short extension dictionary for this group to consider.  I will use a different subject heading for clarity.

James.


On 3 November 2016 at 15:33, Toby, Brian H. <toby@anl.gov> wrote:


Begin forwarded message:

From: Brian Toby <toby@anl.gov>
Subject: Re: [pdDMG] DDLm pdCIF Issue 3: pd_refln should not add phase_id to the main dictionary REFLN category
Date: October 25, 2016 at 9:33:36 PM CDT
To: Distribution list of the IUCr COMCIFS Powder Diffraction Dictionary Maintenance Group <pddmg@iucr.org>

I remember this issue well. Perhaps there is now a way around this, but it was absolutely essential to have duplicate hkl values in a loop since it was not possible to have multiple reflection loops in a single data_ block. At present a typical CIF for a refinement with n phases and m histograms (n + m > 2) will have n+m+1 blocks. If a separate block is needed for each phase within each histogram, we are looking at circa n*(m+1) blocks and a very complex set of pointers to have that all make sense. 

Suggestion (1) below will not work because there will be a need to have up to m reflection lists in each phase block. I cannot comment on (2) and I dislike (3). My comment would be that the initial definition for reflection lists was overly myopic (or at least is single-crystal centric) and needs to be rethought. 

Brian

On Oct 25, 2016, at 7:01 PM, James Hester <jamesrhester@gmail.com> wrote:

Dear PDDMG:

The original DDL1 pdCIF envisages the refln loop in core_cif being enhanced with a phase_id column. This is problematic for general software that doesn't know about pdCIF. Such software will assume that a row is uniquely identified by (h,k,l), or in other words, that the other items in the refln category are functions purely of (h,k,l) and constant-valued datanames (e.g. space group) from elsewhere in the datablock. Use of (h,k,l) from multiple phases will lead to silent errors in such software as 'phase' is assumed to be constant. For example, a Fourier transform routine that simply takes every row in REFLN as input to the transform might silently produce an incorrect result rather than dying noisily. We have recently found a couple of other places in core cif (multiple space groups and multiple crystals) that create the same type of problem, and removed them.

Losing the ability to list hkl from multiple phases is obviously a backward step.  There are 3 alternative solutions I can see:

(1) HKL lists can instead appear in the linked 'phase' datablocks, with pd_refln.peak_id columns that can be used to trace back an hkl value to a particular peak in the linked 'data' datablock.  In this case, pd_refln.phase_id is not necessary as the datablock that the hkl list appears in sufficient to identify the phase.

Advantages: general CIF software that knows nothing of powder diffraction will be able to correctly manipulate the various phases in the separate datablocks, including manipulations of the reflection list. Zero dictionary work required.
Disadvantages: pdCIF software written in accordance with DDL1 pdCIF might need to change how reflection lists are output

(2) Creating an extension dictionary that uses a non-default value of new dataname '_audit.schema' to signal that multiple phases are present in the refln list. This dictionary would contain pd_refln.phase_id. A description of the way that _audit.schema is intended to work is available at https://github.com/COMCIFS/comcifs.github.io/blob/master/looping_proposal.md

Advantages: Reproduces DDL1 behaviour, which was presumably chosen for a reason, and will accord with what pdCIF software is currently outputting (modulo the _audit.schema dataname)
Disadvantages: Some dictionary work and discussion required. Most/all general CIF software will not attempt to manipulate pdCIF hkl lists (although automated transformation to type (1) is possible).

(3) pdCIF defines its own hkl datanames and so does not attempt to integrate with REFLN in core_cif.

Advantages: ?
Disadvantages: repeats already perfectly good definitions; general CIF software that would otherwise be useful is not useable

Supporting all three approaches is also possible but creates extra work for authors of pdCIF reading software.

Does this group have any preference?

James.

--
T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148
_______________________________________________
pdDMG mailing list
pdDMG@iucr.org
http://mailman.iucr.org/cgi-bin/mailman/listinfo/pddmg

********************************************************************
Brian H. Toby, Ph.D.                            office: 630-252-5488
Advanced Photon Source Chief Computational Scientist
Senior Physicist/Computational X-ray Science Group Leader
9700 S. Cass Ave, Bldg. 401/B4192                 cell: 630-327-8426     
Argonne National Laboratory        
Argonne, IL 60439-4856         e-mail: brian dot toby at anl dot gov 
********************************************************************
"We will restore science to its rightful place, and wield technology's wonders... We will harness the sun and the winds and the soil to fuel our cars and run our factories...  All this we can do. All this we will do."


********************************************************************
Brian H. Toby, Ph.D.                            office: 630-252-5488
Advanced Photon Source Chief Computational Scientist
Senior Physicist/Computational X-ray Science Group Leader
9700 S. Cass Ave, Bldg. 401/B4192                 cell: 630-327-8426     
Argonne National Laboratory        
Argonne, IL 60439-4856         e-mail: brian dot toby at anl dot gov 
********************************************************************
"We will restore science to its rightful place, and wield technology's wonders... We will harness the sun and the winds and the soil to fuel our cars and run our factories...  All this we can do. All this we will do."




--
T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148
_______________________________________________
pdDMG mailing list
pdDMG@iucr.org
http://mailman.iucr.org/cgi-bin/mailman/listinfo/pddmg

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