[Date Prev][Date Next][Date Index]
(48) Extended Core: interblock links; DIFFRN categories
- To: COMCIFS@iucr.ac.uk
- 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
- Prev by Date: (47) Extended Core: last round before Seattle
- Next by Date: (49) Remaining issues: block id, disorder, diffrn
- Index(es):