[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [Imgcif-l] CBF file templates
- To: The Crystallographic Binary File and its imgCIF application to image data <imgcif-l@iucr.org>
- Subject: Re: [Imgcif-l] CBF file templates
- From: "Herbert J. Bernstein" <yaya@bernstein-plus-sons.com>
- Date: Wed, 30 Sep 2009 07:28:27 -0400 (EDT)
- In-Reply-To: <137E15CF-5748-41A5-9DCF-BA12A23E732D@mrc-lmb.cam.ac.uk>
- References: <4854F2500EA8C4478A508D2D92973E52047BE339@EXCHANGE25.fed.cclrc.ac.uk><20090929061322.N74653@epsilon.pair.com><4854F2500EA8C4478A508D2D92973E52047BE33D@EXCHANGE25.fed.cclrc.ac.uk><765CB1E0-804D-4874-A6BD-552CE9EDD0B0@mrc-lmb.cam.ac.uk><4854F2500EA8C4478A508D2D92973E5205F2CA8C@EXCHANGE25.fed.cclrc.ac.uk><3278C1D8-203F-420E-8762-E626361F93EB@mrc-lmb.cam.ac.uk><4854F2500EA8C4478A508D2D92973E52047BE33F@EXCHANGE25.fed.cclrc.ac.uk><137E15CF-5748-41A5-9DCF-BA12A23E732D@mrc-lmb.cam.ac.uk>
The unquoted question mark and period are reserved for "null" (i.e. unspecicifed) values in a CIF, with the convention having been adopted that the question mark get used when there is a suggestion to fill it in later, while the period get used when there is no need to fill it in later. ===================================================== 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 ===================================================== On Wed, 30 Sep 2009, harry powell wrote: > Hi > > Yes, this would be in the template (a ? i a field in a finished CIF > says something unspecfied about the user or the experiment); for > example, have a look at the CIFs that SHELX generates - quite a few ? > in things that should be edited by the submitter... > > On 30 Sep 2009, at 10:50, Winter, Graeme (DLSLtd,RAL,DIA) wrote: > >> Indeed. >> >> The *isolated* in here is key: if the user has named their >> experiment ? >> I expect that this says more about them than the sample under >> study :o) >> >> More seriously though, I guess that any title would have some >> furniture >> like quotes ("?" not ?) around it. >> >> Finally, this is not in the final CIF file, this is in the template, >> which may or may not be a CIF file. >> >> No worries. >> >> Graeme >> >> >> >> -----Original Message----- >> From: imgcif-l-bounces@iucr.org [mailto:imgcif-l-bounces@iucr.org] On >> Behalf Of harry powell >> Sent: 30 September 2009 10:47 >> To: The Crystallographic Binary File and its imgCIF application to >> image >> data >> Subject: Re: [Imgcif-l] CBF file templates >> >> Hi >> >> single, isolated "?" is the CIF standard - don't start re-inventing >> the >> wheel! >> >> See - http://www.iucr.org/__data/iucr/cif/standard/cifstd11.html - >>> "Note that the missing items in this example are flagged with a `?'. >>> Programs such as CIFIO can only output the data items present in >>> their >> >>> internal files and the `?' flag represents a simple mechanism for >>> identifying missing items. >>> >>> The use of a `?' as a missing data flag is important for two >>> reasons: it signals the inaccessibility of a data item to the >>> generating software, and it satisfies the STAR File requirement that >>> each data name must be matched with a data value. The use of a `?' >>> enables data items from other sources to be added later either >>> manually or by software. " >>> >> >> >> i.e. if there's only a single "?" there, you know there's something >> missing. If there's anything else, you don't know that, and you also >> break all the CIF parsers that expect a single "?" to represent >> missing >> information. >> >> So "I04?" would not represent a field with a missing item, it would >> be a >> valid string saying something along the lines that you thought you >> were >> collecting on I04, but got confused while walking around the ring and >> ended up in the wrong hutch (but hopefully, the beamline software >> would >> put the right value in anyway...). >> >> You may have a better way, but don't call the result CIF (or CBF). >> CIF has its limitations, as we all know. >> >> On 30 Sep 2009, at 10:16, Ashton, Alun (DLSLtd,RAL,DIA) wrote: >> >>> >>> I don't like a single ? It could be a part of a title for a beamline >>> session, would that confuse it? While multiple ? would be unlikely, >>> unless they were really unsure what they were doing :). >>> >>> Alun >>> ___________________________________________________________ >>> Alun Ashton, alun.ashton@diamond.ac.uk Tel: +44 1235 778404 >>> Data Acquisition Group, http://www.diamond.ac.uk/ >>> Diamond Light Source, Chilton, Didcot, Oxon, OX11 0DE, U.K. >>> >>> >>> >>>> -----Original Message----- >>>> From: imgcif-l-bounces@iucr.org >>>> [mailto:imgcif-l-bounces@iucr.org] On Behalf Of harry powell >>>> Sent: 30 September 2009 10:09 >>>> To: The Crystallographic Binary File and its imgCIF application to >>>> image data >>>> Subject: Re: [Imgcif-l] CBF file templates >>>> >>>> Hi >>>> >>>> a single "?" in an empty field is allowed under CIF rules, as I >>>> understand. ISTR it from the days when I deposited CIFs for small >>>> molecule structures, and CBF is supposed to be conformant to the >>>> normal CIF rules (apart from the binary section, about which people >>>> may argue). >>>> >>>> d*Trek has to be the model of being comprehensive apropos its use of >>>> the header. >>>> >>>> I don't think HKL is an issue, to be honest - I think I'm right in >>>> saying that Wladek has said that "CBF is just another image >>>> format" - >> >>>> they will use what they see as useful and/or necessary. >>>> >>>> On 30 Sep 2009, at 09:45, Winter, Graeme (DLSLtd,RAL,DIA) wrote: >>>> >>>>> Dear Herbert & list, >>>>> >>>>> One template per beamline is probably, in reality, the way it would >>>>> work. We would just make sure that they are all the same. >>>> Adding ???? >>>>> For the detector software to fill in sounds like good >>>> sense. Is this >>>>> kind of thing supported? An alternative is to have some >>>> boiler plate >>>>> which needs to be copied in, then work on getting the >>>> format for the >>>>> detector produced bit the same. These are essentially the same >>>>> problem. >>>>> >>>>> What's the consensus on the best approach? Does everyone >>>> support the >>>>> use of templates? >>>>> >>>>> At the other end, I assume that the contents of the current >>>> ADSC CBF >>>>> header represent the minimum which should be in place for e.g. >>>>> Mosflm to >>>>> make sense of the image, and anything we add will be ignored. XDS >>>>> ignores the header anyway. D*TREK, HKL - any comments? >>>>> >>>>> Thanks, >>>>> >>>>> Graeme >>>>> >>>>> -----Original Message----- >>>>> From: imgcif-l-bounces@iucr.org >>>> [mailto:imgcif-l-bounces@iucr.org] On >>>>> Behalf Of Herbert J. Bernstein >>>>> Sent: 29 September 2009 11:34 >>>>> To: The Crystallographic Binary File and its imgCIF application to >>>>> image data >>>>> Subject: Re: [Imgcif-l] CBF file templates >>>>> >>>>> Dear Colleagues, >>>>> >>>>> Right now the utilities in the library use templates that are >>>>> intended to be for just one beamline per template, so they >>>> are set up >>>>> with tags with zero values for the items that they know will be >>>>> populated from the detector and known specific values for >>>> the beamline >>>>> for items that come from the beamline geometry. If we are going to >>>>> have master templates, there would seem to be more cases: >>>>> >>>>> 1. Items that will be supplied by every detector. >>>>> 2. Items that will be supplied by some detectors but not >>>>> others >>>>> 3. Items that will be supplied by every beamline >>>>> 4. Items that will be supplied by some beamlines but not >>>>> others >>>>> >>>>> I would suggest using "?", rather than "0" values for all >>>> items that >>>>> are know known for sure in writing the master template. Then in >>>>> specializing for a given beamline (e.g. in setting up the >>>> axes), all >>>>> of the "?" for 3, hopefully a lot for 4 could be removed >>>> and replaced >>>>> with known values. >>>>> When the detector data is merged with the beam-line >>>> specific tempate, >>>>> hopefully all "?" for 1 and a lot for 2 would be replaced with data >>>>> from the detector. The "?" that are left would then be >>>> clear markers >>>>> of what was supplied neither by the beamline nor by the >>>> detector. I >>>>> am working on the code to allow comments to be preserved and copied >>>>> along with data, so we could carry remarks such as: >>>>> >>>>> # This item should be supplied by every beamline >>>>> # This item should be supplied on beamlines ..., ... ... >>>>> # This item should be supplied by every detector >>>>> # This item should be supplied by detectors ..., ... ... >>>>> >>>>> or is people, prefer, we can add CIF tags with the same info >>>>> >>>>> Regards, >>>>> Herbert >>>>> ===================================================== >>>>> 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 >>>>> ===================================================== >>>>> >>>>> On Tue, 29 Sep 2009, Winter, Graeme (DLSLtd,RAL,DIA) wrote: >>>>> >>>>>> Dear CBF'ers, >>>>>> >>>>>> I'm working on trying to establish a "Diamond standard" >>>> template for >>>>>> our CBF files across a number of detectors, and I was >>>> wondering how >>>>>> this is best specified. What would be ideal would be to set up a >>>>>> template which contains those things that the beamline "knows" but >>>>>> the >>>>> >>>>>> detector does not, then have the detector software >>>> populate the other >>>>> fields (e.g. >>>>>> exposure time, integration time, maximum trusted pixel, >>>> oscillation >>>>>> start / end) to give a full description. >>>>>> >>>>>> Now, has anyone done something like this? If so, how do >>>> you specify >>>>>> the fields which are to be replaced? If not, does anyone have an >>>>>> opinion on how this should be done? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Graeme >>>>>> >>>>>> Graeme Winter >>>>>> Software and MX Support Scientist >>>>>> Diamond Light Source >>>>>> >>>>>> +44 1235 778091 (work) >>>>>> +44 7786 662784 (work mobile) >>>>>> >>>>>> >>>>>> >>>>>> This e-mail and any attachments may contain confidential, >>>> copyright >>>>>> and or privileged material, and are for the use of the intended >>>>>> addressee only. If you are not the intended addressee or an >>>>>> authorised >>>>> >>>>>> recipient of the addressee please notify us of receipt by >>>> returning >>>>>> the e-mail and do not use, copy, retain, distribute or >>>> disclose the >>>>>> information in or attached to the e-mail. >>>>>> >>>>>> Any opinions expressed within this e-mail are those of the >>>> individual >>>>>> and not necessarily of Diamond Light Source Ltd. >>>>>> >>>>>> Diamond Light Source Ltd. cannot guarantee that this e-mail or any >>>>>> attachments are free from viruses and we cannot accept >>>> liability for >>>>>> any damage which you may sustain as a result of software viruses >>>>>> which >>>>> >>>>>> may be transmitted in or with the message. >>>>>> >>>>>> Diamond Light Source Limited (company no. 4375679). Registered in >>>>>> England and Wales with its registered office at Diamond House, >>>>>> Harwell >>>>> >>>>>> Science and Innovation Campus, Didcot, Oxfordshire, OX11 >>>> 0DE, United >>>>>> Kingdom >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> imgcif-l mailing list >>>>>> imgcif-l@iucr.org >>>>>> http://scripts.iucr.org/mailman/listinfo/imgcif-l >>>>>> >>>>> _______________________________________________ >>>>> imgcif-l mailing list >>>>> imgcif-l@iucr.org >>>>> http://scripts.iucr.org/mailman/listinfo/imgcif-l >>>>> This e-mail and any attachments may contain confidential, copyright >>>>> and or privileged material, and are for the use of the intended >>>>> addressee only. If you are not the intended addressee or an >>>> authorised >>>>> recipient of the addressee please notify us of receipt by returning >>>>> the e-mail and do not use, copy, retain, distribute or disclose the >>>>> information in or attached to the e-mail. >>>>> Any opinions expressed within this e-mail are those of the >>>> individual >>>>> and not necessarily of Diamond Light Source Ltd. >>>>> Diamond Light Source Ltd. cannot guarantee that this e-mail or any >>>>> attachments are free from viruses and we cannot accept >>>> liability for >>>>> any damage which you may sustain as a result of software >>>> viruses which >>>>> may be transmitted in or with the message. >>>>> Diamond Light Source Limited (company no. 4375679). Registered in >>>>> England and Wales with its registered office at Diamond >>>> House, Harwell >>>>> Science and Innovation Campus, Didcot, Oxfordshire, OX11 >>>> 0DE, United >>>>> Kingdom >>>>> >>>>> _______________________________________________ >>>>> imgcif-l mailing list >>>>> imgcif-l@iucr.org >>>>> http://scripts.iucr.org/mailman/listinfo/imgcif-l >>>> >>>> Harry >>>> -- >>>> Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, >>>> Hills Road, Cambridge, CB2 0QH >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> imgcif-l mailing list >>>> imgcif-l@iucr.org >>>> http://scripts.iucr.org/mailman/listinfo/imgcif-l >>>> >>> This e-mail and any attachments may contain confidential, copyright >>> and or privileged material, and are for the use of the intended >>> addressee only. If you are not the intended addressee or an >>> authorised >> >>> recipient of the addressee please notify us of receipt by returning >>> the e-mail and do not use, copy, retain, distribute or disclose the >>> information in or attached to the e-mail. >>> Any opinions expressed within this e-mail are those of the individual >>> and not necessarily of Diamond Light Source Ltd. >>> Diamond Light Source Ltd. cannot guarantee that this e-mail or any >>> attachments are free from viruses and we cannot accept liability for >>> any damage which you may sustain as a result of software viruses >>> which >> >>> may be transmitted in or with the message. >>> Diamond Light Source Limited (company no. 4375679). Registered in >>> England and Wales with its registered office at Diamond House, >>> Harwell >> >>> Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United >>> Kingdom >>> >>> _______________________________________________ >>> imgcif-l mailing list >>> imgcif-l@iucr.org >>> http://scripts.iucr.org/mailman/listinfo/imgcif-l >> >> Harry >> -- >> Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, >> Hills >> Road, Cambridge, CB2 0QH >> >> >> >> >> _______________________________________________ >> imgcif-l mailing list >> imgcif-l@iucr.org >> http://scripts.iucr.org/mailman/listinfo/imgcif-l >> This e-mail and any attachments may contain confidential, copyright >> and or privileged material, and are for the use of the intended >> addressee only. If you are not the intended addressee or an >> authorised recipient of the addressee please notify us of receipt >> by returning the e-mail and do not use, copy, retain, distribute or >> disclose the information in or attached to the e-mail. >> Any opinions expressed within this e-mail are those of the >> individual and not necessarily of Diamond Light Source Ltd. >> Diamond Light Source Ltd. cannot guarantee that this e-mail or any >> attachments are free from viruses and we cannot accept liability >> for any damage which you may sustain as a result of software >> viruses which may be transmitted in or with the message. >> Diamond Light Source Limited (company no. 4375679). Registered in >> England and Wales with its registered office at Diamond House, >> Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 >> 0DE, United Kingdom >> >> _______________________________________________ >> imgcif-l mailing list >> imgcif-l@iucr.org >> http://scripts.iucr.org/mailman/listinfo/imgcif-l > > Harry > -- > Dr Harry Powell, MRC Laboratory of Molecular Biology, MRC Centre, Hills > Road, Cambridge, CB2 0QH > > > > > _______________________________________________ > imgcif-l mailing list > imgcif-l@iucr.org > http://scripts.iucr.org/mailman/listinfo/imgcif-l > _______________________________________________ imgcif-l mailing list imgcif-l@iucr.org http://scripts.iucr.org/mailman/listinfo/imgcif-l
Reply to: [list | sender only]
- References:
- [Imgcif-l] CBF file templates (Winter, Graeme (DLSLtd,RAL,DIA))
- Re: [Imgcif-l] CBF file templates (Herbert J. Bernstein)
- Re: [Imgcif-l] CBF file templates (Winter, Graeme (DLSLtd,RAL,DIA))
- Re: [Imgcif-l] CBF file templates (harry powell)
- Re: [Imgcif-l] CBF file templates (Ashton, Alun (DLSLtd,RAL,DIA))
- Re: [Imgcif-l] CBF file templates (harry powell)
- Re: [Imgcif-l] CBF file templates (Winter, Graeme (DLSLtd,RAL,DIA))
- Re: [Imgcif-l] CBF file templates (harry powell)
- Prev by Date: Re: [Imgcif-l] CBF file templates
- Next by Date: Re: [Imgcif-l] CBF file templates
- Prev by thread: Re: [Imgcif-l] CBF file templates
- Next by thread: Re: [Imgcif-l] CBF file templates
- Index(es):