[Nexus] Nexpy

[steve.collins at diamond.ac.uk]

Great – thanks People,
I’ve tried to follow the thread…
I understand that (a) my nxs file is valid and (b) the new version of nexusformat will solve the problem.
Cheers!
Steve

From: NeXus [mailto:nexus-bounces at nexusformat.org] On Behalf Of Osborn, Raymond
Sent: 15 June 2017 13:25
To: V. Armando Solé <sole at esrf.fr>
Cc: Mita, Charles (DLSLtd,RAL,LSCI) <charles.mita at diamond.ac.uk>; Discussion forum for the NeXus data format <nexus at nexusformat.org>; Sharpe, Chris (DLSLtd,RAL,LSCI) <chris.sharpe at diamond.ac.uk>
Subject: Re: [Nexus] Nexpy

Thanks, Armando,
That is exactly the aim of the nexusformat package - to give scientists a convenient and, hopefully, reliable tool for reading and writing NeXus files that just works. Speaking as a scientist, we don’t want to worry about whether they should be using variable-length strings or byte arrays - we just want to have variables we can manipulate in Python and store in our data files when required. We don’t want to worry about whether we have obeyed the standard, but would be delighted if the program sorted that out for us. That is what nexusformat tries to do, and NeXpy adds other conveniences, like showing visually what items are linked in a file tree.

Those who spend a lot of time developing software, on the other hand, are welcome to do their own thing. If you are happy writing your own read/write modules using, e.g., h5py, then that’s fine. But please don’t expect scientists to have to learn h5py, then study all the NeXus rules for writing NXdata groups (not forgetting to add an ’NX_class’ attribute, a signal attribute, axes, …), and then worry about whether they should be using byte arrays or strings.

This is a philosophical issue that I have brought up many times at NIAC meetings. The original goal of NeXus was to be a convenience tool for scientists, but it is now largely maintained by developers who are willing to read manuals. I was a little reluctant about deprecating the NAPI for this reason, but it started to become a barrier to using the more advanced features of HDF5 and few scientists write in C anyway. Python is different - scientists will use it if we give them the right modules - I have a student with little programming experience who writes standard-conforming NeXus files every day. My suggestion that more people use the nexusformat package, rather than just h5py, is that, as this thread shows, it is helpful to have a wide range of people helping to debug it so that it doesn’t trip scientists up when they do use it.

With best regards,
Ray

On Jun 15, 2017, at 3:21 AM, V. Armando Solé <sole at esrf.fr<mailto:sole at esrf.fr>> wrote:

Hello,

On 15/06/2017 09:17, Carlos Pascual wrote:

And, on the other hand, if the NIAC does bless nexusformat as the preferred
access method for python, I think it should be stated unambiguously in the
manual.

Well, at the ESRF Python programmers are using h5py.

However we recommend scientists to use nexusformat as a simpler tool
because they often work with interactive sessions.
As you see our point of view is that nexusformat is just a convenience
tool on top of h5py being the later the standard (Python) tool to access
HDF5 files.

What we do not recommend at all is to use the NeXus library from Python
(or from anywhere else).

The use of NAPI was unambiguously discouraged by the NIAC in past NIAC
meetings in favour of standard tools. However I never understood why
trainings were kept going on around an API that was considered obsolete.

Best,

Armando

--
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>


-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nexusformat.org/pipermail/nexus/attachments/20170615/99ea3813/attachment-0001.html>