[Imgcif-l] CBF file templates
harry powell
harry at mrc-lmb.cam.ac.uk
Wed Sep 30 11:13:05 BST 2009
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 at iucr.org [mailto:imgcif-l-bounces at 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 at 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 at iucr.org
>>> [mailto:imgcif-l-bounces at 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 at iucr.org
>>> [mailto:imgcif-l-bounces at 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 at 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 at iucr.org
>>>>> http://scripts.iucr.org/mailman/listinfo/imgcif-l
>>>>>
>>>> _______________________________________________
>>>> imgcif-l mailing list
>>>> imgcif-l at 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 at 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 at 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 at 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 at 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 at 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
More information about the imgcif-l
mailing list