Generic tof workflow #233
Generic tof workflow #233
Conversation
src/ess/reduce/nexus/types.py
Outdated
|
|
||
|
|
||
| class CalibratedBeamline(sciline.Scope[RunType, sc.DataArray], sc.DataArray): | ||
| class CalibratedDetectorBeamline(sciline.Scope[RunType, sc.DataArray], sc.DataArray): |
There was a problem hiding this comment.
We spoke the other day about not breaking downstream and notebooks anymore by renaming (unless really necessary). Is this necessary? Is the new name better?
There was a problem hiding this comment.
You are right, this would break
essspectroscopybeamlimeessdiffractionesssans
See code search here.
I'll revert.
src/ess/reduce/nexus/workflow.py
Outdated
| This is performed separately and after :py:func:`get_calibrated_monitor` to avoid | ||
| as false dependency of, e.g., the reshaped detector numbers on the sample position. | ||
| The latter can change during a run, e.g., for a rotating sample. The detector | ||
| numbers might be used, e.g., to mask certain detector pixels, and should not depend | ||
| on the sample position. |
There was a problem hiding this comment.
This does not apply here? Is there thus any reason to not perform this in get_calibrated_monitor? Would avoid the extra type and the "need" to rename CalibratedBeamline.
src/ess/reduce/nexus/workflow.py
Outdated
| _prune_type_vars(wf, run_types=run_types, monitor_types=monitor_types) | ||
|
|
||
| return wf | ||
| from ..utils import prune_type_vars |
| monitor_types: Iterable[sciline.typing.Key] | None = None, | ||
| ) -> sciline.Pipeline: | ||
| """ """ | ||
| wf = GenericNeXusWorkflow() |
There was a problem hiding this comment.
I think this may be slow unless you forward the run_types etc.? Not sure if you then need to prune again, or if there is a better way.
There was a problem hiding this comment.
I opted for pruning twice.
|
Wondering about this bit: Why do we need the |
|
Looking at |
Are you thinking of a case where for example you loaded the lookup table from a file, and then set |
Yes, something like that. |
I am not sure, would be best to discuss this in person/over a call. |
So maybe we should store the |
src/ess/reduce/nexus/workflow.py
Outdated
|
|
||
|
|
||
| def assemble_beamline( | ||
| def assemble_detector_beamline( |
There was a problem hiding this comment.
Can also revert this rename.
| def extract_detector_ltotal( | ||
| detector_beamline: CalibratedBeamline[RunType], | ||
| ) -> DetectorLtotal[RunType]: | ||
| """ | ||
| Extract Ltotal from the detector data. | ||
| """ | ||
| graph = scn.conversion.graph.beamline.beamline(scatter=True) | ||
| return DetectorLtotal[RunType]( |
There was a problem hiding this comment.
I suppose what this really does is the naive straight-line approximation to Ltotal based on basic component positions. I guess the idea is to swap out this provider if something more sophisticated is needed? Maybe the nature of the approximation should be reflected in the names and docstrings?
Conclusion from call: Turns out this was unrelated to this change. |
We build on top of the
GenericNexusWorkflowto add the computation of time-of-flight for the neutron data.See scipp/essimaging#81 for an example of how this is used in instrument reduction workflows.
The graph is the following. Important thing to note is that Ltotal is extracted from the calibrated beamline, not from the detector data, meaning that it is not extracted/computed again every time new streaming events come in.
