Discussion List Archives

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

Re: [Imgcif-l] CBF file templates

Hi Chris,

Here's my thoughts so far: we prepare a template on a per-run basis
(i.e. for the measurement of each sweep) from some kind of central
template, which will contain everything but the contents of e.g. the
current ADSC header. Then the detector control software populates what
it knows - therefore, if there are ? left in the header it's our fault
as the detector control software is only doing what it does already.

No code yet - been figuring out the CIF for the additional records we
want to store, and the mechanisms to put in place to make this happen. 

Working from the starting point of ? = replace me, moving forward should
be fine. Does the ADSC software allow for a template? If so, how should
we do this?

Thanks,

Graeme

Ps... "but I would suggest that if the DLS beamlines do a good job of
it" - that's the plan :o)

-----Original Message-----
From: imgcif-l-bounces@iucr.org [mailto:imgcif-l-bounces@iucr.org] On
Behalf Of Chris Nielsen
Sent: 30 September 2009 23:33
To: The Crystallographic Binary File and its imgCIF application to image
data; The Crystallographic Binary File and its imgCIF application to
image data
Subject: Re: [Imgcif-l] CBF file templates


      Hi All,
 
      I tend to agree that a complete filling-in of the nominal template
is probably not going happen in many places, at least to start, but I
would suggest that if the DLS beamlines do a good job of it and the
"extra" (beyond essential data processing header items) turn out to be
useful for this or that, more beam lines will do a more complete job.
I'd note that these items should be sort of "backward compatible" in the
sense that, to start with, if you only fill in a few "extra" items it
should not matter that a future header has more complete information.
It's hard to see the downside in this.
 
      Graeme:  What are your thoughts on the coding required to do this?
Have you made an attempt yet?
 
      Chris
 
 

________________________________

From: imgcif-l-bounces@iucr.org on behalf of Andy Howard
Sent: Wed 9/30/2009 8:13 AM
To: The Crystallographic Binary File and its imgCIF application to image
data
Subject: Re: [Imgcif-l] CBF file templates



Hi folks,
> 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?
> ...

I support templating, but compliance is likely to be an issue. When Jim
Pflugrath deliberately put in-your-face comments into the D*Trek
"comments" header slots that were designed to force beamlines to
customize their local implementations, seveal of the beamlines that used
D*Trek ignored those comments. So a lot of D*Trek-aquired data have
comments fields that contain language like "This is a meaningless header
that should be replaced by something with content".
  _____________________________________________________________
/ Andrew J.Howard, Associate Professor of Biology and Physics \
| CSRRI, Biological, Chemical, & Physical Sciences Department | College 
| of Science&Letters, Illinois Institute of Technology|
| 3101 South Dearborn Street, Chicago Illinois 60616 USA      |
| Co-director, IIT Masters in Health Physics program          |
| phone: 312-567-5881; fax: 312-567-3576; cell 773-368-5067   |
| e-mail: howard@iit.edu;  web: http://csrri.iit.edu/~howard/ |
  \____________________________________________________________/
_______________________________________________
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

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.

Useful links