Add WavelengthDetector and WavelengthMonitor to GenericTofWorkflow

[nvaytet]

Add the ability to compute WavelengthDetector and WavelengthMonitor to GenericTofWorkflow.

This can be overridden in downstream packages:

• diffraction: the provider either adds more coordinates than just wavelength
• SANS: the wavelengthDetector type is different WavelengthDetector[RunType, Numerator]

but it is still useful to have a default implementation here (for e.g. livedata)

[SimonHeybrock]

Two questions aside from comments below:

• Should downstream packages that compute this differently remove/prune this do avoid confusion if they use a different domain type, do avoid users computing the false one?
• Could the TOF lookup produce wavelength directly to avoid the extra intermediate step?

[SimonHeybrock]

Spelling

[SimonHeybrock]

I thought this is (or should) already be added when computing TOF?

[nvaytet]

We don't add the Ltotal coord on the TofDetector.
We just add source_position and sample_position in the coord transform graph and compute Ltotal from that, but it doesn't make it in the output (see https://github.com/scipp/essreduce/blob/main/src/ess/reduce/time_of_flight/eto_to_tof.py#L335)

source_position and sample_position don't make it either in the output.
This was what we did during the Scipp retreat (before that, I think we were adding these coords to the output).

It does mean that now, if you have a data array which is the TofDetector, you can't compute wavelength from just that. It is no longer self-contained.

Should we add the coords back in?

[SimonHeybrock]

Not sure about our reasoning in October. Wouldn't you think it is conceptually sensible and safer to add it as a coord? I don't think the positions are necessary, but TOF only makes sense with a known Ltotal, right? In a sense they form a pair.

[nvaytet]

Yes, I agree. I'll add Ltotal then!

[SimonHeybrock]

Feels a bit odd to have both of these here. If both ltotal and tof is given by the inputs, why do we need a transform graph? Does passing it here give a false promise that the wavelength computation can be influenced via the graph? It might lead to surprising bugs if the graph does some special flightpath correction but then gets silently ignored.

[nvaytet]

Should we instead forget about the graph and transform coords and compute the wavelength manually using the formula?

[SimonHeybrock]

Yes, or import the underlying function, not the entire graph?

[nvaytet]

Should downstream packages that compute this differently remove/prune this do avoid confusion if they use a different domain type, do avoid users computing the false one?

Good question, I am not sure how best to do this actually.

Could the TOF lookup produce wavelength directly to avoid the extra intermediate step?

Did you mean just compute wavelength and not have a TofDetector? Or did you mean just have a provider that computes it from the lookup, without going via the TofDetector, where the end graph would allow you to compute both TofDetector and WavelengthDetector, where both these nodes would be connected to the same parents?

[SimonHeybrock]

Should downstream packages that compute this differently remove/prune this do avoid confusion if they use a different domain type, do avoid users computing the false one?

Good question, I am not sure how best to do this actually.

Could the TOF lookup produce wavelength directly to avoid the extra intermediate step?

Did you mean just compute wavelength and not have a TofDetector? Or did you mean just have a provider that computes it from the lookup, without going via the TofDetector, where the end graph would allow you to compute both TofDetector and WavelengthDetector, where both these nodes would be connected to the same parents?

The latter. TofDetector might be not needed in practice (except for debugging). But I am not suggesting to change it here and now, this was just a thought.

[SimonHeybrock]

Just the question about Ltotal remaining: Why is the TOF workflow not settings this as a coord on TofDetector? It was used to compute another coord, so I would think it belongs there to ensure consistency?