Discussion List Archives

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

Re: [Imgcif-l] Problems with mar images at cbf wiki

  • To: Justin Anderson <justin@rayonix.com>
  • Subject: Re: [Imgcif-l] Problems with mar images at cbf wiki
  • From: "Herbert J. Bernstein" <yaya@bernstein-plus-sons.com>
  • Date: Thu, 14 Aug 2008 17:32:13 -0400 (EDT)
  • Cc: imgcif-l@iucr.org, ana@slac.stanford.edu
  • In-Reply-To: <cc1cde5c0808141359n5ba63325rd0314adf70c34d29@mail.gmail.com>
  • References: <48925571.4090409@lbl.gov> <20080801193023.N30609@epsilon.pair.com><4893B13F.5010109@lbl.gov><cc1cde5c0808141359n5ba63325rd0314adf70c34d29@mail.gmail.com>
That critical listing of the essential agreed minimal set of tags is what 
we started discussing at BNL in May.  We should try to make progress on 
that set of tags in Osaka, and get it posted on the wiki.

The cbf_construct_detector function is used a lot, and mainly depends in a 
completely specified set of axes.  This is very beam-line specific.

   Just reading the first few tags used from the top of the code,
it uses:

   _diffrn.id
   _diffrn_detector.diffrn_id
   _diffrn_detector.id
   _diffrn_detector_element.detector_id
   _diffrn_detector_element.id
   _diffrn_data_frame.detector_element_id
   _diffrn_data_frame.array_id
   _array_structure_list.array_id
   _array_structure_list.precedence
   _array_structure_list.axis_set_id
   _array_structure_list_axis.axis_set_id
   _array_structure_list_axis.axis_id
   _array_structure_list_axis.displacement
   _array_structure_list_axis.displacement_increment

   ... etc.

It comes down to putting the engineering drawings of the detector relative 
to the sample and the beamline into the imgCIF in sufficient detail so 
that you can algorithmically determine to position of each pixel center. 
Starting from the beamline drawings it is a lot of work, but once it is 
done, it can be saved in a template file for that beamline and used in 
creating all imgCIF data sets until someone changes the physcial setup.


   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 Thu, 14 Aug 2008, Justin Anderson wrote:

> Hello,
>
> I think perhaps this goes back to a main point that those of us trying to
> create CBF images need to get clarified.  That is, what are the minimum
> categories/tags that need to be included to have a valid CBF image?  If
> cbf_construct_detector function is a commonly used one then it might help to
> know what information that function requires.
>
> Regards,
>
> Justin Anderson
>
> On Fri, Aug 1, 2008 at 7:58 PM, Nicholas K. Sauter <nksauter@lbl.gov> wrote:
>
>> Herbert,
>>
>> That sounded like a good idea...I just tried it but unfortunately I still
>> get the return value of 0x4000 (16384 decimal).  So I guess the question
>> still stands...hopefully Justin can reproduce the result.
>>
>> Nick
>>
>> Herbert J. Bernstein wrote:
>>
>>  Dear Nick,
>>>
>>>  The 0x4000 is a "not found", which means that the cbf
>>> is missing a category or tag needed to construct a detector.
>>> You may wish to try cbf_require_reference_detector, which will
>>> try to fill in what is missing, if possible.
>>>
>>>  Regards,
>>>    Herbert
>>>
>>>  Herbert & Justin,
>>>>
>>>> I'm trying to verify function of the cbf library (v0.8.0) with respect
>>>> to the images posted at
>>>>
>>>> http://cbflib.wiki.sourceforge.net/CBFlib+test+images
>>>>
>>>> However, I'm seeing problems with both of the mar images.
>>>>
>>>> 1) With cbf_marccd_img.bz2, the function cbf_construct_detector() returns
>>>> value &x4000.  As far as I know, all functions must return a value of zero.
>>>>  In any case, I don't know how to proceed.  My application traps the
>>>> non-zero value and fails.
>>>>
>>>> 2) With orig_marccd_img.bz2, the header contains an end_xtal_to_detector
>>>> value of 1000 microns.  This is not a reasonable detector distance for a
>>>> physical experiment; normally I expect somewhere between 70 and 1000
>>>> millimeters.  So my application doesn't know how to treat the data.
>>>>
>>>> Do either of you have any further insight or suggestions?
>>>>
>>>> Nick
>>>>
>>>
>>>  --
>> Nicholas K. Sauter, Ph.D.
>> Lawrence Berkeley National Laboratory
>> 1 Cyclotron Road
>> Berkeley, CA 94720
>>
>> nksauter@lbl.gov
>> Voice: 510-486-5713
>> Fax: 510-486-5909
>>
>>
>
_______________________________________________
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