[Nexus-developers] For multi dim axis discussion

Thu Sep 20 08:19:32 BST 2012

On Sep 20, 2012, at 8:41 AM, <Tobias.Richter at diamond.ac.uk> <Tobias.Richter at diamond.ac.uk> wrote:

> Hi Ray,
> 
> Thanks for your comments. I think we should not pre-empt the technical discussion we'll be having at the NIAC here, but we'll make sure and go through your points. We'll summarise and get that across to you either here or in the minutes.
> 
> However I believe we cannot blame communities if they come up with solutions for what they think their problems are. (Your P.S. comment.)

Hi Tobias,
I have no objection to the SAS community discussing these things, but if you look at canSAS, nearly everything is a copy of the NeXus standard, with a few minor modifications here and there. I believe it would have been more productive if they had  tabled proposals for their ideas to be incorporated into the NeXus standard. That's what you have done here, which I applaud, but if we modify your suggestion, then we have made the two standards diverge even more, unless canSAS is prepared to listen to our suggestions.

> I presented a less refined proposal for this axis business at the last code camp and failed to get anyone interested in developing it further. Prior to that we had some mostly fruitless discussions on the mailing list and through the trac tickets (opened 19 months ago, milestone set to "later" almost immediately). 

Sorry I didn't know about the axis discussion. 

> If a community say: "We would really like to use NeXus, but we cannot do X. Here is our proposal how to do X." That is a good thing. They found something, they invested time, so they're obviously interested. We should engage. Shooting their proposal down with the "not invented here" argument adds to the frustration people have with NeXus.

I agree entirely with that statement, but they didn't present a proposal to us. They established a separate standard. Now, we have two separate communities instead of one that can come up with joint solutions. My criticisms of the proposal may not be valid - I may not understand all the issues - but my question is, is this a reciprocal discussion? Are canSAS prepared to accept modifications from us - do we have to have a high-level summit to iron out differences - or do they also adopt the "not invented here" attitude?

> Sorry if that sounds a bit harsh, you may not have intended to come across that way. But for the people out there the message must be that we do welcome input from individuals and communities alike.

I want as many people as possible to become engaged with the NeXus community, but what has happened more than once is that some people have read the standard, decided it doesn't do exactly what they want although they like many of the ideas, and then, instead of engaging with the NeXus community, have copied the bits they like (SASroot, SASentry, SASdata ...) and invented their own standard. That is what I objected to - it defeats the whole point of having a unified standard.

As you can see, this has touched a nerve, and it's mostly past history now. If the new proposal solves a key problem, then I won't oppose it, but please make sure it doesn't duplicate what is in the coordinates proposal. Perhaps the NIAC discussions can be summarized some time. 

With best regards,
Ray

> 
> From: Ray Osborn [ROsborn at anl.gov]
> Sent: 20 September 2012 06:38
> To: Discussion forum for the NeXus API and other programming issues
> Cc: Richter, Tobias (DLSLtd,RAL,DIA)
> Subject: Re: [Nexus-developers] For multi dim axis discussion
> 
> 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
> 
> 
> 
> 
> --
> 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
> 
> 
> 
> 

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