NXtransformations: chaining vs. active/passive transformations

[woutdenolf]

I assume that the values in NXtransformations define active transformations (i.e. coordinate transformations) in analogy with all other transformations in the Nexus standard. This needs to be specified explicitly in the docs. However when looking at chaining, they might actually be passive transformations.

The NXtransformations docs say

when T1 depends on T2 and that in turn T2 depends on T3, the final transformation is T3.T2.T1

Suppose we have two objects, one with R4.R3.R2.T1 and the other with R5.R3.R2.T1. We could define two NXtransformations groups which define the full stack of transformations

entry
    instrument
        object1
            depends_on=position1/T1
                position1:NXtransformations
                    T1
                        @depends_on=R2
                    R2
                        @depends_on=R3
                    R3
                        @depends_on=R4
                    R4
        object2
            depends_on=position2/T1
                position1:NXtransformations
                    T1
                        @depends_on=R2
                    R2
                        @depends_on=R3
                    R3
                        @depends_on=R5
                    R5

Note that the first transformation (T1) occurs first if you think about applying the transformations to the objects one by one in physical space. This is assuming NXtransformations are active transformations.

The NXtransformations docs also say

Following the chain may also require following depends_on links to transformations outside, for example to a common base table

Since our two objects have a common base transformation, lets try to use common NXtransformations group

entry
    instrument
        baseposition:NXtransformations
            T1
                @depends_on=R2
            R2
                @depends_on=R3
            R3
        object1
            depends_on=position1/R4
                position1:NXtransformations
                    R4
                        @depends_on=../baseposition/T1
        object2
            depends_on=position2/R5
                position1:NXtransformations
                    R5
                        @depends_on=../baseposition/T1

However this means I have R3.R2.T1.R4 and R3.R2.T1.R5 which is not what I want. In other words using a common base NXtransformations cannot work.

However when NXtransformations are passive, it would work

entry
    instrument
        baseposition:NXtransformations
            R3
                @depends_on=R2
            R2
                @depends_on=T1
            T1
        object1
            depends_on=position1/R4
                position1:NXtransformations
                    R4
                        @depends_on=../baseposition/R3
        object2
            depends_on=position2/R5
                position1:NXtransformations
                    R5
                        @depends_on=../baseposition/R3

which would give R4.R3.R2.T1 and R5.R3.R2.T1. In other words using a common base NXtransformations works.

Note that the last transformation (T1) occurs first if you think about applying the transformation to the objects one by one in physical space. This is assuming NXtransformations are passive transformations.

As a side question: is ../baseposition/R3 valid? Or does it need to be entry/instrument/baseposition/R3? Or is both allowed?

[PeterC-DLS]

~You are correct that T₃T₂T₁ is the passive transformation and we should be explicitly use active transformations so that T_f=T₁T₂T₃ or reverse the dependency chain.~

The equation is correct as each step in the transformations dependency chain is specified as an active transformation and the T_f actively transforms the component in the laboratory frame.

[prjemian]

@woutdenolf asked:

As a side question: is ../baseposition/R3 valid? Or does it need to be entry/instrument/baseposition/R3? Or is both allowed?

In the manual's nxdl_desc documentation, there is this text:

From the HDF5 documentation:

Note that relative path names in HDF5 do not employ the ../ notation, the UNIX notation indicating a parent directory, to indicate a parent group.

In the case of @depends_on= values, we are not bound by the limitation of HDF5 since we implement these transformations once the HDF5 files has been read. To be consistent with the rules for HDF5, it would be very helpful to use the same rule for @depends_on as the rule as limited by the HDF5 documentation.

I am not certain we have ever been clear whether we allow for relative paths or require absolute paths. We should clarify the documentation as to what types of addressing (relative or absolute are allowed.

[PeterC-DLS]

I have used relative addressing in my code as writers may not be aware of the absolute location of the destination and/or do not resolve it dynamically.

[woutdenolf]

In fact the NXtransformations are active transformations. See https://github.com/nexusformat/definitions/pull/1278