Discussion List Archives

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

re: 00-2-11 Proposed additions to the pdCIF dictionary

  • To: Multiple recipients of list <pddmg@iucr.org>
  • Subject: re: 00-2-11 Proposed additions to the pdCIF dictionary
  • From: "Brian H. Toby" <brian.toby@nist.gov>
  • Date: Sat, 12 Feb 2000 22:07:43 GMT
To members of the pdDMG & Robin Shirley,

In general, with respect to proposals 00-2-11.1 to 00-2-11.4, I agree
pdCIF needs to accommodate information generated for and during
autoindexing. I think the actual data names need some more thought, but
that can be postponed for now. The real question that we need to decide
is, if a new section should be added to pdCIF specifically for indexing,
or if it is better to add appropriate entries to the existing sections. 

00-2-11.1) _pd_proc_quadr_Q

   I am reluctant to agree to add this, since it is so easily generated
from d-space values. I assume that an indexing program would not require
_pd_proc_quadr_Q be present for the file to be used. This means one must
have software that can read generate a peak list from whichever is
present:  _pd_peak_2theta_centroid, _pd_peak_2theta_maximum, or
_pd_peak_d_spacing. If a program is going to read the peak list and
generate _pd_peak_quadr_Q, it could just as easily add
_pd_peak_d_spacing when it is not there already. I would like to hear a
good argument for why this would be more valuable than
_pd_peak_d_spacing.

00-2-11.2) _pd_index_appendix

   I think this is needed. The only question is what section of pdCIF is
should be placed: a new _pd_index section, or the _pd_refln_ section?
For the following discussion I have assumed a new section, but I am
ambivalent on this point.

00-2-11.3) _pd_proc_index_merit

   I think this is needed but this needs more thought. First, a formal
definition of the figure of merit (FOM) is needed. I am not sure, but I
believe that more than one FOM definition is commonly used. So it makes
sense to define a different data item for each FOM definition. Also, as
I see it, one would likely want to include a list of trial unit cells
and FOM values for each, so my thinking would be more like this
(apologies to Bob Snyder and Jan Visser):

	loop_
	  _pd_index_cellid
	  _pd_index_trial_a
	  _pd_index_trial_b
	  _pd_index_trial_c
	  _pd_index_trial_alpha
	  _pd_index_trial_beta
	  _pd_index_trial_gamma
	  _pd_index_FOM_Visser
	  _pd_index_FOM_Snyder
		cell1 3  4   6 90 90 90 101.2  75.
		cell2 12 12 12 90 90 90  20.   99.

00-2-11.4) _pd_peak_index_status

   I agree that one needs a way to flag peaks to be used or omitted in
an autoindexing attempt and _pd_peak_ is the place to do this. My
confusion is: should there be a matrix for indicating indexing status
rather than a vector?

	peak #    cell1  cell2 ...
	  1       uniq   mult
	  2       fail   uniq
	  ...
   
If so, there are [at least] two ways to do this. One is a separate block
for each trial cell. In that case, I would do something like this:

	data_trialcell1
	_pd_index_trial_a 3
	_pd_index_trial_b 4
	_pd_index_trial_c 5
	_pd_index_trial_alpha 90
	_pd_index_trial_beta  90
	_pd_index_trial_gamma 90
	_pd_index_FOM_Visser  101.2
	_pd_index_FOM_Snyder  75.

	# loop over peaks to show status
	loop_
	  _pd_index_peak_id
	  _pd_index_peak_status

	# loop over reflections to show indexing
	loop_ 
	  _refln_index_h
	  _refln_index_k
	  _refln_index_l
	  _pd_refln_peak_id	  

The other way would not require a separate block, but would get messy
with lots of cells
	loop_
	  _pd_index_cell_ref
	  _pd_index_peak_id
	  _pd_index_peak_status
	cell1 peak1 uniq
	cell2 peak1 mult
	cell1 peak2 fail
	cell2 peak2 uniq

00-2-11.5) _pd_calib_*_offset

   This makes sense, except I am scratching my head over
_pd_calib_phi_offset. Is not the zero of phi arbitrary?

00-2-11.6) tube take-off angle

I see three choices: 
   A) include a new item in pdCIF 
   B) record it as a "comment" in _diffrn_source_details
   C) bump this to the CoreDMG to define
	_diffrn_source_takeoff in the core dictionary

My preference is C, as I seem to recall that the takeoff angle is needed
for predicting the instrument response function.

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
********************************************************************

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