[Nexus] Correct way to specify multiple signals

[V. Armando Sole]

On 11.01.2018 23:45, Osborn, Raymond wrote:
> 
> But you haven’t explained why you need multiple signals. If it’s
> to store the fit with the raw data, then you will also probably need
> multiple axes, since fitted functions are normally calculated at many
> more points than the raw data. How would you handle that? And do you
> propose to store a copy of the fields within the NXentry raw NXdata
> group?

I have proposed both and explicitly mentioned that auxiliary_signals and 
auxiliary_axes would allow to achieve co-plotting raw_data and fitted 
data with different number of points in my reply to Peter's proposal.

You are focused on the fit, but any data treatment generating more than 
one "signal" makes desirable to be able to group them. PyMca and NexPy 
have no problem on visualizing anything, but plenty of developers 
complain about the fat they are "forced" to create a separated NXdata 
for each "signal" if they want the end user to inspect the data in a 
friendly way. The fit case is just so evident that should be enough to 
justify having that feature.

Other simple use case that I aim to have solved at the ESRF is to 
achieve the goal of providing the user with a simple way to browse the 
entries of an HDF5 file generated during the acquisition and presenting 
them what they had at acquisition time. As you know sometimes (even with 
SPEC) users are moving one motor and visualizing more than one counter 
together. Having multiple signals would allow the user to retrieve that 
information at the cost of a single click instead of selecting what they 
want as x axis and at least one click for each of the associated 
signals. The difference in user experience is incomparable. Users and 
scientists of our beamlines moving to HDF5 find tedious to have to 
interact so much.

To summarize with the SPEC analogy, in our view the default plot of an 
entry associated to a measurement should be able to visualize one of the 
plots the user was seeing when acquiring the data. If the user was 
watching multiple counters on a plot, that goal cannot be achieved with 
the current definition of NXdata and could be solved by implemented the 
requested feature. You have everything on NeXus to allow that 
(NXentry at default set to the default NXdata group) except the capability 
to have multiple signals.

> 
> Before we can make meaningful comments, you have to give an explicit
> example.

I said we would do it for the XRF fit case and that I expected to have 
for next week.

In the mean time please think about what the default NXdata plot 
associated to an entry should be when the user was simultaneously 
visualizing several counters at acquisition time.

> You keep on denying that you mean what both
> Ben and I have inferred you to mean, but until we see your example,
> it’s impossible to tell.

Sorry but I have to quote yourself and my answer that I thought it could 
not be clearer:

RAY: but I don't think it is necessary for NeXus to then specify all 
other possible non-default plots.

ARMANDO: Nobody is asking for it.

As I said, next week there will be the example for a fit output but to 
have multiple signals is desirable for more than just the fit: exactly 
the use case of the default plot.

Best regards,

Armando