You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
in practice a bluesky tiled run that is compliant would have a list of available NEXUS formats in it's start document metadata and where (within the tiled run - baseline, primary, monitor stream or descriptor etc) to get the metadata for each element of that NEXUS format, so a reader that was interested in NXXAS, NXSAS, NXcanSAS (like Pyhyper) could reach in and get that structured data without having the complexity in the reader code. It could also ignore the Nexus formats it's not interested in, (NXXRR). So the same simple reader code could read data from any compliant tiled/bluesky source.
It seems to me that this would simplify the loader lift for each instrument -(putting that weight on the beamline to structure it's metadata nicely). It's also a way to future proof a reader for a beamline, so you don't have to remember how to find the certain metadata from RSoXS in sept 2021 as opposed to oct 2022 within pyhyper.
I think there would probably need to be a way to replace the lookuptable provided in the metadata with a different custom lookup table.
The text was updated successfully, but these errors were encountered:
EliotGann
changed the title
a unified Tiled NXSAS / NXcanSAS loader
Feature: a unified Tiled NXSAS / NXcanSAS loader
Sep 3, 2024
There is an effort to make NEXUS compatible metadata available in EVERY bluesky scan.
One approach is shown in process here
in practice a bluesky tiled run that is compliant would have a list of available NEXUS formats in it's start document metadata and where (within the tiled run - baseline, primary, monitor stream or descriptor etc) to get the metadata for each element of that NEXUS format, so a reader that was interested in NXXAS, NXSAS, NXcanSAS (like Pyhyper) could reach in and get that structured data without having the complexity in the reader code. It could also ignore the Nexus formats it's not interested in, (NXXRR). So the same simple reader code could read data from any compliant tiled/bluesky source.
It seems to me that this would simplify the loader lift for each instrument -(putting that weight on the beamline to structure it's metadata nicely). It's also a way to future proof a reader for a beamline, so you don't have to remember how to find the certain metadata from RSoXS in sept 2021 as opposed to oct 2022 within pyhyper.
I think there would probably need to be a way to replace the lookuptable provided in the metadata with a different custom lookup table.
The text was updated successfully, but these errors were encountered: