# The generic data model coordinate system

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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. XDS offers the user to freely define the convenient coordinate frame for his experiment. The definitions are via assignment of two (orthogonal) directions in the laboratory frame to the detector scan axes directions. The choice of such assignment still needs to be made for EDNA.

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

## Gleb's suggestion

• Good reference points: beam + detector
• Possible convenient solution:

X (1 0 0 ) axis is along the beam
Z( 0 0 1 ) axis is along the normal to the beam drawn at an acute angle to the fast detector axis in the plane parallel to the beam and the fast detector axis
Y (0 1 0 ) selected to complete the right-handed coordinate system

0 1 0 direction given by cross product of fast detector scan direction and beam direction.

• Pro's of such definition:
• No over-definition - all the parameters involved are defined by the diffraction experiment
• Any useful change in the experimental condition (like change in the crystal orientation, scan axis, detector two-theta) is implemented as a change in a relevant model parameter, without re-calculating a complete model, as would require in case of rotation of the detector around the beam. In practice, the two-theta axis may be misaligned with respect to the detector and still induce such a rotation component (detector around the beam). If small, this will be compensated by the refinement of crystal orientation and spindle direction. If large, the instrument-specific transformation of a complete model (incl. change in a crystal and goniostat axes orientations) will require.
• Axes assignment corresponds to MOSFLM coordinate frame

## 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 (in case of "standard" orthogonal geometry; any direction of the spindle - e.g. phi-scan or omega scan with two-theta offset can be defined and refined).

## 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[ Detector.FastAxis x BeamDirection ] = { 0 1 0 } - by definition