[Nexus] Correct way to specify multiple signals

[Jacob.Filik at Diamond.ac.uk]

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.

Kind regards,

Jacob

Dr Jacob Filik
Senior Software Scientist
Tel: +441235 77 8690
 
Diamond Light Source Ltd.
Diamond House
Harwell Science & Innovation Campus
Didcot
Oxfordshire
OX11 0DE



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

On 11/01/2018 10:24, Tobias Richter wrote:
> Hi Armando,
>
> First of all: With the new scheme where the attributes belong to the NXdata group there are no “,” separated lists. That scheme uses attribute arrays (for axes). I’ve just made that yet a bit clearer in the NXdata base class documentation. Hope that helps.

Thanks. That has already answered a second question I have just asked :-)

>
> Otherwise there is currently no provision for plotting multiple things out of a single NXdata. If the axes of multiple NXdata groups coincide, an application would be free to plot them into the same coordinate system. 
> For signals with 2 or more dimensions it is not obvious what should be done. Keeping the generic case simple and clean makes sense to me.

Well, for 2 or more dimensions the simplest way is to use a "signal"
browser but any application could implement whatever approach convenient for the application (for instance playing with transparency could be other approach).

My colleagues suggest that for compatibility issues perhaps to define a new NXdata group attribute signals (instead of signal) would avoid any confusion at programs expecting to find signal as a string and not as an array of strings.

Armando



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