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 15:19:56 +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=AZyAWSni+x/e9UQWofMGHRzd32r6p4fpvG9cHNYj0AE=;b=ZrikWsRRJ4ZJdmyDtb9AS5gPSukvSxQzWmY6dQ2o9oLn6ITh5Pr5CxLcoxIg5jT8HsR5caDk18PW/Nv+G6zuYYam7Es6uXVfPtZVRFrZQ33t4SrjqBxuEP2TNdQ401edTFDlmZ19EMsf9I1Ik35/0zb+T3wd9P784kImU0AHJp0egEQv25rXZ8Bn8PDQZ7q1cMQB0RTYQR1Ylts4i/1ww7XYKopFkHEAwIfPNPDeo7rhoIrsn5HIxFtYCuBplsg65RlTIPdr2OOCVWfHyqJ6mrgVRitgvj7zIMin0ZJeG7StbeqGRRT63pqP/e2wpnh+h11bvileILHBE28hcID6Ug==
  • In-Reply-To: <CAM+dB2c+ED8t=9sJLYrYZKYNmdFAyvLqWTh4Y30bJuyDZn8gYg@mail.gmail.com>
  • References: <CAM+dB2c+ED8t=9sJLYrYZKYNmdFAyvLqWTh4Y30bJuyDZn8gYg@mail.gmail.com>
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@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
_______________________________________________
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)]