Discussion List Archives

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

RE: core_cif review note: _diffrn.crystal_id removed

I should point out that the multiple crystal feature was added  because of requests from users. It may not be needed for routine work, but it is needed for archival purposes and in some cases for submission of papers to journals. Not every program needs to be able to handle multiple crystal files, but the feature needs to be present for those cases where the structure determination is dependent on the use of different crystals.


I. David Brown
Professor Emeritus
Department of Physics and Astronomy
McMaster University
Hamilton, Ontario, Canada

From: coreDMG [coredmg-bounces@iucr.org] on behalf of James Hester [jamesrhester@gmail.com]
Sent: September 7, 2016 21:28
To: Distribution list of the IUCr COMCIFS Core Dictionary Maintenance Group
Subject: core_cif review note: _diffrn.crystal_id removed

Dear Core DMG,

In the course of removing unneeded keys (as per a previous email), I noted that the draft core dictionary is inconsistent as to whether or not multiple crystals are supported.   Referring to Vol G, the original DDL1 core allowed multiple crystals to be listed in exptl_crystal, and these crystal ids could be included in the diffrn_refln and refln lists.  The new draft core adds these crystal ids to the exptl_crystal_face category (not too problematic) and to the diffrn category. The latter is nominally a set category (one value per dataname in DDL1) and so couldn't refer to more than a single crystal id.  I have therefore removed crystal_id from this category in the updated draft, which now accurately reflects the state of the DDL1 dictionary.

Looking to the future, we do now have an elegant solution for handling multiple crystals, by making use of the new _audit.schema arrangement. In an ideal world, the core dictionary would assume only one crystal, and a small expansion dictionary associated with a non-default value of _audit.schema would define exptl_crystal.id and the keys listed in the previous paragraph.  In this ideal world, software that did not want to deal with multiple crystals could happily stick to the default schema.

It's not clear to me how much the multiple crystal definitions in the DDL1 core are actually used. It would be great to have some comments, especially from software authors, as to whether or not they input/output _exptl_crystal_id as defined in the current DDL1 core dictionary.  For example, would your software input and process CIFs correctly if the reflection list contained multiple instances of the same h,k,l, each from different crystals? Do you actually output _refln_crystal_id in the reflection list?

I am currently preparing a core CIF draft containing the various small revisions described in this and previous emails and should have it available for you by the end of the week.

all the best,
coreDMG mailing list

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