[Nexus] Correct way to specify multiple signals

[Jacob.Filik at Diamond.ac.uk]

Ah, that is very interesting, I hadn't considered putting NXdata inside NXProcess (or more likely inside the NXProcess, and each NXNote within, if that is how you structure your NXProcess).

I feel it would be useful to have some examples or recipes, or even just example trees on the recommended way to store "rich" metadata for a scan. There is always connections between datasets which is hard express using only the nexus structure as is.

A processed XRF grid scan is a fine example: I have 4d raw Xspress3 data block, and the 3D sum of all 8 channels and many 2D  element fitting results of the sum, each have the x and y set values as axes, but these axes actually come from NXPositioners, which also contain read-back values (which are probably better as axes, but more difficult to display the elemental map against).

As someone who writes software that reads Nexus I want to know all this, but at the moment it is a struggle.

I would be interested to see an example Nexus Tree for the structure you are proposing (like the ones the NexusFormat python prints).

Kind regards,

Jacob

-----Original Message-----
From: NeXus [mailto:nexus-bounces at shadow.nd.rl.ac.uk] On Behalf Of V. Armando Solé
Sent: 11 January 2018 10:03
To: nexus at nexusformat.org
Subject: Re: [Nexus] Correct way to specify multiple signals

Hi Jacob,

On 11/01/2018 10:50, Jacob.Filik at Diamond.ac.uk wrote:
> Hi All,
>
> We also often struggle with how to explicitly show two datasets are related (e.g. raw data and fitted data).
>
> We have been sticking to the "one signal per NXdata", even when the axes are the same, and therefore can have lots of NXdata in a single NXentry, with little obvious to connect them (except just the name).
>
> We are looking into how we can specify the relationship between datasets, i.e. raw data in an NXdata comes from the NXdetector, the fitting result NXdata comes from algorithm defined in this NXprocess acting on the data in this NXdata (which comes from this NXdetector etc), but we haven't implemented against it yet.
>
> This is considerably more verbose than "signals" but should have better provenance.
>

Thanks for for your contribution.

We want *exactly* that because our intention is to put the NXdata group containing multiple signals *inside* and NXprocess group. As you see we want the same thing and having "signals" would allow us to do it because as far as I know NXdata has no restrictions about where can be located in a NeXus file.

We would be able to store in NXprocess the configuration used for the treatment and the results of it.

Armando


_______________________________________________
NeXus mailing list
NeXus at nexusformat.org
http://lists.nexusformat.org/mailman/listinfo/nexus