Consider loading source from NXmoderator

[jl-wynen]

The NeXus workflow loads source information from an NXsource group. The current BIFROST files (both written by Greg and CODA) don't contain such a group but use NXmoderator instead.

A moderator group contains different data than a source group. But it does have a position which is all we need in our current workflow. So we may want a way to use a moderator instead of a source.

[jl-wynen]

This may be an oversight in the file schema. See https://jira.esss.lu.se/browse/ECDC-4262?jql=text+%7E+%22source%22+AND+assignee+in+%28georgeoneill%29

[g5t]

I'm willing to accept different opinions, but my current viewpoint is influenced by the NeXus Format base class descriptions

• NXsource, "The neutron or x-ray storage ring/facility"
• NXmoderator, "A neutron moderator"

I interpret this, as well as the list of optional group fields for each, to suggest that the two groups contain different types of information for spallation neutron sources

• NXsource contains information about the proton accelerator and (possibly) target
• NXmoderator contains information about the component which moderates high-energy neutrons to useful energies

The position of the accelerator and target are irrelevant for neutron instruments, since it is the moderator which defines the distribution of neutrons available to the instrument.

The NXmoderator group is the best available base group to use for the position of the neutron origin, but leaves a bit to be desired since the physical moderator and the 'viewed' origin do not need to coincide.

Until such time as an NXneutron_origin or NXguide_view are added to the NeXus format standard, I would argue in favor of using the NXmoderator group position over that of the NXsource.

[jl-wynen]

This sounds like we should in general move away from using the 'source' in general and should reformulate it as 'neutron origin'. Detaching it from NeXus names would allow us to better customise it for different instruments. @SimonHeybrock did you already consider this when designing the workflow in ESSreduce?

[SimonHeybrock]

Not sure which part you refer to @jl-wynen ?

[jl-wynen]

Not using NXsource to define the flight path and t0. Right now, we load NXsource and store it as source_position which is then used in coordinate transforms.
Did you consider making this more generic and not relying on NXsource?

[SimonHeybrock]

The only reason we used NXsource was that we assumed that that will define the moderator position. If that is not the case we should not do that, and use another component instead. Naming ("source position") comes from Mantid, so I do not mind changing that either.