Discussion List Archives

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

(48) Extended Core: interblock links; DIFFRN categories

  • To: [email protected]
  • Subject: (48) Extended Core: interblock links; DIFFRN categories
  • From: bm
  • Date: Fri, 23 Aug 1996 14:36:27 +0100
Dear Colleagues

It was very good to meet you all (almost) again in Seattle last week. Thanks
to Syd for organising a most successful CIF workshop.

David is pressing me to wrap up the current Core revision in a matter of
a couple of weeks, and I think that's feasible, so long as "a couple of
weeks" is understood as running from the beginning of September, as I shall
be away for all of next week. There have been a couple of postings which I
shall send out now for your consideration. Please give due weight to the
timescale for closure on these discussions.

D45.7  _audit_link_block_code
-----------------------------
Brian Toby writes:
B> I am bothered by the implicit grouping of blocks into logical unit (a
B> multi-block file) without having any formal structures in STAR (or at least
B> CIF) for this purpose.  Use of the data block name (xxxx as in data_xxxx) as
B> an identifier for use in interblock links is a particularly poor approach.
B> Block names are arbitrary and for that matter must be pretty short. I do not
B> even recall a rule stating the obvious... that the "datablock name must be
B> unique within any file."

See Table 1 (p. 656) of the original Hall, Allen & Brown paper, and the
second paragraph of p. 657; or the last line on p. 1 of "A Guide to CIF for
Authors".

B> There is a need for grouping of blocks, as Brian's example shows. Brian M.'s
B> discussion is correct as far as it goes, though I note that we now have
B> _pd_block_id rather than _pd_dataset_id. Consider an even more troubling
B> example: a case where one makes measurements on a one single crystal at
B> several wavelengths to use anomolous dispersion to establish site occupancies
B> for ions sharing sites. The only model that is produced will be fit to all
B> of the datasets. Thus, we have:
B> 
B> 	data_paper
B> 	# final coordinates and discussion
B> 	data_wave1
B> 	# hkl, Fobs, Fcalc;  r-factors for wave 1
B> 	data_wave2
B> 	...
B> 
B> If the blocks are ever separated into different files... how can
B> humpty-dumpty ever be reassembled?  Yet, the contents of data_paper
B> do not stand on their own.
B> 
B> For the _pd_ dictionary, without the ability to link blocks into a
B> higher-level unit, I worked with the idea that blocks must be assigned
B> unique names so that links can survive transmission. I am not completely
B> happy with my mechanism for naming, but I do not have any better ideas.
B> 
B> If we intend files to be considered a logical grouping, we should define that
B> in some manner. To date we have assumed no logical linkage between CIF's in a
B> single computer file. Further, we have long allowed data_names to be changed
B> (I recall hearing this first in Tarrytown). Thus, in my opinion, interblock
B> links defined by the _audit_ fields in D45.7 can be considered "write-only
B> memory" as soon as the CIF leaves the lab where it was created.
B> 
B> Extending the _pd_ approach we could use:
B> 
B>  data_aaaa_text
B>   loop_ _audit_link_block_code _audit_link_block_description
B>     .             'Text of paper comparing powder and single-crystal studies'
B>     unique_aaaa_pow      'Powder data for phase 1 of brianite'
B>     unique_aaaa_xtal     'Single-crystal data for phase 1 of brianite'
B>   _block_id unique_aaaa_text
B> 
B>  data_aaaa_pow
B>     _block_id unique_aaaa_pow
B>     _pd_dataset_id   Bri1|NSLS|A.N.Other|96-02-29|08:45
B>    loop_ _audit_link_block_code _audit_link_block_description
B>     unique_aaaa_text
B>               'Text of paper comparing powder and single-crystal studies'
B>     .             'Powder data for phase 1 of brianite'
B>     unique_aaaa_xtal     'Single-crystal data for phase 1 of brianite'
B> 
B>  data_aaaa_xtal
B>   loop_ _audit_link_block_code _audit_link_block_description
B>     unique_aaaa_text
B>             'Text of paper comparing powder and single-crystal studies'
B>     unique_aaaa_pow      'Powder data for phase 1 of brianite'
B>     .             'Single-crystal data for phase 1 of brianite'
B>   _block_id unique_aaaa_xtal
B> 
B> where unique_ is a prefix that insures uniqueness.
B> 
B> Resolving this problem of interblock links is a real not hypothetical problem
B> -- When I get back from the IUCr meeting, I plan to do a combined refinement
B> of a neutron powder and a x-ray single crystal dataset to see if we can
B> establish vacancy levels for a mixed-oxide system. If we are to solve this
B> problem, it must be done in the core dictionary, not by an
B> application-specific approach or in a discipline-specific dictionary.

B> I propose we punt on this item until we have a better idea.

I agree that the resolution of the problem is a real issue. I am willing to
go along with Brian T.'s example, and transfer the value of
'_audit_link_block_code' to a '_block_id' rather than a datablock name. What
do other people think about having a mechanism to assign "unique_" prefixes
to the _block_id values to ensure (or at least assist) global uniqueness?
(Remember, we have a similar scheme for assign prefixes to data names for
the use of developers wishing to devise private data names.)


D48.1 Proposal for core dictionary definitions in the _diffrn section
---------------------------------------------------------------------
Following the discussions begun in D44.10 and 11, David has worked at
rationalising the requirements for _diffrn_ items, and presents the
following proposal. The glance I have so far afforded it suggests that it is
a better basis for handling these categories in the future. Comments on this
scheme (particularly on its relationship with area detectors) are most
welcome.

D>      The current categories in this section are:
D> 
D>      diffrn
D>      diffrn_attenuator
D>      diffrn_measurement
D>      diffrn_orientation_matrix
D>      diffrn_orientation_refln
D>      diffrn_radiation
D>      diffrn_refln
D>      diffrn_reflns
D>      diffrn_scale_group
D>      diffrn_standard_refln
D>      diffrn_standards
D> 
D> Most of these present no difficulties, but I propose a reworking
D> of the two categories
D> 
D>      diffrn_radiation
D>      diffrn_measurement
D> 
D> and the addition of two new categories
D> 
D>      diffrn_source
D>      diffrn_detector
D> 
D>      The rationale is to include all descriptions of the radiation
D> source in the _source category, details of the radiation, its
D> collimation and monochromatisation in the _radiation category,
D> details of the specimen and goniometer in the _measurement
D> category and details of the radiation detector in the _detector
D> category.
D> 
D>      These changes involve the renaming of some of the proposed
D> items and moving them to one of the new categories.  In a few
D> cases I have moved some existing items to new categories and
D> proposed new names.  The new names are not essential as long as
D> we are content to live with names that suggest a wrong category. 
D> This problem would disappear if we ever move to DDL2.
D> 
D>             PROPOSED CHANGES IN THE _DIFFRN_ section
D> 
D> =========================================================
D> diffrn_source_[]    ***NEW CATEGORY***
D>      Data items in the _diffrn_source category describe the
D> nature of the radiation source used in the experiment.  
D> ---------------------------------------------------------
D> PROPOSED ITEMS (transferred from other sections) 
D> _diffrn_source_type
D>      The type of source used, e.g. sealed xray tube
D>                                    nuclear reactor
D>                                    spallation source
D>                                    electron microscope
D>                                    rotating anode xray tube
D>                                    synchrotron
D>      (replaces the proposed _diffrn_radiation_source_type)
D> 
D> _diffrn_source_details
D>      Description of the make or name of the souce used, e.g.
D>                                    NSLS beamline X8C
D>                                    Rigaku RU200
D>      (replaces the proposed _diffrn_radiation_source_details and
D>      *_specific)
D> 
D> _diffrn_source_target
D>      The target in the source used to generate the radiation,
D>                                    e.g. Cu,  Mo
D>      It could also, presumably, be used for spallation sources.
D>      (replaces the proposed _diffrn_radiation_xray_target)
D> 
D> _diffrn_source_size
D>      The dimensions of the source as viewed from the sample.
D>      (replaces the proposed _diffr_radiation_source_target but
D>      notice that the definition of the latter is vague and might
D>      be taken as synonymous with _diffrn_radiation_xray_target
D>      were it not for the examples given.  I have redefined this
D>      to correspond more closely with the examples)
D> 
D> _diffrn_source_power
D>      The power at which the source was operated in kW.  This
D>      could be used for xray tubes, reactors, synchrotrons, spallation
D>      sources, etc.
D>      (replaces the proposed _diffrn_radiation_source_power and is
D>      changed from 'char' to 'numb')
D> 
D> NEW ITEMS (can be added at our leisure)
D> _diffrn_source_voltage
D> _diffrn_source_current
D> 
D> =========================================================
D> _diffrn_radiation_[]
D>      Items in this category describe the radiation used, its
D> collimation and monochromatisation before the sample.  (Post-
D> sample treatment of the beam is given in the detector category.) 
D> Many items are already defined in this category and most of
D> these do not need changing.
D> ---------------------------------------------------------
D> REMOVAL of existing data items to other categories
D> 
D> _diffrn_radiation_detector_* items moved to _diffrn_detector
D>      category (q.v.)
D> 
D> _diffrn_radiation_source moved to _diffrn_source category and 
D>      replaced by _diffrn_source_details unless it is needed in
D>      loops with *_wavelength in which case it remains here but
D>      contains essentially the same information as
D>      _diffrn_source_details
D> 
D> NEW ITEMS (already proposed)
D> _diffrn_radiation_collimation
D> _diffrn_radiation_probe
D> _diffrn_radiation_xray_symbol
D> 
D> NEW ITEMS (can be added at our leisure)
D> _diffrn_radiation_flux
D>      Number of particles per mm^2^ per s ('numb'  units =
D> mm^-2^.s^-1^)
D> 
D> =========================================================
D> _diffrn_measurement_[]
D>      Items in this category refer to the mounting of the sample
D> and to the goniometer on which it is mounted.  
D>      Note that most of the items currently included in the
D> _diffrn_[] category could (or should) be included in this
D> category, particularly the proposed _diffrn_crystal_support which
D> should in any case be _diffrn_SPECIMEN_support since not all
D> specimens will be crystals.
D> ---------------------------------------------------------
D> EXISTING ITEMS (no changes needed)
D> _diffrn_measurment_device
D> _diffrn_measurment_method
D> 
D> NEW ITEMS (already proposed)
D> _diffrn_measurement_details
D> _diffrn_measurement_device_details
D>      This should be a combination of the proposed
D>      *_device_details and *_device_specific
D> _diffrn_measurement_device_type
D> _diffrn_measurement_specimen_support 
D>      (replaces proosed _diffrn_crystal_support)
D> Should 'device' be replaced by 'goniometer' in these names?
D> 
D> =========================================================
D> _diffrn_detector_[]   ***NEW***
D>      Items in the _diffrn_detector_category describe the detector
D> used to measure the scattered radiation, including any analyser
D> and post-sample collimation.
D> ---------------------------------------------------------
D> EXISTING ITEMS (transferred from other categories)
D> _diffrn_detector_dtime 
D>      (replaces existing _diffrn_radiation_detector_dtime)
D> 
D> PROPOSED ITEMS (transferred from other categories)
D> _diffrn_detector_type
D>      Type of detector used, e.g.   photographic film
D>                                    scintillation counter
D>                                    CCD plate
D>                                    BF~3~ counter
D>      (replaces both proposed _diffrn_radiation_detector_type and
D>      the identically defined _diffrn_measurement_device_type) 
D>      This is a great example of how confusing our names have
D>      become, one group wanting to put this in the _radiation
D>      category and another in the _measurement category, one using
D>      'device' the other 'detector'.  Note that the word 'device'
D>      has been used synonymously with 'goniometer' in our existing
D>      definitions.
D> 
D> _diffrn_detector_details
D>      Manufacturer and model number of detector
D>      (replaces proposed _diffrn_radiation_detector_details and
D>      *_specific as well as the existing 
D>      _diffrn_radiation_detector. The latter could be left in the
D>      the _diffrn_radiation category, duplicating
D>      _diffrn_detector_details, if it is considered necessary to
D>      include it in a list with *_wavelength_id.)
D> 
D> NEW ITEMS (can be added at our leisure)
D> _diffrn_detector_analyser
D> _diffrn_detector_distance
D> _diffrn_detector_slit


------
Next time I'll try to get round to the promised tying off of loose ends.

Best wishes
Brian