[Nexus] Correct way to specify multiple signals

Pete Jemian jemian at anl.gov
Fri Jan 12 16:34:24 GMT 2018


I'm thinking XRF is a classic case of multiple 2-D charts.  Not 
displayed on top of each other, that's a mess.  A grid of 2-D charts 
each for a different fluorescence wavelength.

On 1/12/2018 8:53 AM, Osborn, Raymond wrote:
> I know I’m being cast as an obstructionist Luddite in this thread, who 
> isn’t able to understand the obvious, but it comes from experience that 
> we make bad decisions when we don’t think through the implications. I am 
> perfectly capable of understanding the desire for multiple signals, but 
> we need to experiment with a number of practical examples before we 
> understand what the consequences of this decision are.
> 
> Here’s one that needs clarification. In Pete Jemian’s SPEC importer, he 
> converts meshes into 2D data, producing an NXdata like this:
> 
> data:NXdata
>   @axes = [‘K’ ‘H']
>   @signal = ‘NaI'
>   @auxiliary = [‘detector’ ‘ic0’ ‘ic1’ ‘ic2’ ic3’]
>   @auxiliary_axes = [[‘K’ ‘H’] [‘K’ ‘H’] [‘K’ ‘H’] [‘K’ ‘H’] [‘K’ ‘H’]]
>   Epoch = float64(16x16)
>   H = float64(16)
>   K = float64(16)
>   L = float64(16x16)
>   NaI = float64(16x16)
>   Ring = float64(16x16)
>   Seconds = float64(16x16)
>   detector = float64(16x16)
>   ic0 = float64(16x16)
>   ic1 = float64(16x16)
>   ic2 = float64(16x16)
>   ic3 = float64(16x16)
> 
> As you can see, I added attributes following what I believe is one of 
> the suggestions for allowing extra signals. Since the data is 2-D, the 
> axes are size-2 arrays, so each auxiliary axis also has to be an array 
> of size-2 arrays matching the axes. (By the way, the latest version of 
> the standard requires extra attributes of the form ‘Two_Theta_indices’ 
> stating what dimension they refer to - it’s not an aspect of the 
> standard that I support, but it would make the above example much more 
> complicated).
> 
> Note that, without the auxiliary attributes, the above is a 
> NeXus-conforming data set, so it already contains multiple signals and 
> multiple axes.
> 
> OK - I think everyone is thinking of 1-D arrays, because it’s difficult 
> to overplot 2-D arrays, but 1D arrays have their difficulties as well.
> 
> data:NXdata
>   @axes = 'Two_Theta'
>   @signal = 'NaI'
>   @auxiliary = [‘detector’ ‘ic0’ ‘ic1’ ‘ic2’ ic3’]
>   @auxiliary_axes = [’Seconds’, ‘Epoch’, ‘Epoch’, ’Two_Theta']
>   Epoch = float64(26)
>   H = float64(26)
>   K = float64(26)
>   L = float64(26)
>   NaI = float64(26)
>   Ring = float64(26)
>   Seconds = float64(26)
>   Two_Theta = float64(26)
>   detector = float64(26)
>   ic0 = float64(26)
>   ic1 = float64(26)
>   ic2 = float64(26)
>   ic3 = float64(26)
> 
> Here I have made an arbitrary choice of which x-axis to plot against 
> which y-axis, but what is a generic NeXus program, like NeXpy, meant to 
> do here? Is it meant to provide an option to plot every possible signal 
> against its axis on the same plot, resulting in six different y-axes and 
> four different x-axes, all of which might need to be arbitrarily scaled 
> against each other (or do we provide the scaling as well?). That is not 
> trivial to do in Matplotlib.
> 
> My point is that I can see why people want multiple signals, but it may 
> be difficult to define them in a way that would allow be unambiguously 
> parsed in the way that a standard demands. I’m not saying it is 
> impossible, but if we are to extend the standard, these need to be 
> thought through.
> 
> Remember that, on your beamlines, there is nothing to stop you adding 
> menu items to your applications that will overplot specific signals that 
> are typically plotted together.
> 
> In the last day, I have provided four different explicit examples to 
> show why this might be complicated.  I am extremely willing to be 
> convinced if you provide your own examples that show why this should be 
> a part of the standard.
> 
> Ray
> 
>> On Jan 12, 2018, at 1:14 AM, GOTZ Andrew <andy.gotz at esrf.fr 
>> <mailto:andy.gotz at esrf.fr>> wrote:
>>
>> 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
> 
> 
> 
> -- 
> 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>
> 
> 
> 
> _______________________________________________
> NeXus mailing list
> NeXus at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus
> 

-- 
----------------------------------------------------------
Pete R. Jemian, Ph.D.                <jemian at anl.gov>
Beam line Controls and Data Acquisition, Group Leader
Advanced Photon Source,   Argonne National Laboratory
Argonne, IL  60439                   630 - 252 - 3189
-----------------------------------------------------------
    Education is the one thing for which people
       are willing to pay yet not receive.
-----------------------------------------------------------




More information about the NeXus mailing list