Discussion List Archives

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

Powder CIF Proposals for Indexing

  • To: Multiple recipients of list <pddmg@iucr.org>
  • Subject: Powder CIF Proposals for Indexing
  • From: "Brian H. Toby" <Brian.Toby@nist.gov>
  • Date: Fri, 6 Oct 2000 21:12:15 +0100 (BST)
"ROBIN SHIRLEY (USER)" wrote:
> ...the principle on which CIF standards are built is that CIF files
> exist primarily to record measured data, plus various derived
> quantities that have been obtained from measured data by calculation.
> Of course such derived quantities also introduce an element of
> model-building and hence of hypothesis, but CIF definitions tend to
> downplay this aspect.

This is a valid point with respect to CIF. CIF was planned as a standard
format for communication of results with no (or at least little) thought
to capturing intermediate results, as an experiment is analyzed. I want
to see pdCIF applied all the way from [Eulerian] cradle-to-grave (aka
publication) activities, but this sometimes makes pdCIF hard to
implement. 

In most cases, it is possible to use loops for storing multiple models
(I'll give an example later), but in some cases that does not work. For
example, to store more than one model structure (for example to consider
different subgroups) one must use multiple blocks.

00-2-11.1) _pd_proc_quadr_Q  (or _pd_index_quad_Q - see discussion
 below)

> At each stage during indexing, a particular set of observed Q values
> will be used, which often remains the same throughout the indexing
> process.  However, these Q values *need not* be derived in the same
> way for each line.
> 
> ...Similarly, because the positions of individual low-angle lines are
> particularly important for some indexing methods and are often
> harder to measure accurately than those at higher angles, it may be
> beneficial to make adjustments based on lines at higher angles that
> appear to be their higher orders.
 
I can see now the argument that the peak positions used for indexing may
well differ from other, more internally-consistently peak positions,
since an experienced indexer may well want to "tweak" the list. I now
agree that it makes sense to have a peak position data name for
indexing. 

I must admit that I would prefer these values be stored in Q or
sin(theta)/lambda than d-space or Q*10000, but I would very much like to
hear points of view that conflict with mine.

> On reflection, I am now persuaded that, since these data are actually
> specific to the indexing stage, it might be preferable to move it to
> _pd_index_ so that it would become _pd_index_quadr_Q.  An equivalent
> version might be _pd_index_d_spacing (I would prefer both to be
> defined, but would settle for either).

I am convinced now in the need for an indexing section
 
00-2-11.2) _pd_index_appendix
> 
> Brian queried whether this might be accommodated within _pd_refln_.
> I would argue strongly for a distinct section for indexing (and now
> favour moving all indexing-specific items into it, such as quadr_Q
> and index_merit - see below).

I support this.

00-2-11.3) _pd_proc_index_merit (or _pd_index_merit - see discussion
> below)

> ...The bottom line here is that since all programs tackle such
> implementation issues a bit differently, it is desirable to record
> the program as well as the FOM measure.  Thus I propose that three
> items are needed per FOM entry: first the value (M) then the name of
> the FOM ( usually M or M20), then the name of the program version
> concerned (*not* that of an attributed FOM author such as Snyder or
> Visser) which the Powder CIF standard obviously could not predefine.
> 
> Thus this would become:
>    _pd_index_merit M FOM program
> 
>    (e.g. _pd_index_merit 21.7 M20 ITO12,
>    or _pd_index_merit 54.215 M1 CRYS934h).

This is not valid CIF, though _pd_index_merit '21.7 M20 ITO12' would be,
but CIF [usually] avoids definitions that require parsing a data item.

Robin is correct this is best handled with a new loop such as:

loop_
	_pd_index_merit_value
	_pd_index_merit_method
	_pd_index_merit_program
	_pd_index_cell_length_a
	_pd_index_cell_length_b
	_pd_index_cell_length_c
	_pd_index_cell_angle_alpha
	_pd_index_cell_angle_beta
	_pd_index_cell_angle_gamma
	21.7 M20 ITO12      12.112 5.278 4.486 90. 90. 90. 
	54.215 M1 CRYS934h  6.432  6.432 28.769 90. 90. 90.

Can we have formal definitions for the _pd_index_merit_method values M1
and M20? Are there other methods that should be defined? Is there other
information that should also be included in a list of 
possible cells, for example _pd_index_cell_appendix to describe a
comment about what is wrong or right about the cell.

00-2-11.4) _pd_peak_index_status (or _pd_index_peak_status - see
> discussion below)
> 
> Since it would involve an entry for every line (perhaps 50-100) of
> every trial cell (there could be thousands), I think that Brian's
> option of looping this as a (cells x peaks) matrix is unattractive
> and probably should not be attempted.
>
> My intention was that this status list (like the list of trial hkl
> indices) would be maintained only for the single, current front
> runner among the trial cells.
> 
> However, for consistency with the emerging section schema, I now
> think that the name should more logically become
> _pd_index_peak_status.  In other words, that all items that are
> associated specifically with indexing operations should be gathered
> in the_pd_index_ section.  That would make it easier for human
> readers to locate what is relevant to indexing, and also for
> automated CIF readers to include or exclude such material
> systematically.
> 
> Such indexing status flags would most naturally be placed in the
> loop that contains the trial indices for that cell - I have not yet
> thought through the best way to cater for the common situation where
> the calculated pattern yields multiple indexings for a single
> observed line.  Maybe such complications aren't worth bothering
> about, leaving the recorded information for that line confined to
> just the indices for the closest calculated line plus a "mult"
> index-status flag.

00-10-06.1) _pd_index section

So far it seems we need three groupings of information in _pd_index: 

(1) a loop for peaks with _pd_index_peak_Q, or something similar. 
	What else is needed in this loop? 
	Should it be allowed that this loop be combined with _pd_peak
		data names or always be separate?

(2) a loop for trial cells and FOM values
	What else is needed in this loop? 

(3) _pd_index_appendix


Anything else?

Brian
 
********************************************************************
Brian H. Toby, Ph.D.                    Leader, Crystallography Team
Brian.Toby@NIST.gov      NIST Center for Neutron Research, Stop 8562
voice: 301-975-4297     National Institute of Standards & Technology
FAX: 301-921-9847                        Gaithersburg, MD 20899-8562
                http://www.ncnr.nist.gov/xtal
********************************************************************

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