Workflow patches for @inputs and time-dependent transformations#93
Open
Workflow patches for @inputs and time-dependent transformations#93
Conversation
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Seemingly depends on my PR to
essreduce, though I imagine there is a better way to achieve the reduction to the first-time-point only. Otherwise loading any data from the files fails due to transformation dependency-chain resolution problems.@inputsneutron-path information, now present in simulated BIFROST NeXus files, to resolvedetector->analyzerrelationships. This approach works partly-outside of the normal workflow and likely needs tweaking to work the correct way.