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

[James Hester]

Dear pdDMG,

This group having expressed no preference, I will go with leaving the
equivalent of pd_refln_phase_id out of the DDLm version, with the intention
that it will reappear in an extension dictionary. The advice to programmers
will be to put h,k,l loops into phase-specific blocks, with peak_id columns
included in those h,k,l loops if desired.

That concludes the list of pd issues. I will forward the DDLm version of
the powder CIF dictionary to COMCIFS for final approval.

James.

On 26 October 2016 at 11:01, James Hester <jamesrhester at 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
>



-- 
T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iucr.org/pipermail/pddmg/attachments/20161103/dc9e6ac9/attachment.html>