[Nexus] Correct way to specify multiple signals

[Jemian, Pete R.]

Clear to me, too - directly on topic for one of the three NeXus motivations: simple plotting




Sent from a device with a dreadfully small screen


-------- Original message --------
From: GOTZ Andrew <andy.gotz at esrf.fr>
Date: 1/12/18 1:15 AM (GMT-06:00)
To: Discussion forum for the NeXus data format <nexus at shadow.nd.rl.ac.uk>
Subject: Re: [Nexus] Correct way to specify multiple signals

Armando,

thank you for your patience - your explainations are clear to me! It is
a pity the Nexus community do not understand them

Andy


On 12/01/2018 06:54, V. Armando Sole wrote:
> 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
> _______________________________________________
> NeXus mailing list
> NeXus at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus

_______________________________________________
NeXus mailing list
NeXus at nexusformat.org
http://lists.nexusformat.org/mailman/listinfo/nexus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nexusformat.org/pipermail/nexus/attachments/20180112/5a8aef62/attachment.html>