[Nexus] Correct way to specify multiple signals

Fri Jan 12 10:13:14 GMT 2018

That does not allow the use case of the default entry plot with multiple
signals.

Armando

On 12/01/2018 10:18, 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
> Sent: 12 January 2018 08:56
> To: 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>
> 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
>
> _______________________________________________
> 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