[Nexus] Correct way to specify multiple signals

[GOTZ Andrew]

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