[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [Imgcif-l] imgCIF Standard Axis definition
- To: The Crystallographic Binary File and its imgCIF application to image data <imgcif-l@iucr.org>
- Subject: Re: [Imgcif-l] imgCIF Standard Axis definition
- From: "Herbert J. Bernstein" <yaya@bernstein-plus-sons.com>
- Date: Fri, 4 May 2007 17:08:27 -0400
- In-Reply-To: <463B310D.4060306@esrf.fr>
- References: <3FACFB8AB0CA1B41A4B83670D0DEC1DE93FEF1@exchange08.fed.cclrc.ac.uk><463B310D.4060306@esrf.fr>
Dear Colleagues, We have three intermixed threads in this discussion: The standard axis definition The handling of multiple grains in SAS Keeping the raw data imgCIF file clean and uncluttered I have had an off-list request to keep all three threads together, since this is an interesting discussion, so here goes: On the standard axis defintion, I seem to hear no objection to incorporating Jon's suggestion on using an appropriate goniometer axis definition, if available, to define an origin. Are there any strong feelings about David's comments on the currently proposed fallbacks to (gravity or north) deal with the cases in which there is no sample positioner with axes sufficiently distinct from the beam axis and there is no appropriate axis direction suggested by detector axes? On the handling of multiple grains, Jon has suggested "adding a pointer to the category '_exptl_crystal_id' which might also be called '_diffrn.crystal_id' in mmCIF". The category definition of exptl_crystal is: "Data items in the EXPTL_CRYSTAL category record the results of experimental measurements on the crystal or crystals used, such as shape, size or density." If a domain is a crystal, then what Jon proposes would seem to be a legitimate use of EXPTL_CRYSTAL. We don't have to litter other categories with .crystal_id tags if we make the tag "implicit". I'll say more about that approach in talking about clutter below. A related question is whether we need two levels of identification, so we can have multiple rocks as well as multiple crystals within each rock. If there is such a need, then we should add an EXPTL_SAMPLE category as well. mmCIF basically assumes everything depends in there being a crystal. These days that is clearly too narrow a view, but in the case of a UB matrix, can we have one without a crystal? On the question of cluttering raw data imgCIFs, I like the approach the Kim Henrick originally suggested, data harvesting: each program or subsystem collects whatever data is appropriate to what it does and the values it provides are harvested to populate the overall record of the data collection, the data processing, etc. With that in mind, it would seem sensible for experimentalists to produce what I like to call "miniCBFs", imgCIF files that have the actual data and just as much header information as is known and needed at that stage of the experiment. Later in the life of the experiment other mmCIF, imgCIF, sasCIF data would be added as needed to the original CBF or multiple CIFs would be collected for a later merge. If we are careful, by the end of the entire experiment the composite CIF or collection of CIFs will be a very useful electronic notebook of the experiment. The implications for software writers are: 1. When reading a CIF, skip the tags that you don't need for the processing you do. 2. When writing a CIF, put whatever you think should be keep for posterity into the output CIF as parseable CIF data, not as comments. 3. Don't overwrite or delete earlier stage CIFs unless you have carried all tags and values over to a CIF that will be kept. In order to make it easier to write miniCBF's I propose to change many of the tags that are intended to disambiguate multiple diffraction experiments to be implicit, so that the default assumption will be that a CBF contains the data from one diffraction experiment and we will not have to repeat a dummy diffrn_id of DS1 over and over again. In order to satisfy programs that need fully populated CIFs I am working on a program convert_minicbf to fill in the missing items from a template. Regards, -- Herbert I've pruned the tail of replies -- it was getting a bit long. -- ===================================================== Herbert J. Bernstein, Professor of Computer Science Dowling College, Kramer Science Center, KSC 121 Idle Hour Blvd, Oakdale, NY, 11769 +1-631-244-3035 yaya@dowling.edu ===================================================== _______________________________________________ imgcif-l mailing list imgcif-l@iucr.org http://scripts.iucr.org/mailman/listinfo/imgcif-l
Reply to: [list | sender only]
- References:
- Re: [Imgcif-l] imgCIF Standard Axis definition (Winter, G (Graeme))
- Re: [Imgcif-l] imgCIF Standard Axis definition (Jon Wright)
- Prev by Date: Re: [Imgcif-l] imgCIF Standard Axis definition
- Next by Date: [Imgcif-l] CBFlib_0.7.7 update to subrelease 0.7.7.4
- Prev by thread: Re: [Imgcif-l] imgCIF Standard Axis definition
- Next by thread: [Imgcif-l] imgCIF workshop (new series) at BSR 2007
- Index(es):