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

Re: area detector cif definitions

• To: Multiple recipients of list <imgcif-l@bnl.gov>
• Subject: Re: area detector cif definitions
• From: Andy Hammersley <hammersl@esrf.fr>
• Date: Wed, 6 Nov 1996 13:34:24 -0500 (EST)

Hello Everyone,

Here's some info and background to a proposal from David Brown
on CIF definitions for area detectors. I don't feel fully qualified
to give a direct answer so I prefer to open the discussion. Here I will try
to describe the problem and why I feel the views of others are needed
to find a good solution. 

Concerning CIF Definitions for Area Detectors
---------------------------------------------

In finalising DDL-2 I and other members of COMCIFS have been asked
to approve it. This I did, but pointed out a reservation regarding a
number of definitions for area detector related data names and
definitions. I proposed that it is recognised that the definitions
are suitable for human interpretation e.g. details of experimental
conditions to accompany a structure solution, but are not sufficiently
detailed to allow automatic processing of area detector data. David
and Syd Hall would still, however like to finalise the definitions
for a January issue of Acta Cryst. 

Here I'll explain how I see the problem.


Specification of Problem
------------------------

One of the major aims of "imageNCIF" is to store, in addition to the 
area detector data, essential information describing the experiment such
that the processing software can proceed automatically without further
user intervention. (Bob Sweet in particular emphasizes this point.)

Requirements
------------

The above aim has obvious implications e.g. we need to store known 
details of the experiment including precise diffraction geometry 
using well defined and non-ambiguous definitions. 

Obvious items include sample to detector distance, and diffractometer
angles. However, it needs to be considered that the diffractometer
may be slightly mis-aligned relative to the X-ray beam i.e. the sample
precesses in the beam rather than simply rotating. Thus it needs to
be considered whether to use the diffractometer axes (or virtual axes)
as the reference coordinate system and to define angles specifying the
angle of the X-ray (or other radiation) beam, or vice versa. Which is
the better system ? (I suppose other reference frames are also possible
but probably add unnecessary complication.) (Phil Evans made these 
points particularly clear to me.)

Similarly the detector may be nominally orthogonal to the direct beam, 
but in practice is often slightly mis-aligned. So three angles are needed to
describe this mis-alignment, but in addition the detector may be 
deliberately rotated to a set "2-theta" angle. In general another 3 angles
need to be defined (or could they be combined ?)

Whilst various different sets of angles/distances may contain equivalent
information, I feel that it is worth finding the parameterisation which
is most natural and simple for the most usual circumstances, whilst of
course allowing the flexibility to describe any geometry. (It should be
noted that different integration programs use different definitions 
for sample to detector distance, and for direct beam position.)

In addition to these geometrical definitions it is highly desirable
to preserve information about the type of detector and even the precise
model, and the experimental instrument which was used to collect the
data. This is because analysis software might know about particular
qualities of particular detector types and even particular instruments.
e.g. Point spread function, list of hot pixels, etc. Eventually, some of
this information could itself be defined in data-names, but still
precise detector information will remain important. (Zbyszek Otwinoski
in particular pointed out the danger of a general format lossing
important information concerning the detector characteristics.)

Here the main need is to define the precise data values defining the
type of detector, model, and the precise experimental instrument used.
e.g. Mar-Research IP Detector, Mar Image Plate Scanner, or Big MarResearch
Scanner, may all convey sufficient information for a human, but will
not necessarily be recognised as the same by a computer program parsing
a file. Probably a register of standard detector types and data
values, and experimental instruments and corresponding data values will
be necessary.

Solution ?
----------

Particularly the first part is beyond my experience and competence, so
I prefer to leave others to give their views. Jim Pflugrath has made 
a proposal for defining a coordinate system, but I find it complicated
and wonder whether a simpler definition could not be defined which is
more natural for standard geometries. 

Bob Sweet has been trying to organise a workshop on "imageNCIF" where
the coordinate system and geometrical definitions would be one of the
main topics to be discussed. However, I presume that he is still trying to
find funding for the workshop. 

I think a workshop would be the best way to bring together enough
specialists in this area, but I doubt that this would fit in with the
desire to publish in January.


Regards,


      Andy

Reply to: [list | sender only]

• Prev by Date: Re: File identifier (was Re: Seattle Discussions)
• Next by Date: Re: area detector cif definitions
• Prev by thread: Draft DDL 2.1 CIF binary file extension dictionary
• Next by thread: Re: area detector cif definitions
• Index(es):
  • Date
  • Thread