Development MXv2

From EdnaWiki
Jump to: navigation, search

Development data model for MXv2

The following people are currently participating in the development of this data model: Gérard, Gleb, Johan, Olof, Peter and Sándor. Pierre has also attended one data modelling videoconference.

The idea is that in the initial stages, only the scientific accuracy of the model should be considered, and we should not consider ourselves bound by any external conventions (including those required to implement it using current EDNA methods). The other important criterion is that the model should not contain anything that is specific to any particular application.

For information about some of the UML constructs such as ordering and association redefinition that have been used in these diagrams see UMLConstructsEDNA

Positionable instrumentation

This diagram shows the model for a detector and rotational goniostat modelled as an ordered set of axes that can have a displacement applied to them (either angular or linear). These axes correspond to settable devices provided by the beamline control software. For a particular instrument, each axis operates on other axes subsequent to it in the list. The diagram in its current state provides only for the direction of each axis at a datum or "home" setting of the instrument being provided: this is sufficient for our purposes at the time of writing because all axes that we currently deal with refer directly to the origin of the coordinate system (where the beam and crystal goniostat axes intersect), but it could be extended to cater for axes at arbitrary positions.

The RotationalGoniostat is understood to be a goniostat where only the rotational elements are considered, hence only consists of rotational axes: other devices (used for centering for example) are disregarded. A more complete representation of a goniostat could be represented in this model by including all the motors present in the physical goniostat.

A RotationalGoniostat's base axis is understood to operate on all of the goniostat's other axes, but it itself is not operated on by anything. It also has a special relationship to the unit vectors that define the coordinate frame (expressed here as the constraint that its direction is one of those vectors, but other ways of doing this are possible).

The NonCoupledDisplacementSet class can be ignored for the time being. It is intended to represent set of axes that do not operate on each other, but collectively operate on other axes in the set. It could be used for example, to represent the two motors of the XY stage of the Maatel MD2 microdiffractometer

MXv2 displacers.png

Instrument Settings

The setting of an instrument defined in the previous diagram is expressed as a list of settings for each of the axes that make up the instrument, specialised to be consistent with the instrument definition itself.

Basic classes for the beam have been added for the sake of completeness, although the beam cannot be considered to be a type of DisplacementList. The beam direction is included as a derived attribute of BeamSetting to allow for the case where it changes with wavelength (although this is debatable: maybe it would be better to include the nominal direction as an attribute of Beam

MXv2 instrument settings.png

Detector Position

The diagram below expresses the setting of a detector in a device-independent way (rather like an orientation matrix expresses the setting of a crystal). This is in contrast to the previous diagram, which represents the setting of a detector in terms of its settable elements (distance, two-theta axis if present...). The Detector class is common to the two diagrams.

It presupposes that the face of the detector contains two axes with a common origin whose relationship to the physical detector object is known: these could be (but don't have to be) the "fast" and "slow" axes. The detector setting is then expressed as the location of that common origin, and a pair of unit vectors giving the directions of those two axes (all in the instrumental coordinate frame).

MXv2 detector.png

The relationship between each DetectorSetting.detectorAxisDirection and its corresponding DetectorAxis is inferred from the {ordered} properties that are used for each. There is no direct link between a detectorAxisDirection and its corresponding DetectorAxis: see UMLCycles for a discussion of the problems that that would cause.

Data collection

This diagram shows a view of data collection that is (mostly) consistent with the MXv2 discussion of 2009-06-17. The two major qualifications are:

1. The detector setting is defined by using the settings of the displacement axes, rather than the device-independent description. This assumes of course that there is always going to be a way of calculating the device-independent settings from the displacement axes and the calibration settings.

2. It does not contain the AxisDirectionRefined item that was discussed at the time. This quantity can be calculated multiple times after data collection, and is not part of what defines a data collection (Gleb: have I got this right? Peter.) and should probably be modelled in some other way, rather than being a property of RotationExposure

A CollectionWedge is a series of images measured continuously in time and space, in such a way that at the start of a frame (other than the first one) the device sees the sample in exactly the same state as it was at the end of the previous one (independently of the parameters of the exposure). Also the state of the instrumentation is preserved. (The relationship between partials on adjacent images must be usable in postrefinement within a wedge, at least in principle.) This means that within a wedge, there must be no:

1. Change in wavelength (within instrumental tolerance)

2. Discontinuity in variation of flux

3. Change in beam direction

4. Change in orientation matrix outside of radius of convergence

5. Dose discontinuity.

In addition, within a SubWedge, exposure time and width are the same for all images.

The ProcessingWedge class is a just reminder at this stage that images may be grouped together in arbitrary ways during processing

MXv2 data collection.png