Discussion List Archives

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Science Council (admitted 1947). Member of CODATA, the ISC Committee on Data. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

International Science Council Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.