Fairmat 2024: use NXcoordinate_system together with NXtransformations

[lukaspie]

This PR is concerned with coordinate systems and the transformations that are intricately linked to them. It was started for multiple reasons:

• There is the frequent need to explicitly describe which coordinate system is used in an experiment.
• NeXus by default uses a coordinate system that is the same as that used by McStas. However, this can be limiting:
  • there are now several techniques coming in where there is no explicit beam defined: temperature-dependant IV measurements, scanning probe microscopy (STM, AFM), etc.
  • in some communities, there already exists an agreement on which coordinate system shall be used, which is different than what NeXus uses. As an example, there is an existing ISO standard for data transfer in surface chemical analysis that uses a coordinate system that is left-handed and defined based on the sample stage. It would be good if in an application definition (e.g. NXxps) one could explicitly state which coordinate system is to be used. There has already been some discussion on this, see NXmpes #1464 (comment)
    • Specifically on this, for the XPS community, there are certain angles (e.g. analyser-to-beam) that are needed to perform rigoruous analysis. It would be helpful if one could write these in the existing coordinate system (as in the ISO standard), without needing to transform back from the NeXus coordinate system.
• NeXus (with its concept of NXtransformations) does already allow to define a specific coordinate system (see e.g. discussion in NXtransformations: clarify that these are active transformations + example #1278). But, this has several limitations:
  • these transformations always depend on a tool that can read them out and perform the transformations itself. We would also like to allow that one can give an coordinate system explicitly, both in a machine and human readable way
  • left-handed CSs are currently not supported
  • fractional coordinates are not supported

Therefore, we introduce in this PR two new base classes: NXcoordinate_system and NXcoordinate_system_set.

Explanation of using NXcoordinate_system and NXtransformation:

• NX_coordinate_system_set contains one or more of NXcoordinate_system
• in NXcoordinate_system, there is a depends_on, and (NXtransformation) group
• in NXtransformation AXISNAME depends_on, one can place either ".", or the path to an NX_coordinate_system
• if a depends_on attribute or field links to a NXcoordinate_system, it should pick the respective depends_on field in that class, and apply the specified TRANSFORMATIONS

Example of how this is implemented in a (proposed) application definition: NXXps

[lukaspie]

Copying here discussion that was buried in #1464 for clarity:

LP: we shall align to and extend the existing ISO standard for XPS. The concept of coordinate systems allow connecting multiple conventions.
PM: Which use cases needs a different coordinate system?
LP: ISO standard requires a different coordinate system
SB: Another example is when NeXus coordinate system being linked to incident beam does not exists because no beam exists in a specific experiment type, like temperature dependent IV measurement.
PM: shall we make this a standard, so all sw shall implement the ability of changing coordinate systems?
HB: NeXus shall allow multiple coordinate systems, as MX is also using it and other fields also require that. It is preferred to have a clearly described way how to do that.
PC: NeXus uses McStas as default, but other coordinate systems can also be used. Important is that the use of NXtransformations shall be consistent throughout the datasets.
SB: This is exactly what the proposal is about: provide a simple solution either on how to use NXtransformations when a base change is required to connect two coordinate systems, or on describing a coordinate system which is used in the definition and data file.
PM: Cannot we use a label for this purpose?
SB: Indeed that is what hapenning: Currently, the NXtransformations chain is followed along @depends_on until it ends with '.'. The proposal is that instead of ending with a '.', it could end with a label pointing to a Coordinate System which either describes a coordinate system on its own, or connetcs it to another coordinate system using NXtransformations.