Axes with more than one dimension

[SimonHeybrock]

For our application (neutron scattering) we frequently deal with axis-arrays that have more than one dimension. To my understanding this mainly occurs when one of the dimensions is not a continuous variable but rather a discrete set of values, such as a label.

As an example, consider measuring a series of values at a number of points in in space:

auto v =
    variable(data,
             xf::coordinate({{"position", xf::axis({pos1, pos2, pos3, pos4})},
                             {"time", xf::axis({1ms, 2ms, 3ms})}}),
             xf::dimension({"position", "time"}));

// "time" can be converted into other related physical quantities, e.g., wavelength
auto v2 = convert(v, "time", "wavelength");

For illustration, consider also this figure: http://docs.mantidproject.org/v3.11.0/_images/MBC_Ragged.png.

• The conversion from "time" to "wavelength" depends on the position (in the linked figure, every spectrum is measured at a different position). Therefore, the "wavelength" axis in v2 must have different values for every "position" index.
• We may later rebin the data onto a common axis, but for intermediate steps the non-aligned axis is required.
• I think only one of the coordinates can have more than one dimension. For example, "position" cannot depend on "wavelength".
• If an axis is multi-dimensional many operations operate without changes, but some are not possible. For example, indexing slices is only possible with an index, but not with the label provided by the axis.

In general, I think similar types of a multi-dimensional axis would be required by many adjustments or conversions that depend on one of the other axes.

[JohanMabille]

That's something we have not thought about yet. The current architecture is flexible enough so we can plug different implementations of coordinates, however whether such a coordinate object could fit in xframe must be studied.

[kunaltyagi]

Any updates on this?

[SimonHeybrock]

From our side, we have since chosen a different mechanism, relying on type erasure to build a library (https://scipp.github.io/) that supports this and other features in a Python-like manner. From my point of view this issue could thus be closed.

[JohanMabille]

Unfortunately no, I didn't have the time to improve xframe during the past year.