Skip to content

[BIFROST] Implement support for a moving detector#101

Draft
jl-wynen wants to merge 13 commits intomainfrom
jlw-workflow-patches
Draft

[BIFROST] Implement support for a moving detector#101
jl-wynen wants to merge 13 commits intomainfrom
jlw-workflow-patches

Conversation

@jl-wynen
Copy link
Copy Markdown
Member

WIP, requires scipp/ess#246

g5t and others added 13 commits April 7, 2026 11:41
The positions and orientation of components after the sample position
are, strictly speaking, time-dependent parameters. Previously their
transformation chains lacked this fidelity due to limitations in
creating the NeXus Structure JSON via `moreniius`. Those limitations
have been lifted and newly-generated BIFROST simulation files include
NXtransformation groups with NXlog constituents.

In order to calculate the correct analyzer and sample scattering angle
for each detector pixel, the BIFROST workflow performs some geometry
calculations in the coordinate frame which rotates with the detector
tank, around the sample position.
Since the analyzers and detectors are stationary in this frame, we can
(and must) remove any time-dependence from their positions and
orientations.

This PR introduces a quick-and-dirty hack to only use the first
time-point from any time-dependent transformation result for the
- sample
- analyzers
- detectors
The NeXus format specification now allows most base objects to specify
two attributes which help define the *expected* beam path through a
collection of instrument components: `@inputs` and `@outputs`.

Updates to `moreniius` mean that the BIFROST NeXus Structure JSON now
contains these attributes, including the one-to-many and many-to-one
transitions between, e.g., the sample position and the 45 analyzers.

Given a detector's HDF5 Group, it is possible to follow the @inputs
attributes analagously to a depends-on chain to identify which analyzer
the detector should have received its neutron events from.

This commit adds functionality which has only been tested outside of the
workflow, by defining the `DetectorAnalyzerMap` at repl scope and the
patching `ess.bifrost.io.nexus._get_analyzer_for_detector_name` to use
the static relational information.
I imagine it needs work to mold it into an appropriate `sciline`
workflow.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants