Difference between revisions of "The generic data model coordinate system"

From EdnaWiki
Jump to: navigation, search
Line 1: Line 1:
This is a first draft of the generic data model coordinate system (see bug #51 for a discussion):
+
This is a first draft of the generic data model coordinate system. No choice have been made yet so please be prepared that this page will change in the near future.
   
 
The main goals with this coordinate system definition are:
 
The main goals with this coordinate system definition are:
   
  +
* To have a coordinate system which is "calibratable".
 
* To be able to describe complex experiment geometry (kappa goniostats, offset detectors etc.)
 
* To be able to describe complex experiment geometry (kappa goniostats, offset detectors etc.)
 
* To be able to as easily as possible track refined values during data processing.
 
* To be able to as easily as possible track refined values during data processing.
   
  +
The MOSFLM and the imgCIF definitions do not fulfill these goals. The imageciff reference frame (http://it.iucr.org/Ga/ch3o7v0001/fig3o7o3o1.pdf) is bound to the "beam" and "principle goniostat axis". The problem with this definition is that the orientation of the "principle axis" is basically undefined by our typical experiment, unless the "principle axis" is the scan axis as well.
Neither the MOSFLM nor the XDS coordinate system definitions fullfill these two goals.
 
  +
  +
The XDS data model is very flexible so it's definition of coordinate system could in principle be used.
  +
  +
Here are three possible definitions of generic data model coordinate systems:
  +
  +
== Gleb's suggestion ==
  +
  +
* Good reference points: beam + detector
  +
* Possible convenient solution:
  +
** Beam along 1 0 0
  +
** 0 1 0 direction given by cross product of beam direction and fast detector scan direction.
  +
  +
== Pierre's suggestion ==
  +
  +
* Use detector as reference (as does XDS):
  +
** Detector X : 1 0 0
  +
** Detector Y : 0 1 0
  +
  +
In the processing, assume that the beam is 0 0 1 and then refine.
  +
  +
== Sandor's suggestion ==
  +
  +
* Use gravity as 0 1 0
  +
** Cross product of beam and graviy -> 1 0 0
  +
  +
-------------------------------------------
  +
   
Neither does the imgCIF definition - the imageciff reference frame (http://it.iucr.org/Ga/ch3o7v0001/fig3o7o3o1.pdf) is bound to the "beam" and "principle goniostat axis". The problem with this definition is that the orientation of the "principle axis" is basically undefined by our typical experiment, unless the "principle axis" is the scan axis as well.
 
   
   

Revision as of 16:39, 9 September 2008

This is a first draft of the generic data model coordinate system. No choice have been made yet so please be prepared that this page will change in the near future.

The main goals with this coordinate system definition are:

  • To have a coordinate system which is "calibratable".
  • To be able to describe complex experiment geometry (kappa goniostats, offset detectors etc.)
  • To be able to as easily as possible track refined values during data processing.

The MOSFLM and the imgCIF definitions do not fulfill these goals. The imageciff reference frame (http://it.iucr.org/Ga/ch3o7v0001/fig3o7o3o1.pdf) is bound to the "beam" and "principle goniostat axis". The problem with this definition is that the orientation of the "principle axis" is basically undefined by our typical experiment, unless the "principle axis" is the scan axis as well.

The XDS data model is very flexible so it's definition of coordinate system could in principle be used.

Here are three possible definitions of generic data model coordinate systems:

Gleb's suggestion

  • Good reference points: beam + detector
  • Possible convenient solution:
    • Beam along 1 0 0
    • 0 1 0 direction given by cross product of beam direction and fast detector scan direction.

Pierre's suggestion

  • Use detector as reference (as does XDS):
    • Detector X : 1 0 0
    • Detector Y : 0 1 0

In the processing, assume that the beam is 0 0 1 and then refine.

Sandor's suggestion

  • Use gravity as 0 1 0
    • Cross product of beam and graviy -> 1 0 0



Class: Unit Vector : { float float float } , dimensionless, 
Beam Direction - Unit Vector 1 0 0  -- by definition


ExperimentalCondition
  DiffractionOrigin { 0 0 0 - default} - vector (not unit vector) - mm
  Detector
    DistanceToDiffractingCrystal ( mm )
    BeamCoordinateFast
    BeamCoordinateSlow 
    FirstPixelPosition { vector } 


    Fast Axis
      Direction { Xfast, Yfast, Zfast }
      BeamCoordinate ( mm ) - 
  Slow Axis
      Direction { Xslow, Yslow, Zslow }
      BeamCoordinate ( mm )

Cross[ BeamDirection x Detector.FastAxis] = { 0 1 0 } - by definition