[Imgcif-l] CBF file templates

Wed Sep 30 10:09:12 BST 2009

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