[Nexus] Correct way to specify multiple signals

[Benjamin Watts]

I agree here that the core goal of NeXus is the coherent *storage* of 
data. NXdata was defined in order to allow a quick view of the data in 
order to aid in sorting files. If we extend NeXus to describe views of 
the data then we will certainly have problems with the infinite number 
of possible plots that people could want to describe. Line plots with 
multiple lines is a fairly simple case that can be well defined rather 
simply, so an NXplot1d could make sense to at least experiment with, but 
I would oppose making NXdata more complicated by burdening it with this 
extra function. The core need that I see from Armando is a way for 
analysis programs to store their plotting outputs in the NeXus files, 
rather than the experiment control system describing the ways the raw 
data can be viewed.

Therefore, I would support an NXplot that specifically describes a view 
of data (raw or processed). In order to see how much work is needed to 
provide the flexibility "everybody" is going to want, just look at the 
list of options in any plotting software (Excel, Matlab, Matplotlib, 
Origin, etc.) and you will see that it is extensive. Perhaps a good way 
forward is to write an NXplot definition by copying all of the options 
provided by the various plotting packages. They all tend to provide very 
similar options to each other, so it should be possible to provide 
descriptions of 99% of the plots that people commonly make. Then we will 
at least have something concrete to base further discussion on.

Cheers,
Ben


On 11/01/18 15:56, Jacob.Filik at Diamond.ac.uk wrote:
>
> Another suggestion might just be to put any extra auxiliary NXdata 
> inside the raw NXdata.
>
> I fear this conversion is going into dangerous/interesting territory. 
> Software packages usually have an associated file format, which is 
> strongly linked to the application and its data model.
>
> Is it the job of Nexus to allow NeXpy/DAWN/Mantis/Mantid… to be able 
> open a processed file from pyMCA of raw data, say collected at 
> Diamond, and display it in a the “richest” way it can? Where richest 
> is a function of how deeply the application developer has implemented 
> reading the standard?
>
> I can understand that it may not be the job of Nexus to provide a 
> complete application data model for all experiments and all 
> applications ever, but wanting an application to be able to plot 2 
> related datasets at the same time seems like it shouldn’t be out the 
> scope (but also should not break applications using a more simple 
> Nexus structure).
>
> Anyway, just my point of view.
>
> Jake
>
> *From:*NeXus [mailto:nexus-bounces at shadow.nd.rl.ac.uk] *On Behalf Of 
> *V. Armando Solé
> *Sent:* 11 January 2018 14:40
> *To:* nexus at nexusformat.org
> *Subject:* Re: [Nexus] Correct way to specify multiple signals
>
> On 11/01/2018 15:36, Osborn, Raymond wrote:
>
>     I saw the Github issue and responded before I realized there was
>     already a lengthy correspondence here. I will have to read more
>     carefully what has already been contributed here, but I wanted to
>     quickly summarize what I wrote there
>     (https://github.com/nexusformat/NIAC/issues/25):
>
>     “In my view, it is the role of the NeXus standard to provide a way
>     to offer a default plot for each NXdata group, but I don't think
>     it is necessary for NeXus to then specify all other possible
>     non-default plots. Any program is free to provide that option
>     within the current standard as NeXpy does.”
>
>     Please see the issue for my reasoning - basically, you can do what
>     Armando requests, i.e., plot multiple signals, now without adding
>     extra complexity to the standard.
>
>
> The goal is not to foresee any possible plot. It is to provide a 
> default plot. I post the answer I sent to github here too:
>
> On 11/01/2018 15:04, Ray Osborn wrote:
>
>     To summarize - in my view, it is the role of the NeXus standard to
>
>     provide a way to offer a default plot for each NXdata group,
>
> Exact, but to me the default plot for a fit is the raw_data, the used
> uncertainties and the fitted curve.
> NeXus provides everything for it except the possibility to put the
> auxiliary curve.
>
>     but I don't think it is necessary for NeXus to then specify all other
>
>     possible non-default plots.
>
> Nobody is asking for it.
>
>     Any program is free to provide that option within the current standard
>
>     as NeXpy does.
>
> PyMca does it too, so that is not the problem. However, consider the
> marvellous opportunity NeXus offers to provide the output of a fit (or
> other treatments), with uncertainties, axis labels, and fitted curve at
> the cost of defining two group attributes.
> If NIAC tells me that Peter Chang's solution is not going to be
> considered at all, it is fine with me too. We'll implement those two
> attributes at our side and they will not conflict with any other
> implementation.
>
> -- 
>
> This e-mail and any attachments may contain confidential, copyright 
> and or privileged material, and are for the use of the intended 
> addressee only. If you are not the intended addressee or an authorised 
> recipient of the addressee please notify us of receipt by returning 
> the e-mail and do not use, copy, retain, distribute or disclose the 
> information in or attached to the e-mail.
> Any opinions expressed within this e-mail are those of the individual 
> and not necessarily of Diamond Light Source Ltd.
> Diamond Light Source Ltd. cannot guarantee that this e-mail or any 
> attachments are free from viruses and we cannot accept liability for 
> any damage which you may sustain as a result of software viruses which 
> may be transmitted in or with the message.
> Diamond Light Source Limited (company no. 4375679). Registered in 
> England and Wales with its registered office at Diamond House, Harwell 
> Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United 
> Kingdom
>
>
>
> _______________________________________________
> 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/20180111/22a93aa0/attachment-0001.html>