[Nexus] NeXus update

[V. Armando Sole]

On 21.01.2015 17:48, Osborn, Raymond wrote:
> On Jan 7, 2015, at 3:45 AM, V. Armando Solé <sole at esrf.fr> wrote:
> 
>> I think you should take into consideration the advice of people 
>> actually writing data visualization software (Ray, myself and even 
>> Eugen was thinking about whether the generic solution specifying 
>> points would not be the best).
>> 
>> I doubt I will ever add support to the new indices stuff. I can 
>> default to the current situation where the user can specify what he 
>> actually want to visualize.
> 
> Armando,
> Sorry I didn’t reply at the time you wrote, but I think that your
> comment about not supporting the new indices stuff is critically
> important to the reasons behind my own objections. Adding this support
> to NeXpy will require me to divert my time from other things. I don’t
> object to changes per se, but it’s frustrating when the change is for
> something that is not needed 99% of the time. Currently, it is low on
> my priority list because I have many other things to do first.
> 

Yep. It's the same with me.

One thing is to specify a *simple* default plot and other one to ask 
every code to be able to generate the actual axes because the actual 
data are not there.

For multidimensional visualization software it is much simpler to get 
the x and y (and eventually z) coordinates at which something was 
measured and needs to be plotted than to get a reduced amount x, y (and 
eventually z) values from which to generate all the coordinates. In one 
case you need a visualization software. In the other you need a "NeXus 
interpreter" plus a visualization software.

If one makes a n_points two dimensional scan, with a motor for the x 
positions and a motor for the y positions, the simplest is to save 
n_points values for the x positions and n_points values for the y 
position with shape (npoints,). To store x and y as (n_rows, ncolumns) 
with the product n_rows * n_columns equal to n_points is *not* 
convenient. The same applies to storing x as (n_rows) and y as 
(n_columns). Why? Because not only due to visualization issues. The data 
will be taken sequentially, if the user interrupts the scan *because of 
any reason*, one can end up with a non regular grid. The solution with 
shapes (npoints,) for the motors and (n_points, 
whatever_dimensions_needed_for_the_measured_data) will *always* be 
possible to visualize.

So, either one specifies *simple* cases in NXdata (and for that the 
interpretation attribute helps a lot) or one writes the data properly to 
make the (very few) complex cases for which you would need the new 
indices simple. Basically one wants coordinates at which something has 
to be plotted. That something can be a set of scalars, of spectra, of 
images, of whatever and for that we have the interpretation attribute. I 
do not think that is difficult to understand or to interpret.

Armando