benajamin
commented
2 years ago The NXsample class is intended for both attributes of the sample itself, and its environment. For environment parameters that are changing during the experiment, you could treat the environmental sensors as a detector and include them in /entry/instrument/, perhaps also with a link from a field in /entry/sample/. Further, by treating the environment sensor as a detector, you can switch between sample environments in the same way as you would switch between detectors. We are doing this at the PolLux@SLS beamline using the NXstxm application definition.
Dear Nexusformat community, I am new to the Nexusformat and its standards. When I was looking into it, I could not see any class that deals with sample environments directly. There is NX_instrument for the instrument / beamline, but I understand it contains more beamline aspects, e.g. attenuators, beam. I am trying to implement a multi-modal sample environment into an instrument and also into the NeXus file for the beamline. It will probe the sample with UV, fluo spectrometry and measure the density of the sample. Several pumps and switch valves will be also involved. What would be your advice how to implement such a sample environment into the Nexusformat? Would you split it up or put it as one group next to the instrument entry?
And a general question: A beamline / instrument offers usually multiple sample environments, but they are not necessarily always in. Would it be reasonable to have sample environments on the same level as /entry/instrument, i.e. /entry/sample_environment? In case it is required, one switches the sample environment into the Nexus file.
I was looking at Nexus file of other large scale facilities. Concerning sample environments, there does not seem to be an agreement how to handle those.
Thank you for your advice.