[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [Imgcif-l] Goniometer axis question
- To: The Crystallographic Binary File and its imgCIF application to image data <imgcif-l@iucr.org>
- Subject: Re: [Imgcif-l] Goniometer axis question
- From: "Herbert J. Bernstein" <yaya@bernstein-plus-sons.com>
- Date: Mon, 4 Jul 2011 07:31:44 -0400 (EDT)
- In-Reply-To: <13999B6FC038EB44B067771E3CFBD09109ADB9@EXCHMBX01.fed.cclrc.ac.uk>
- References: <13999B6FC038EB44B067771E3CFBD09109ADB9@EXCHMBX01.fed.cclrc.ac.uk>
Clearly a bug (incomplete implementation) Have you tried constructing a goniometer and then applying cbf_rotate_vector to [1,0,0]? That sounds like what we really want cbf_get_rotation_axis to do. I'll cobble together a fix with two new routine names, one to return the reference setting of the nth axis in a chain of axes in a goniometer, and one to return the current setting. Let's say: cbf_get_reference_goinimeter_axis(cbf_goniometer goniometer, unsigned int reserved, int axis_number, double *vector1, double *vector2, double *vector3) cbf_get_goinimeter_axis(cbf_goniometer goniometer, unsigned int reserved, int axis_number, double *vector1, double *vector2, double *vector3) where axis number, starting from 1 is the axis number counting down the chain (most deeply nested axis first) and, if negative, is counting up the chain (with the base axis having axis number -1, the axis on top of that having axis number -2, etc.). I know that sounds backwards, but I think it will make the common default of 1 give you the axis you are most likely to really want. ===================================================== 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 Mon, 4 Jul 2011, Graeme.Winter@Diamond.ac.uk wrote: > Dear All, > > In an effort to understand how multiple axes are handled in CBFlib I "faked up" a toy goniometer which I chose to call FRED, which has a lot in common with a 50 degree kappa axis: > > loop_ > _axis.id > _axis.type > _axis.equipment > _axis.depends_on > _axis.vector[1] _axis.vector[2] _axis.vector[3] > _axis.offset[1] _axis.offset[2] _axis.offset[3] > GONIOMETER_FRED rotation goniometer . 0.643 -0.766 0 . . . > GONIOMETER_OMEGA rotation goniometer GONIOMETER_FRED 1 0 0 . . . > SOURCE general source . 0 0 1 . . . > GRAVITY general gravity . 0 -1 0 . . . > DETECTOR_Z translation detector . 0 0 -1 0 0 0 > DETECTOR_Y translation detector DETECTOR_Z 0 1 0 0 0 0 > DETECTOR_X translation detector DETECTOR_Y 1 0 0 0 0 0 > ELEMENT_X translation detector DETECTOR_X 1 0 0 -126.30 144.39 0 > ELEMENT_Y translation detector ELEMENT_X 0 1 0 0 0 0 > > loop_ > _diffrn_scan_frame_axis.frame_id > _diffrn_scan_frame_axis.axis_id > _diffrn_scan_frame_axis.angle > _diffrn_scan_frame_axis.displacement > FRAME1 GONIOMETER_FRED 30.0 0.0 > FRAME1 GONIOMETER_OMEGA 24.4499 0.0 > FRAME1 DETECTOR_Z 0.0 800.02 > FRAME1 DETECTOR_Y 0.0 0.0 > FRAME1 DETECTOR_X 0.0 0.0 > > loop_ > _diffrn_scan_axis.scan_id > _diffrn_scan_axis.axis_id > _diffrn_scan_axis.angle_start > _diffrn_scan_axis.angle_range > _diffrn_scan_axis.angle_increment > _diffrn_scan_axis.displacement_start > _diffrn_scan_axis.displacement_range > _diffrn_scan_axis.displacement_increment > SCAN1 GONIOMETER_FRED 30.0000 0.0 0.0 0.0 0.0 0.0 > SCAN1 GONIOMETER_OMEGA 24.4499 0.0500 0.0500 0.0 0.0 0.0 > SCAN1 DETECTOR_Z 0.0 0.0 0.0 800.02 0.0 0.0 > SCAN1 DETECTOR_Y 0.0 0.0 0.0 0.0 0.0 0.0 > SCAN1 DETECTOR_X 0.0 0.0 0.0 0.0 0.0 0.0 > > (I presume that cbflib is not upset by silly goniometer names, I got no errors). Anyway offsetting this axis by 30 degrees then asking for the rotation axis I got (1, 0, 0) not the offset axis I was expecting. Checking through the documentation in Tables G it seems that the cbf_get_rotation_axis which is used in pycbf *should* do this. > > Looking at the actual code in cbf_simple I do however see: > > /* Currently just return the first rotation axis */ > > Would I be right in thinking that this is an aspirational method which still needs implementing, or am I perhaps looking in the wrong place? It would be consistent with my observations. > > I checked it out from the code mentioned in Herbert's most recent email... > > Thanks in advance & best wishes, > > Graeme > > -- > 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
Reply to: [list | sender only]
- Follow-Ups:
- Re: [Imgcif-l] Goniometer axis question (Graeme.Winter)
- References:
- [Imgcif-l] Goniometer axis question (Graeme.Winter)
- Prev by Date: Re: [Imgcif-l] Pilatus 2M putative full CBF implementation
- Next by Date: Re: [Imgcif-l] Goniometer axis question
- Prev by thread: [Imgcif-l] Goniometer axis question
- Next by thread: Re: [Imgcif-l] Goniometer axis question
- Index(es):