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: vondreele@lanl.gov (Bob Von Dreele)
  • Date: Mon, 14 Feb 2000 16:58:03 GMT
Dear Brian (& others),
Comments:
At 10:07 PM 2/12/00 +0000, you wrote:
>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.
I think that _pd_peak_d_spacing should be sufficient to describe the
location of the reflections used for indexing. My own experience with this
(indexing protein patterns) shows that the other two (2theta_centroid &
2theta_maximum) are not particularly useful as they don't reflect the true
position of the reflection. The asymmetry due to axial divergence shifts
both of these 2theta measures away from what Bragg's Law would predict.
>
>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.
I think this is right also (a new section).
>
>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):
I suspect that the indexing program used to produce the cell & FOM is also
needed. They all seem to be a little different in their behavior &
success/failure for a given problem.
>
>	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?
I guess my problem with this is in what kind of "powder" experiment is
"omega", "chi" and "phi" an issue. The only thing I can think of off the
top of my head is texture measurements. The other problem with these is the
definition of their respective "handedness" and reference coordinate system
(i.e. what is omega a rotation about?). These are single crystal
diffraction issues too - are they in the _diffrn_ core dictionary already?
>
>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.
I agree that C is the correct choice. After all the tube take-off angle is
something that is setup by the experimenter for single crystal experiments
also.
>
>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)]