[Nexus] Correct way to specify multiple signals

Fri Jan 12 17:04:28 GMT 2018

Hi Peter,
Just a quick comment about this, since it should probably be moved to another thread.

I agree with what you wrote. In fact, it is very similar to how we handle fits saved from an lmfit session, except that we currently put these in an NXsubentry. Putting them in an NXprocess would be an improvement.

You can see my example in the Github issue thread at https://github.com/nexusformat/NIAC/issues/25. I’m not sure if the “display” attributes are necessary, since any NXdata set is meant for plotting, but otherwise, I think this should become part of a separate proposal.

Ray

On Jan 12, 2018, at 3:18 AM, Peter.Chang at Diamond.ac.uk<mailto:Peter.Chang at Diamond.ac.uk> wrote:

Hi all,

Perhaps a better solution would be to have an attribute in a parent group. For presenting fitted results from some process:

my_fit:NXprocess/
  @display_data=["fit ", "data"]
  fit:NXdata/
  data:NXdata/
  fitting:NXnote/
  fit_parameters:NXparameters/

Regards,
Peter

-----Original Message-----
From: NeXus [mailto:nexus-bounces at shadow.nd.rl.ac.uk] On Behalf Of Jacob.Filik at Diamond.ac.uk<mailto:Jacob.Filik at Diamond.ac.uk>
Sent: 12 January 2018 08:56
To: nexus at shadow.nd.rl.ac.uk<mailto:nexus at shadow.nd.rl.ac.uk>
Subject: Re: [Nexus] Correct way to specify multiple signals

Dear Armando, All,

Thank you for the extra clarification, I will check with the others, but I believe this is functionality Diamond would be interested in.

I believe there is still merit in having discussion on the implementation.

As I see it:

Pete suggested auxiliary_signals which effectively gives back the signal =1, signal = 2 feature, I'm sure someone more experienced in NeXus can explain why this was not included in the 2014 tagging, I assume it was just simplicity.

To me the addition of auxiliary_axes is a new feature, which is convenient and useful, not all data on one plot needs the same axes, but thinking on this addition this now appears equivalent to making another NXdata inside the primary NXdata, but without any encapsulation and requiring new logic to correctly interpret an NXData group.

I would suggest instead of auxiliary_signals and auxiliary_axes NXdata groups should contain explicit NXdata groups for all the auxiliary datasets. We all have code that parses the NXdata structure, the addition if (nxdata contains nxdata) branch feels more simple that auxiliary_signal parsing.

I'm not sure but I think and NXdata in and NXdata is fine, so the only addition I would suggests this needs to the standard is to explicitly state "placing an NXdata inside another NXdata signifies they can be plotted on the same plot".

Kind regards,

Jake

-----Original Message-----
From: NeXus [mailto:nexus-bounces at shadow.nd.rl.ac.uk] On Behalf Of GOTZ Andrew
Sent: 12 January 2018 07:14
To: Discussion forum for the NeXus data format <nexus at shadow.nd.rl.ac.uk<mailto: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<mailto:NeXus at nexusformat.org>
http://lists.nexusformat.org/mailman/listinfo/nexus

_______________________________________________
NeXus mailing list
NeXus at nexusformat.org<mailto: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

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

--
Ray Osborn, Senior Scientist
Materials Science Division
Argonne National Laboratory
Argonne, IL 60439, USA
Phone: +1 (630) 252-9011
Email: ROsborn at anl.gov<mailto:ROsborn at anl.gov>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nexusformat.org/pipermail/nexus/attachments/20180112/27905f1b/attachment-0001.html>