[Nexus-developers] For multi dim axis discussion

[Ray Osborn]

HI Tobias,
I am concerned about such a major change being voted on before many of us have had a chance to digest it, even if it is backwardly compatible. I don't object in principle to the idea of putting axis information as group attributes - it won't work in HDF4, but I can't remember whether we have officially deprecated that anyway. 

Here are some concerns:

1) If you have multi-dimensional axes, aren't you basically saying the axes are the coordinates of the data points, rather than independent axes. If that is the case, we already have a scheme that we voted for in 2010 - again, I'm not sure of the official status, but the proposal was described in http://wiki.nexusformat.org/Proposal:_NeXus_Coordinates. That could be modified to transfer some of the attributes to group attributes, if that's what people want.

2) There are two statements criticizing the existing "axes" scheme that I disagree with.

a) does not allow for alternative axes
b) Also the @signal=1 attribute prevents the same data (e.g. from a temperature probe) to be used both as data in it's own right as well as as an axis for another dataset.

Firstly, there is nothing to stop you plotting anything against anything else. The axes attributes are only to give a generic plotting program ways of defining a default plot. It is true that it stops the signal data from different axes in different NXdata groups, although I have never come across a need to do that. 

Also, one advantage of the old scheme is that @signal could be set to 2, 3, etc, to allow alternative signals within an NXdata group, such as often are possible in spec scans. I don't think the new scheme would allow that since now the @signal is defined for the whole group.

3) I really don't understand:

@I_axes=Temperature,Wavelength,Pressure,Q,Q

This makes no sense to me, even with the 'indices' attributes. Again, if the Q's are coordinates, then this seems a confusing way of defining them as axes.
I confess I haven't had time to go through all the examples. Does one Q mean Q[0,:,0] (in Python notation) and the second Q[0,0,:]?

Also, why does the attribute have to have the 'I_'  prefix since there is only one signal defined by the @signal attribute. This could just be 'axes', couldn't it?

4) For one-dimensional axes, all the _indices attributes seem redundant. The information is already contained in @I_axes (which I think should just be 'axes'). For the two-dimensional axes, these would be better handled as coordinates, although it's true that wouldn't allow you to mix coordinates and axes, but then I wouldn't know how to plot that anyway.

I'm sorry I can't be at the meeting - I realize that some of these things may have been explained at the meeting, but this proposal is critical to NeXus, so I hope we'll have a chance to digest these things before a final decision is made.

Good luck with the rest of the meeting,
Ray
P.S. This is another reason why I regret canSAS going off on its own. We are now having to repeat debates in two separate organizations. 



On Sep 19, 2012, at 3:54 PM, <Tobias.Richter at diamond.ac.uk> <Tobias.Richter at diamond.ac.uk> wrote:

> Hi all,
> 
> This is in preparation for the discussions at the NIAC meeting tomorrow.
> Sorry for the lack of context for those not here.
> 
> Tobias
> 
> 
> -- 
> 
> 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
> 
> 
> 
> 
> 
> 
> 
> 
> 
> <02axes.pdf>_______________________________________________
> NeXus-developers mailing list
> NeXus-developers at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus-developers

-- 
Ray Osborn
Materials Science Division
Argonne National Laboratory
Argonne, IL 60439, USA
Phone: +1 (630) 252-9011
Email: ROsborn at anl.gov