From dyadkin at lns.pnpi.spb.ru  Sat Jan 21 22:04:34 2012
From: dyadkin at lns.pnpi.spb.ru (Vadim Dyadkin)
Date: Sun, 22 Jan 2012 02:04:34 +0400
Subject: [Nexus-developers] bug (?) in nexus-4.2.1
Message-ID: <1516830.TuphLk4Dyb@kato>

Dear developers

Since the registration is closed, I write this letter.

I have started to sort out the nexus format and I have got a strange behavior 
of this python example: 
http://download.nexusformat.org/doc/html/Examples.html#Examples.NAPI
It produces this xml:

<?xml version="1.0" encoding="UTF-8"?>
  <NXroot NeXus_version="4.2.1" XML_version="mxml"
file_name="next.nxs.xml"
xmlns="http://definition.nexusformat.org/schema/3.1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://definition.nexusformat.org/schema/3.1
http://definition.nexusformat.org/schema/3.1/BASE.xsd"
file_time="2012-01-21T01:37:29+04:00">
    <NXentry name="entry">
      <NXdata name="data">
        <test NAPItype="NX_INT64[2,3,4]"
signal="-99999999999999997748809823456034029568.000000">
                                 0                        1 
                                 2                        3 
                                 4                        5 
                                 6                        7 
                                 8                        9 
                                10                       11 
                                12                       13 
                                14                       15 
                                16                       17 
                                18                       19 
                                20                       21 
                                22                       23 
        </test>
      </NXdata>
    </NXentry>
  </NXroot>

Look at the signal attribute of the test field, it is a pure overflow. I am 
not sure whether this is an error or I have done something wrong. I could not 
test your trunk since the svn is only for the registered users. I use x86-64 
linux-3.2.1, python-2.7.2, numpy-1.6.1, mini-xml-2.6, gcc-4.5.3

Best regards,
Vadim

From ROsborn at anl.gov  Mon Jan 23 14:31:39 2012
From: ROsborn at anl.gov (Ray Osborn)
Date: Mon, 23 Jan 2012 08:31:39 -0600
Subject: [Nexus-developers] bug (?) in nexus-4.2.1
In-Reply-To: <1516830.TuphLk4Dyb@kato>
References: <1516830.TuphLk4Dyb@kato>
Message-ID: <E8E4275F-AC43-45F3-9068-5505CBE1BEEE@anl.gov>

The problem can be fixed by changing the attribute call to 

>>> nf.putattr("signal",1, dtype='int32')

i.e, by casting the integer attribute as 32-bit. You are using a 64-bit version of python, but a 32-bit version of the API. 

There is a 64-bit version of the Python NeXus API that I think will be included in the next release, although I can't say for sure if this bug will be fixed by it. I am still using the older version with 64-bit Python, but the problem only seems to affect XML output.

Ray

On Jan 21, 2012, at 4:04 PM, Vadim Dyadkin wrote:

> Dear developers
> 
> Since the registration is closed, I write this letter.
> 
> I have started to sort out the nexus format and I have got a strange behavior 
> of this python example: 
> http://download.nexusformat.org/doc/html/Examples.html#Examples.NAPI
> It produces this xml:
> 
> <?xml version="1.0" encoding="UTF-8"?>
>  <NXroot NeXus_version="4.2.1" XML_version="mxml"
> file_name="next.nxs.xml"
> xmlns="http://definition.nexusformat.org/schema/3.1"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://definition.nexusformat.org/schema/3.1
> http://definition.nexusformat.org/schema/3.1/BASE.xsd"
> file_time="2012-01-21T01:37:29+04:00">
>    <NXentry name="entry">
>      <NXdata name="data">
>        <test NAPItype="NX_INT64[2,3,4]"
> signal="-99999999999999997748809823456034029568.000000">
>                                 0                        1 
>                                 2                        3 
>                                 4                        5 
>                                 6                        7 
>                                 8                        9 
>                                10                       11 
>                                12                       13 
>                                14                       15 
>                                16                       17 
>                                18                       19 
>                                20                       21 
>                                22                       23 
>        </test>
>      </NXdata>
>    </NXentry>
>  </NXroot>
> 
> Look at the signal attribute of the test field, it is a pure overflow. I am 
> not sure whether this is an error or I have done something wrong. I could not 
> test your trunk since the svn is only for the registered users. I use x86-64 
> linux-3.2.1, python-2.7.2, numpy-1.6.1, mini-xml-2.6, gcc-4.5.3
> 
> Best regards,
> Vadim
> _______________________________________________
> 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





From mark.koennecke at psi.ch  Wed Feb  8 10:04:49 2012
From: mark.koennecke at psi.ch (Mark Koennecke)
Date: Wed, 8 Feb 2012 11:04:49 +0100
Subject: [Nexus-developers] NeXusTelco
Message-ID: <8A5A3781-B32C-423E-B0BE-169AA2177AF5@psi.ch>

Please join me in an Adobe Connect Meeting.

Meeting Name:  NeXusTelco
Summary: 
Invited By: Mark Koennecke (mark.koennecke at psi.ch)
When:  02/08/2012 2:30 PM - 3:30 PM
Time Zone:  (GMT+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna



To join the meeting:
https://collab.switch.ch/nexus/



----------------
If you have never attended an Adobe Connect meeting before:

Test your connection: https://collab.switch.ch/common/help/en/support/meeting_test.htm

Get a quick overview: http://www.adobe.com/go/connectpro_overview

Adobe, the Adobe logo, Acrobat and Adobe Connect are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries.

From eugen.wintersberger at desy.de  Wed Feb  8 12:40:13 2012
From: eugen.wintersberger at desy.de (Eugen Wintersberger)
Date: Wed, 08 Feb 2012 13:40:13 +0100
Subject: [Nexus-developers] NeXusTelco
In-Reply-To: <8A5A3781-B32C-423E-B0BE-169AA2177AF5@psi.ch>
References: <8A5A3781-B32C-423E-B0BE-169AA2177AF5@psi.ch>
Message-ID: <1328704813.22706.13.camel@haso228w>

I have just checked the meeting_test.htm it seems that I cannot connect
to the meeting place. I am not sure if there are some ports filtered by
our DESY-wide firewall (does the software require some special ports for
communication?). 
Besides, I have seen that there is some add-in required (for the
browser?). Does anyone know if this is available for Linux (64Bit) too?

regards
  Eugen


On Wed, 2012-02-08 at 11:04 +0100, Mark Koennecke wrote: 
> Please join me in an Adobe Connect Meeting.
> 
> Meeting Name:  NeXusTelco
> Summary: 
> Invited By: Mark Koennecke (mark.koennecke at psi.ch)
> When:  02/08/2012 2:30 PM - 3:30 PM
> Time Zone:  (GMT+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna
> 
> 
> 
> To join the meeting:
> https://collab.switch.ch/nexus/
> 
> 
> 
> ----------------
> If you have never attended an Adobe Connect meeting before:
> 
> Test your connection: https://collab.switch.ch/common/help/en/support/meeting_test.htm
> 
> Get a quick overview: http://www.adobe.com/go/connectpro_overview
> 
> Adobe, the Adobe logo, Acrobat and Adobe Connect are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries.
> _______________________________________________
> NeXus-developers mailing list
> NeXus-developers at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus-developers



From mark.koennecke at psi.ch  Wed Feb  8 12:49:44 2012
From: mark.koennecke at psi.ch (Mark Koennecke)
Date: Wed, 8 Feb 2012 13:49:44 +0100
Subject: [Nexus-developers] NeXusTelco
In-Reply-To: <1328704813.22706.13.camel@haso228w>
References: <8A5A3781-B32C-423E-B0BE-169AA2177AF5@psi.ch>
 <1328704813.22706.13.camel@haso228w>
Message-ID: <2DB54342-054F-4804-A4C6-D4CB1E199C10@psi.ch>

Eugen,

it may be that the meeting is not yet open. It is a tad early. As fas as I know you need a WWW-browser with
flash support.

Cheers,

    Mark

On Feb 8, 2012, at 1:40 PM, Eugen Wintersberger wrote:

> I have just checked the meeting_test.htm it seems that I cannot connect
> to the meeting place. I am not sure if there are some ports filtered by
> our DESY-wide firewall (does the software require some special ports for
> communication?). 
> Besides, I have seen that there is some add-in required (for the
> browser?). Does anyone know if this is available for Linux (64Bit) too?
> 
> regards
>  Eugen
> 
> 
> On Wed, 2012-02-08 at 11:04 +0100, Mark Koennecke wrote: 
>> Please join me in an Adobe Connect Meeting.
>> 
>> Meeting Name:  NeXusTelco
>> Summary: 
>> Invited By: Mark Koennecke (mark.koennecke at psi.ch)
>> When:  02/08/2012 2:30 PM - 3:30 PM
>> Time Zone:  (GMT+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna
>> 
>> 
>> 
>> To join the meeting:
>> https://collab.switch.ch/nexus/
>> 
>> 
>> 
>> ----------------
>> If you have never attended an Adobe Connect meeting before:
>> 
>> Test your connection: https://collab.switch.ch/common/help/en/support/meeting_test.htm
>> 
>> Get a quick overview: http://www.adobe.com/go/connectpro_overview
>> 
>> Adobe, the Adobe logo, Acrobat and Adobe Connect are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries.
>> _______________________________________________
>> NeXus-developers mailing list
>> NeXus-developers at nexusformat.org
>> http://lists.nexusformat.org/mailman/listinfo/nexus-developers
> 
> 
> _______________________________________________
> NeXus-developers mailing list
> NeXus-developers at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus-developers



From eugen.wintersberger at desy.de  Wed Feb  8 12:55:19 2012
From: eugen.wintersberger at desy.de (Eugen Wintersberger)
Date: Wed, 08 Feb 2012 13:55:19 +0100
Subject: [Nexus-developers] NeXusTelco
In-Reply-To: <2DB54342-054F-4804-A4C6-D4CB1E199C10@psi.ch>
References: <8A5A3781-B32C-423E-B0BE-169AA2177AF5@psi.ch>
 <1328704813.22706.13.camel@haso228w>
 <2DB54342-054F-4804-A4C6-D4CB1E199C10@psi.ch>
Message-ID: <1328705719.22706.14.camel@haso228w>

Ok - I will try later. 


On Wed, 2012-02-08 at 13:49 +0100, Mark Koennecke wrote: 
> Eugen,
> 
> it may be that the meeting is not yet open. It is a tad early. As fas as I know you need a WWW-browser with
> flash support.
> 
> Cheers,
> 
>     Mark
> 
> On Feb 8, 2012, at 1:40 PM, Eugen Wintersberger wrote:
> 
> > I have just checked the meeting_test.htm it seems that I cannot connect
> > to the meeting place. I am not sure if there are some ports filtered by
> > our DESY-wide firewall (does the software require some special ports for
> > communication?). 
> > Besides, I have seen that there is some add-in required (for the
> > browser?). Does anyone know if this is available for Linux (64Bit) too?
> > 
> > regards
> >  Eugen
> > 
> > 
> > On Wed, 2012-02-08 at 11:04 +0100, Mark Koennecke wrote: 
> >> Please join me in an Adobe Connect Meeting.
> >> 
> >> Meeting Name:  NeXusTelco
> >> Summary: 
> >> Invited By: Mark Koennecke (mark.koennecke at psi.ch)
> >> When:  02/08/2012 2:30 PM - 3:30 PM
> >> Time Zone:  (GMT+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna
> >> 
> >> 
> >> 
> >> To join the meeting:
> >> https://collab.switch.ch/nexus/
> >> 
> >> 
> >> 
> >> ----------------
> >> If you have never attended an Adobe Connect meeting before:
> >> 
> >> Test your connection: https://collab.switch.ch/common/help/en/support/meeting_test.htm
> >> 
> >> Get a quick overview: http://www.adobe.com/go/connectpro_overview
> >> 
> >> Adobe, the Adobe logo, Acrobat and Adobe Connect are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries.
> >> _______________________________________________
> >> NeXus-developers mailing list
> >> NeXus-developers at nexusformat.org
> >> http://lists.nexusformat.org/mailman/listinfo/nexus-developers
> > 
> > 
> > _______________________________________________
> > NeXus-developers mailing list
> > NeXus-developers at nexusformat.org
> > http://lists.nexusformat.org/mailman/listinfo/nexus-developers
> 
> 
> _______________________________________________
> NeXus-developers mailing list
> NeXus-developers at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus-developers



From eugen.wintersberger at desy.de  Wed Feb  8 13:29:06 2012
From: eugen.wintersberger at desy.de (Eugen Wintersberger)
Date: Wed, 08 Feb 2012 14:29:06 +0100
Subject: [Nexus-developers] NeXusTelco
In-Reply-To: <8A5A3781-B32C-423E-B0BE-169AA2177AF5@psi.ch>
References: <8A5A3781-B32C-423E-B0BE-169AA2177AF5@psi.ch>
Message-ID: <1328707746.22706.15.camel@haso228w>

Does not see that this works for me. The system simply refuses to
establish a connection ;). Any ideas?

regards 
Eugen

On Wed, 2012-02-08 at 11:04 +0100, Mark Koennecke wrote: 
> Please join me in an Adobe Connect Meeting.
> 
> Meeting Name:  NeXusTelco
> Summary: 
> Invited By: Mark Koennecke (mark.koennecke at psi.ch)
> When:  02/08/2012 2:30 PM - 3:30 PM
> Time Zone:  (GMT+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna
> 
> 
> 
> To join the meeting:
> https://collab.switch.ch/nexus/
> 
> 
> 
> ----------------
> If you have never attended an Adobe Connect meeting before:
> 
> Test your connection: https://collab.switch.ch/common/help/en/support/meeting_test.htm
> 
> Get a quick overview: http://www.adobe.com/go/connectpro_overview
> 
> Adobe, the Adobe logo, Acrobat and Adobe Connect are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries.
> _______________________________________________
> NeXus-developers mailing list
> NeXus-developers at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus-developers



From Tobias.Richter at diamond.ac.uk  Wed Feb  8 13:46:25 2012
From: Tobias.Richter at diamond.ac.uk (Tobias.Richter at diamond.ac.uk)
Date: Wed, 8 Feb 2012 13:46:25 +0000
Subject: [Nexus-developers] NeXusTelco
In-Reply-To: <1328707746.22706.15.camel@haso228w>
References: <8A5A3781-B32C-423E-B0BE-169AA2177AF5@psi.ch>,
 <1328707746.22706.15.camel@haso228w>
Message-ID: <4669C175DBA03A4981471A4B07FEC3740F7ECEE7@EXCHMBX03.fed.cclrc.ac.uk>

Does not work for us either.

Tobias
________________________________________
From: nexus-developers-bounces at nexusformat.org [nexus-developers-bounces at nexusformat.org] on behalf of Eugen Wintersberger [eugen.wintersberger at desy.de]
Sent: 08 February 2012 13:29
To: nexus-developers at nexusformat.org
Subject: Re: [Nexus-developers] NeXusTelco

Does not see that this works for me. The system simply refuses to
establish a connection ;). Any ideas?

regards
Eugen

On Wed, 2012-02-08 at 11:04 +0100, Mark Koennecke wrote:
> Please join me in an Adobe Connect Meeting.
>
> Meeting Name:  NeXusTelco
> Summary:
> Invited By: Mark Koennecke (mark.koennecke at psi.ch)
> When:  02/08/2012 2:30 PM - 3:30 PM
> Time Zone:  (GMT+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna
>
>
>
> To join the meeting:
> https://collab.switch.ch/nexus/
>
>
>
> ----------------
> If you have never attended an Adobe Connect meeting before:
>
> Test your connection: https://collab.switch.ch/common/help/en/support/meeting_test.htm
>
> Get a quick overview: http://www.adobe.com/go/connectpro_overview
>
> Adobe, the Adobe logo, Acrobat and Adobe Connect are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries.
> _______________________________________________
> NeXus-developers mailing list
> NeXus-developers at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus-developers


_______________________________________________
NeXus-developers mailing list
NeXus-developers at nexusformat.org
http://lists.nexusformat.org/mailman/listinfo/nexus-developers

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





From zikovskyjl at ornl.gov  Wed Feb 15 19:02:51 2012
From: zikovskyjl at ornl.gov (Zikovsky, Janik L.)
Date: Wed, 15 Feb 2012 14:02:51 -0500
Subject: [Nexus-developers] Thread-safety of HDF5, NeXus
Message-ID: <5C691E518F345F4882FAB9E9839E60BA146207AF9B@EXCHMB.ornl.gov>

Hello,

I just found out that the usual binaries of HDF5 are NOT thread-safe even when accessing DIFFERENT files from separate threads in the same process. However, the HDF libraries CAN be built in a thread-safe way:
http://www.hdfgroup.uiuc.edu/papers/features/mthdf/index.html

My question is: does NeXus use the thread-safe version of HDF5 (I suspect no)? And if not, can it?

Thanks!

Janik Zikovsky
Scientific Data Analysis Group, Spallation Neutron Source


From freddie.akeroyd at stfc.ac.uk  Wed Feb 15 19:31:04 2012
From: freddie.akeroyd at stfc.ac.uk (freddie.akeroyd at stfc.ac.uk)
Date: Wed, 15 Feb 2012 19:31:04 +0000
Subject: [Nexus-developers] Thread-safety of HDF5, NeXus
In-Reply-To: <5C691E518F345F4882FAB9E9839E60BA146207AF9B@EXCHMB.ornl.gov>
References: <5C691E518F345F4882FAB9E9839E60BA146207AF9B@EXCHMB.ornl.gov>
Message-ID: <8CB55BA9D873DA42AA26C3BDD72F56280FB54851@EXCHMBX03.fed.cclrc.ac.uk>

Hi Janik,

NeXus 4.3.0 (currently at rc2) implements its own HDF5 thread safety via pthreads / Windows Critical sections, so you will be able to use either thread safe or non thread safe HDF5 from a multi-threaded program. NeXus basically protects all HDF5 calls with a global lock, which doesn't allow any concurrency, but my understanding of the current thread safety in HDF5 is that it doesn't yet either; we may need to revisit this if things change in HDF5  

Regards,

Freddie 

> -----Original Message-----
> From: nexus-developers-bounces at nexusformat.org [mailto:nexus-
> developers-bounces at nexusformat.org] On Behalf Of Zikovsky, Janik L.
> Sent: 15 February 2012 19:03
> To: nexus-developers at nexusformat.org
> Subject: [Nexus-developers] Thread-safety of HDF5, NeXus
> 
> Hello,
> 
> I just found out that the usual binaries of HDF5 are NOT thread-safe
> even when accessing DIFFERENT files from separate threads in the same
> process. However, the HDF libraries CAN be built in a thread-safe way:
> http://www.hdfgroup.uiuc.edu/papers/features/mthdf/index.html
> 
> My question is: does NeXus use the thread-safe version of HDF5 (I
> suspect no)? And if not, can it?
> 
> Thanks!
> 
> Janik Zikovsky
> Scientific Data Analysis Group, Spallation Neutron Source
> 
> _______________________________________________
> NeXus-developers mailing list
> NeXus-developers at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus-developers
-- 
Scanned by iCritical.


From Mark.Koennecke at psi.ch  Mon Feb 20 15:32:11 2012
From: Mark.Koennecke at psi.ch (Mark Koennecke)
Date: Mon, 20 Feb 2012 16:32:11 +0100
Subject: [Nexus-developers] NeXus Quo Vadis
Message-ID: <4F42677B.90509@psi.ch>

Hi,

as promised at the last tele conference I send a short document about 
some views I
have about NeXus and the future of NeXus. It questions many of the 
things we have done
so far. So this may be a bit disruptive. My general ideas was to discuss 
these topics at
the next NIAC. But I first want your feedback. Depending on this:
- we can decide to bury the document
- we can improve it to become a framework for discussion at NIAC

I feel a little uneasy about writing such a document. On the other hand, 
if times change
NeXus may need to change too.

This paper is for NIAC members only.

Best Regards,

               Mark Koennecke

-------------- next part --------------
A non-text attachment was scrubbed...
Name: NeXusQV.pdf
Type: application/pdf
Size: 56753 bytes
Desc: not available
URL: <http://lists.nexusformat.org/pipermail/nexus-developers/attachments/20120220/e175e508/attachment-0001.pdf>

From sole at esrf.fr  Mon Feb 20 16:54:29 2012
From: sole at esrf.fr (=?ISO-8859-1?Q?=22V=2E_Armando_Sol=E9=22?=)
Date: Mon, 20 Feb 2012 17:54:29 +0100
Subject: [Nexus-developers] NeXus Quo Vadis
In-Reply-To: <4F42677B.90509@psi.ch>
References: <4F42677B.90509@psi.ch>
Message-ID: <4F427AC5.9030807@esrf.fr>

Hi there,

Just to clarify my position and that of the ESRF concerning what Mark 
has written:

"""
NeXus-Armando-Light
A better name is required here. The Armando is for Armando Sole who more 
or less suggested this
aproach if I read him correctly. This is another version of a lighter 
NeXus. I believe the approach
suggested here would formalize a practice of using NeXus which is common 
at synchrotron sources. This
version looks like this:
1. Use HDF-5 as a file format
"""

100 % correct.

"""
2. Store your data in a simplified hierarchy using NXentry and 
NXcollection groups. Apply a lot of
freedom how you do this.
"""

NXentry mandatory.
NXcollection for anything not dealt with by other NXclass.

If you want to describe your beamline, then there is a group 
(NXinstrument) for that. I would not write it into an NXcollection.
Personally I like how ALBA is generating Nexus files.

"""
3. Have NXmethod groups at NXentry level which contain links to those 
data items required for a
specific use of the file. For example a group NXsas would contain links 
to all data items required for
small angle scattering analysis. The content of the NXmethod groups can 
be derived from the
existing application definitions. Just flatten the application 
definition hierarchy and resolve name
conflicts by prefixing.
"""

That is certainly not our point of view. At last NIAC was decided to 
have NXsubentry performing that role. I would have preferred to have 
NXdefinition as NX_CLASS attribute, but at the end is just a personal taste.

What we advocate is, for instance:

/(root)
/whatever_entry_name:
      @NX_CLASS:NXentry
      start_time
      end_time
      ....
/whatever_entry_name/whatever_group_name:
     @NX_CLASS:NXsubentry
     definition  (string set to the particular technique implemented 
helping to understand the rest of the fields in the subentry)
     .....

That approach solves the issue of several techniques under the same 
NXentry because you can have several NXsubentry groups.

Our most common case is simultaneous fluorescence-diffraction. That 
approach is compliant with NeXus and it is not against any NeXus philosophy.
What we do not accept, is to force the different items to be found 
inside the NXsubentry group to belong a particular place in the NeXus 
tree. They just need to be there, either as datasets, as groups or as 
links to datasets or groups. Please take a loot at the attached talk I 
gave at the Q2XAFS 2011 workshop. The attachment needed approval. Please 
download it from 
http://ftp.esrf.fr/pub/scisoft/HDF5FILES/SOLE-HDF5NeXusAndBeyond.pdf

There are currently initiatives at APS and SLS among others for 
standardizing tomography data. They define a exchange group with the 
information needed to analyze the data, with other optional groups to 
describe the instrument, and XML representation for validation purposes 
and so on. When I take a look at their work, they are doing nothing 
different to what can be done with NeXus adding an attribute NXsubentry 
to their exchange group. Should one congratulate the NIAC for 
encouraging such practices with the NIAC intransigence?

There are several consequences of the "Armando's approach":

1 - If HDF5 is the format, the NeXus API is not necessary.
2 - If the analysis information is in the definition, SOLEIL's common 
data model is already contained in it and becomes redundant. Its only 
motivation would be to deal with non-HDF5 legacy formats.
3 - The NeXus application definition validation tool is a perfectly 
valid tool.

Other big mistakes are that the NIAC has tried to answer:

a) how one had to store the data and
b) how one had to analyze them


It is our opinion that:

a) How to store the data is a question that belongs to the data 
acquisition people of the facility and the constraints of the experiment 
(speed)

b) How to analyze the data belongs to the community employing a 
technique and/or the analysis application developers to decide what is 
needed. The NIAC can define a set of required data to perform an 
analysis, but if the leading applications decide to use other parameters 
the NIAC has nothing to do. As a matter of fact there are community 
initiatives going on for XAS and for tomography. If they arrive to a 
consensus, the NIAC will have *no other choice* than to accept them as 
they come.

I think NeXus can still play a role:

1 - Acting as custodian of the community approved application 
definitions and providing the corresponding validation tool(s).
2 - Presenting anything else as a set of recommendations.
3 - Redirecting NAPI maintenance/development efforts to work with the 
HDF group to  implement much needed features as the single writer 
multiple reader and to push for interesting developments that currently 
are just proposals. As a matter of fact, there is a proposal for an 
abstract object layer that would allow to use HDF5 on non HDF5 files 
therefore getting all SOLEIL's common data model objectives directly 
supplied by the HDF5 library.

Best regards,

Armando

On 20/02/2012 16:32, Mark Koennecke wrote:
> Hi,
>
> as promised at the last tele conference I send a short document about 
> some views I
> have about NeXus and the future of NeXus. It questions many of the 
> things we have done
> so far. So this may be a bit disruptive. My general ideas was to 
> discuss these topics at
> the next NIAC. But I first want your feedback. Depending on this:
> - we can decide to bury the document
> - we can improve it to become a framework for discussion at NIAC
>
> I feel a little uneasy about writing such a document. On the other 
> hand, if times change
> NeXus may need to change too.
>
> This paper is for NIAC members only.
>
> Best Regards,
>
>               Mark Koennecke
>
>
>
> _______________________________________________
> NeXus-developers mailing list
> NeXus-developers at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus-developers


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nexusformat.org/pipermail/nexus-developers/attachments/20120220/14486f1b/attachment.html>

From jemian at anl.gov  Mon Feb 20 17:07:05 2012
From: jemian at anl.gov (Pete R. Jemian)
Date: Mon, 20 Feb 2012 11:07:05 -0600
Subject: [Nexus-developers] NeXus Quo Vadis
In-Reply-To: <4F427AC5.9030807@esrf.fr>
References: <4F42677B.90509@psi.ch> <4F427AC5.9030807@esrf.fr>
Message-ID: <4F427DB9.3090407@anl.gov>

I like this.

On 2/20/2012 10:54 AM, "V. Armando Sol?" wrote:
> """
> 2. Store your data in a simplified hierarchy using NXentry and
> NXcollection groups. Apply a lot of
> freedom how you do this.
> """
>
> NXentry mandatory.
> NXcollection for anything not dealt with by other NXclass.
>
> If you want to describe your beamline, then there is a group
> (NXinstrument) for that. I would not write it into an NXcollection.
> Personally I like how ALBA is generating Nexus files.

This is actually a good model for the EPICS areaDetector, NeXus file 
plugin, to use.  So, the basic structure I have been recommending is:

<file>
    NXentry (required)
      NXdata (required)
        data : contains the image
      NXcollection (optional)
        user-supplied list of uncategorized metadata
      NXinstrument (optional)
        metadata organized as defined in the NeXus dictionary

links may be used to avoid replicating information, if that is important

-- 
----------------------------------------------------------
  Pete R. Jemian, Ph.D.                <jemian at anl.gov>
  Beam line Controls and Data Acquisition, Group Leader
  Advanced Photon Source,   Argonne National Laboratory
  Argonne, IL  60439                   630 - 252 - 3189
-----------------------------------------------------------
     Education is the one thing for which people
        are willing to pay yet not receive.
-----------------------------------------------------------

From ROsborn at anl.gov  Mon Feb 20 17:18:24 2012
From: ROsborn at anl.gov (Ray Osborn)
Date: Mon, 20 Feb 2012 11:18:24 -0600
Subject: [Nexus-developers] NeXus Quo Vadis
In-Reply-To: <4F427DB9.3090407@anl.gov>
References: <4F42677B.90509@psi.ch> <4F427AC5.9030807@esrf.fr>
 <4F427DB9.3090407@anl.gov>
Message-ID: <D8CF2F56-B389-4176-B6F1-60EA907AD491@anl.gov>

I want to support the idea that there is tremendous value to encouraging the use of NeXus in this way  - in fact, it is the way I have been using NeXus for years - as a way of loosely connecting data that are not necessarily defined by a strict standard. As Pete suggested, I would add that every NeXus file should contain at least one NXdata group, and I think people should be encouraged to use the glossary rather than inventing all their own terms, if they exist. 

This, of course, requires access to flexible tools (usually scripting tools) that allow you to handle whatever data you are given interactively. If you are writing formal data analysis applications, you will have to be much stricter in requiring the input data to conform to some standard, but if you are using a scripting toolbox to play with the data, that is unnecessary. Hence my interest in the Python tree API (which I hope will be included in the 4.3 release).

Ray

On Feb 20, 2012, at 11:07 AM, Pete R. Jemian wrote:

> I like this.
> 
> On 2/20/2012 10:54 AM, "V. Armando Sol?" wrote:
>> """
>> 2. Store your data in a simplified hierarchy using NXentry and
>> NXcollection groups. Apply a lot of
>> freedom how you do this.
>> """
>> 
>> NXentry mandatory.
>> NXcollection for anything not dealt with by other NXclass.
>> 
>> If you want to describe your beamline, then there is a group
>> (NXinstrument) for that. I would not write it into an NXcollection.
>> Personally I like how ALBA is generating Nexus files.
> 
> This is actually a good model for the EPICS areaDetector, NeXus file plugin, to use.  So, the basic structure I have been recommending is:
> 
> <file>
>   NXentry (required)
>     NXdata (required)
>       data : contains the image
>     NXcollection (optional)
>       user-supplied list of uncategorized metadata
>     NXinstrument (optional)
>       metadata organized as defined in the NeXus dictionary
> 
> links may be used to avoid replicating information, if that is important
> 
> -- 
> ----------------------------------------------------------
> Pete R. Jemian, Ph.D.                <jemian at anl.gov>
> Beam line Controls and Data Acquisition, Group Leader
> Advanced Photon Source,   Argonne National Laboratory
> Argonne, IL  60439                   630 - 252 - 3189
> -----------------------------------------------------------
>    Education is the one thing for which people
>       are willing to pay yet not receive.
> -----------------------------------------------------------
> _______________________________________________
> 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





From ROsborn at anl.gov  Mon Feb 20 17:19:55 2012
From: ROsborn at anl.gov (Ray Osborn)
Date: Mon, 20 Feb 2012 11:19:55 -0600
Subject: [Nexus-developers] NeXus Quo Vadis
In-Reply-To: <D8CF2F56-B389-4176-B6F1-60EA907AD491@anl.gov>
References: <4F42677B.90509@psi.ch> <4F427AC5.9030807@esrf.fr>
 <4F427DB9.3090407@anl.gov> <D8CF2F56-B389-4176-B6F1-60EA907AD491@anl.gov>
Message-ID: <A7B8F2A9-B27A-4120-9B78-8195880D3A09@anl.gov>

I should have said I was responding to Armando's post. 

On Feb 20, 2012, at 11:18 AM, Ray Osborn wrote:

> I want to support the idea that there is tremendous value to encouraging the use of NeXus in this way  - in fact, it is the way I have been using NeXus for years - as a way of loosely connecting data that are not necessarily defined by a strict standard. As Pete suggested, I would add that every NeXus file should contain at least one NXdata group, and I think people should be encouraged to use the glossary rather than inventing all their own terms, if they exist. 
> 
> This, of course, requires access to flexible tools (usually scripting tools) that allow you to handle whatever data you are given interactively. If you are writing formal data analysis applications, you will have to be much stricter in requiring the input data to conform to some standard, but if you are using a scripting toolbox to play with the data, that is unnecessary. Hence my interest in the Python tree API (which I hope will be included in the 4.3 release).
> 
> Ray
> 
> On Feb 20, 2012, at 11:07 AM, Pete R. Jemian wrote:
> 
>> I like this.
>> 
>> On 2/20/2012 10:54 AM, "V. Armando Sol?" wrote:
>>> """
>>> 2. Store your data in a simplified hierarchy using NXentry and
>>> NXcollection groups. Apply a lot of
>>> freedom how you do this.
>>> """
>>> 
>>> NXentry mandatory.
>>> NXcollection for anything not dealt with by other NXclass.
>>> 
>>> If you want to describe your beamline, then there is a group
>>> (NXinstrument) for that. I would not write it into an NXcollection.
>>> Personally I like how ALBA is generating Nexus files.
>> 
>> This is actually a good model for the EPICS areaDetector, NeXus file plugin, to use.  So, the basic structure I have been recommending is:
>> 
>> <file>
>>  NXentry (required)
>>    NXdata (required)
>>      data : contains the image
>>    NXcollection (optional)
>>      user-supplied list of uncategorized metadata
>>    NXinstrument (optional)
>>      metadata organized as defined in the NeXus dictionary
>> 
>> links may be used to avoid replicating information, if that is important
>> 
>> -- 
>> ----------------------------------------------------------
>> Pete R. Jemian, Ph.D.                <jemian at anl.gov>
>> Beam line Controls and Data Acquisition, Group Leader
>> Advanced Photon Source,   Argonne National Laboratory
>> Argonne, IL  60439                   630 - 252 - 3189
>> -----------------------------------------------------------
>>   Education is the one thing for which people
>>      are willing to pay yet not receive.
>> -----------------------------------------------------------
>> _______________________________________________
>> 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
> 
> 
> 
> 
> _______________________________________________
> 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





From sole at esrf.fr  Mon Feb 20 16:51:18 2012
From: sole at esrf.fr (=?ISO-8859-1?Q?=22V=2E_Armando_Sol=E9=22?=)
Date: Mon, 20 Feb 2012 17:51:18 +0100
Subject: [Nexus-developers] NeXus Quo Vadis
In-Reply-To: <4F42677B.90509@psi.ch>
References: <4F42677B.90509@psi.ch>
Message-ID: <4F427A06.7070501@esrf.fr>

Hi there,

Just to clarify my position and that of the ESRF concerning what Mark 
has written:

"""
NeXus-Armando-Light
A better name is required here. The Armando is for Armando Sole who more 
or less suggested this
aproach if I read him correctly. This is another version of a lighter 
NeXus. I believe the approach
suggested here would formalize a practice of using NeXus which is common 
at synchrotron sources. This
version looks like this:
1. Use HDF-5 as a file format
"""

100 % correct.

"""
2. Store your data in a simplified hierarchy using NXentry and 
NXcollection groups. Apply a lot of
freedom how you do this.
"""

NXentry mandatory.
NXcollection for anything not dealt with by other NXclass.

If you want to describe your beamline, then there is a group 
(NXinstrument) for that. I would not write it into an NXcollection.
Personally I like how ALBA is generating Nexus files.

"""
3. Have NXmethod groups at NXentry level which contain links to those 
data items required for a
specific use of the file. For example a group NXsas would contain links 
to all data items required for
small angle scattering analysis. The content of the NXmethod groups can 
be derived from the
existing application definitions. Just flatten the application 
definition hierarchy and resolve name
conflicts by prefixing.
"""

That is certainly not our point of view. At last NIAC was decided to 
have NXsubentry performing that role. I would have preferred to have 
NXdefinition as NX_CLASS attribute, but at the end is just a personal taste.

What we advocate is, for instance:

/(root)
/whatever_entry_name:
      @NX_CLASS:NXentry
      start_time
      end_time
      ....
/whatever_entry_name/whatever_group_name:
     @NX_CLASS:NXsubentry
     definition  (string set to the particular technique implemented 
helping to understand the rest of the fields in the subentry)
     .....

That approach solves the issue of several techniques under the same 
NXentry because you can have several NXsubentry groups.

Our most common case is simultaneous fluorescence-diffraction. That 
approach is compliant with NeXus and it is not against any NeXus philosophy.
What we do not accept, is to force the different items to be found 
inside the NXsubentry group to belong a particular place in the NeXus 
tree. They just need to be there, either as datasets, as groups or as 
links to datasets or groups. Please take a loot at the attached talk I 
gave at the Q2XAFS 2011 workshop.

There are currently initiatives at APS and SLS among others for 
standardizing tomography data. They define a exchange group with the 
information needed to analyze the data, with other optional groups to 
describe the instrument, and XML representation for validation purposes 
and so on. When I take a look at their work, they are doing nothing 
different to what can be done with NeXus adding an attribute NXsubentry 
to their exchange group. Should one congratulate the NIAC for 
encouraging such practices with the NIAC intransigence?

There are several consequences of the "Armando's approach":

1 - If HDF5 is the format, the NeXus API is not necessary.
2 - If the analysis information is in the definition, SOLEIL's common 
data model is already contained in it and becomes redundant. Its only 
motivation would be to deal with non-HDF5 legacy formats.
3 - The NeXus application definition validation tool is a perfectly 
valid tool.

Other big mistakes are that the NIAC has tried to answer:

a) how one had to store the data and
b) how one had to analyze them


It is our opinion that:

a) How to store the data is a question that belongs to the data 
acquisition people of the facility and the constraints of the experiment 
(speed)

b) How to analyze the data belongs to the community employing a 
technique and/or the analysis application developers to decide what is 
needed. The NIAC can define a set of required data to perform an 
analysis, but if the leading applications decide to use other parameters 
the NIAC has nothing to do. As a matter of fact there are community 
initiatives going on for XAS and for tomography. If they arrive to a 
consensus, the NIAC will have *no other choice* than to accept them as 
they come.

I think NeXus can still play a role:

1 - Acting as custodian of the community approved application 
definitions and providing the corresponding validation tool(s).
2 - Presenting anything else as a set of recommendations.
3 - Redirecting NAPI maintenance/development efforts to work with the 
HDF group to  implement much needed features as the single writer 
multiple reader and to push for interesting developments that currently 
are just proposals. As a matter of fact, there is a proposal for an 
abstract object layer that would allow to use HDF5 on non HDF5 files 
therefore getting all SOLEIL's common data model objectives directly 
supplied by the HDF5 library.

Best regards,

Armando

On 20/02/2012 16:32, Mark Koennecke wrote:
> Hi,
>
> as promised at the last tele conference I send a short document about 
> some views I
> have about NeXus and the future of NeXus. It questions many of the 
> things we have done
> so far. So this may be a bit disruptive. My general ideas was to 
> discuss these topics at
> the next NIAC. But I first want your feedback. Depending on this:
> - we can decide to bury the document
> - we can improve it to become a framework for discussion at NIAC
>
> I feel a little uneasy about writing such a document. On the other 
> hand, if times change
> NeXus may need to change too.
>
> This paper is for NIAC members only.
>
> Best Regards,
>
>               Mark Koennecke
>
>
>
> _______________________________________________
> NeXus-developers mailing list
> NeXus-developers at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus-developers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nexusformat.org/pipermail/nexus-developers/attachments/20120220/737b833c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SOLE-HDF5NeXusAndBeyond.pdf
Type: application/pdf
Size: 1474632 bytes
Desc: not available
URL: <http://lists.nexusformat.org/pipermail/nexus-developers/attachments/20120220/737b833c/attachment-0001.pdf>

From Tobias.Richter at diamond.ac.uk  Tue Mar  6 10:31:27 2012
From: Tobias.Richter at diamond.ac.uk (Tobias.Richter at diamond.ac.uk)
Date: Tue, 6 Mar 2012 10:31:27 +0000
Subject: [Nexus-developers] 4.3 rc download
Message-ID: <4669C175DBA03A4981471A4B07FEC3740F805442@EXCHMBX03.fed.cclrc.ac.uk>

There currently is no way to find out about the 4.3 release candidate from the www.nexusformat.org<http://www.nexusformat.org> website unless you dig very deep. Which you would only do when you know what you are looking for. After a bit of trying I am no longer sure there is a way to get to a tarball at all.
That should be fixed I think. And maybe the website could do with being slightly less static.

Regards,

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
 





From freddie.akeroyd at stfc.ac.uk  Tue Mar  6 12:03:43 2012
From: freddie.akeroyd at stfc.ac.uk (freddie.akeroyd at stfc.ac.uk)
Date: Tue, 6 Mar 2012 12:03:43 +0000
Subject: [Nexus-developers] 4.3 rc download
In-Reply-To: <4669C175DBA03A4981471A4B07FEC3740F805442@EXCHMBX03.fed.cclrc.ac.uk>
References: <4669C175DBA03A4981471A4B07FEC3740F805442@EXCHMBX03.fed.cclrc.ac.uk>
Message-ID: <8CB55BA9D873DA42AA26C3BDD72F56280FB84212@EXCHMBX03.fed.cclrc.ac.uk>

Hi Tobias,

the release candidate has only been circulated to nexus-tech and does indeed need linking better from the main site. Which page did you find on the wiki? http://wiki.nexusformat.org/NeXus_43_Testing contains a link to the download page and the tarball download works there as far as I can tell

Regards,

Freddie

> -----Original Message-----
> From: nexus-developers-bounces at nexusformat.org [mailto:nexus-
> developers-bounces at nexusformat.org] On Behalf Of
> Tobias.Richter at diamond.ac.uk
> Sent: 06 March 2012 10:31
> To: nexus-developers at nexusformat.org
> Subject: [Nexus-developers] 4.3 rc download
> 
> There currently is no way to find out about the 4.3 release candidate
> from the www.nexusformat.org<http://www.nexusformat.org> website unless
> you dig very deep. Which you would only do when you know what you are
> looking for. After a bit of trying I am no longer sure there is a way
> to get to a tarball at all.
> That should be fixed I think. And maybe the website could do with being
> slightly less static.
> 
> Regards,
> 
> Tobias
> 

-- 
Scanned by iCritical.


From Tobias.Richter at diamond.ac.uk  Tue Mar  6 13:07:09 2012
From: Tobias.Richter at diamond.ac.uk (Tobias.Richter at diamond.ac.uk)
Date: Tue, 6 Mar 2012 13:07:09 +0000
Subject: [Nexus-developers] 4.3 rc download
In-Reply-To: <8CB55BA9D873DA42AA26C3BDD72F56280FB84212@EXCHMBX03.fed.cclrc.ac.uk>
References: <4669C175DBA03A4981471A4B07FEC3740F805442@EXCHMBX03.fed.cclrc.ac.uk>,
 <8CB55BA9D873DA42AA26C3BDD72F56280FB84212@EXCHMBX03.fed.cclrc.ac.uk>
Message-ID: <4669C175DBA03A4981471A4B07FEC3740F80552C@EXCHMBX03.fed.cclrc.ac.uk>

Hi Freddie,

Feel free to disagree, but I'd distribute release candidates more freely than exclusively to nexus-tech. A few more people doesn't harm and there is nothing else to fear really.Just the fact that there is visible activity is a good thing also.

You've now linked the NeXus_43_Testing page from two others, but the best thing I found was the Release (at that time with out a link to download). What would be further helpful is something more obvious. All of the links in the Installation section on the home page could link to a page that encourages interested people to try the release candidate. (But the wording would lead to faint of heart to the released version, of course.)
I'd even put some news banner on the home page, at least for the final release. The way it is designed now you could have returning customers to the website that never find out about new releases, upcoming meetings etc.

Regards,

Tobias

________________________________________
From: nexus-developers-bounces at nexusformat.org [nexus-developers-bounces at nexusformat.org] on behalf of freddie.akeroyd at stfc.ac.uk [freddie.akeroyd at stfc.ac.uk]
Sent: 06 March 2012 12:03
To: nexus-developers at nexusformat.org
Subject: Re: [Nexus-developers] 4.3 rc download

Hi Tobias,

the release candidate has only been circulated to nexus-tech and does indeed need linking better from the main site. Which page did you find on the wiki? http://wiki.nexusformat.org/NeXus_43_Testing contains a link to the download page and the tarball download works there as far as I can tell

Regards,

Freddie

> -----Original Message-----
> From: nexus-developers-bounces at nexusformat.org [mailto:nexus-
> developers-bounces at nexusformat.org] On Behalf Of
> Tobias.Richter at diamond.ac.uk
> Sent: 06 March 2012 10:31
> To: nexus-developers at nexusformat.org
> Subject: [Nexus-developers] 4.3 rc download
>
> There currently is no way to find out about the 4.3 release candidate
> from the www.nexusformat.org<http://www.nexusformat.org> website unless
> you dig very deep. Which you would only do when you know what you are
> looking for. After a bit of trying I am no longer sure there is a way
> to get to a tarball at all.
> That should be fixed I think. And maybe the website could do with being
> slightly less static.
>
> Regards,
>
> Tobias
>

--
Scanned by iCritical.

_______________________________________________
NeXus-developers mailing list
NeXus-developers at nexusformat.org
http://lists.nexusformat.org/mailman/listinfo/nexus-developers

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





From freddie.akeroyd at stfc.ac.uk  Tue Mar  6 13:33:48 2012
From: freddie.akeroyd at stfc.ac.uk (freddie.akeroyd at stfc.ac.uk)
Date: Tue, 6 Mar 2012 13:33:48 +0000
Subject: [Nexus-developers] 4.3 rc download
In-Reply-To: <4669C175DBA03A4981471A4B07FEC3740F80552C@EXCHMBX03.fed.cclrc.ac.uk>
References: <4669C175DBA03A4981471A4B07FEC3740F805442@EXCHMBX03.fed.cclrc.ac.uk>, 
 <8CB55BA9D873DA42AA26C3BDD72F56280FB84212@EXCHMBX03.fed.cclrc.ac.uk>
 <4669C175DBA03A4981471A4B07FEC3740F80552C@EXCHMBX03.fed.cclrc.ac.uk>
Message-ID: <8CB55BA9D873DA42AA26C3BDD72F56280FB8438C@EXCHMBX03.fed.cclrc.ac.uk>

Hi Tobias,

no I agree - the plan was to distribute to nexus-tech first and then go wider. The more people testing the better, but I wanted to start with a smaller group first so if there was a major general problem it didn't mean a lot of people were spending time on it. rc2 should have got announced to nexus-developers too, but I wanted to get the release notes in better shape and so it hasn't happened yet...

Freddie 

> -----Original Message-----
> From: nexus-developers-bounces at nexusformat.org [mailto:nexus-
> developers-bounces at nexusformat.org] On Behalf Of
> Tobias.Richter at diamond.ac.uk
> Sent: 06 March 2012 13:07
> To: nexus-developers at nexusformat.org
> Subject: Re: [Nexus-developers] 4.3 rc download
> 
> Hi Freddie,
> 
> Feel free to disagree, but I'd distribute release candidates more
> freely than exclusively to nexus-tech. A few more people doesn't harm
> and there is nothing else to fear really.Just the fact that there is
> visible activity is a good thing also.
> 
> You've now linked the NeXus_43_Testing page from two others, but the
> best thing I found was the Release (at that time with out a link to
> download). What would be further helpful is something more obvious. All
> of the links in the Installation section on the home page could link to
> a page that encourages interested people to try the release candidate.
> (But the wording would lead to faint of heart to the released version,
> of course.)
> I'd even put some news banner on the home page, at least for the final
> release. The way it is designed now you could have returning customers
> to the website that never find out about new releases, upcoming
> meetings etc.
> 
> Regards,
> 
> Tobias
> 
> ________________________________________
> From: nexus-developers-bounces at nexusformat.org [nexus-developers-
> bounces at nexusformat.org] on behalf of freddie.akeroyd at stfc.ac.uk
> [freddie.akeroyd at stfc.ac.uk]
> Sent: 06 March 2012 12:03
> To: nexus-developers at nexusformat.org
> Subject: Re: [Nexus-developers] 4.3 rc download
> 
> Hi Tobias,
> 
> the release candidate has only been circulated to nexus-tech and does
> indeed need linking better from the main site. Which page did you find
> on the wiki? http://wiki.nexusformat.org/NeXus_43_Testing contains a
> link to the download page and the tarball download works there as far
> as I can tell
> 
> Regards,
> 
> Freddie
> 
> > -----Original Message-----
> > From: nexus-developers-bounces at nexusformat.org [mailto:nexus-
> > developers-bounces at nexusformat.org] On Behalf Of
> > Tobias.Richter at diamond.ac.uk
> > Sent: 06 March 2012 10:31
> > To: nexus-developers at nexusformat.org
> > Subject: [Nexus-developers] 4.3 rc download
> >
> > There currently is no way to find out about the 4.3 release candidate
> > from the www.nexusformat.org<http://www.nexusformat.org> website
> unless
> > you dig very deep. Which you would only do when you know what you are
> > looking for. After a bit of trying I am no longer sure there is a way
> > to get to a tarball at all.
> > That should be fixed I think. And maybe the website could do with
> being
> > slightly less static.
> >
> > Regards,
> >
> > Tobias
> >
> 
> --
> Scanned by iCritical.
> 
> _______________________________________________
> NeXus-developers mailing list
> NeXus-developers at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus-developers
> 
> --
> 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-developers mailing list
> NeXus-developers at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus-developers
-- 
Scanned by iCritical.


From yaya at bernstein-plus-sons.com  Tue Mar  6 14:07:39 2012
From: yaya at bernstein-plus-sons.com (Herbert J. Bernstein)
Date: Tue, 06 Mar 2012 09:07:39 -0500
Subject: [Nexus-developers] [NeXus Library 4.3.0-20120306svn] testsuite: 10
	failed
Message-ID: <4F561A2B.2010807@bernstein-plus-sons.com>

This was one of several runs on a MacBook Pro under Lion 10.7.3.  The 
problem is
with gfortran.

gfortran --version
GNU Fortran (GCC) 4.6.2
Copyright (C) 2011 Free Software Foundation, Inc.

which was brought in with fink.

In addition to the problem reported in the log, there is a
nuisance problem with make clean (or make disclean) that results in

mv napi.html nxs.napi.html
mv: rename napi.html to nxs.napi.html: No such file or directory
make[2]: *** [nxs.napi.html] Error 1

which is cured by simply reunpacking the tarball
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: testsuite.log
URL: <http://lists.nexusformat.org/pipermail/nexus-developers/attachments/20120306/d9546497/attachment-0001.ksh>

From Mark.Koennecke at psi.ch  Thu Apr  5 10:56:30 2012
From: Mark.Koennecke at psi.ch (Mark Koennecke)
Date: Thu, 05 Apr 2012 11:56:30 +0200
Subject: [Nexus-developers] Scattering application definition
Message-ID: <4F7D6C4E.4020507@psi.ch>

Hi,

Pete Jemian already pointed out a couple of problems with the NXDL.
I have a few points to make about the content:
- In general the application definition is very close to what NeXus does.
- The scattering application definition defines coordinate systems for 
incoming beam,
   sample and detector. Here are some issues:

   * NeXus is  trying to come up with a system which emulates the CIF 
way of doing coordinate
     systems. I admit that we are very slow on this, possibly because it 
takes a crystallographer
     to understand and sort such things out. Rainers system would be in 
conflict with this.
   * The scattering application definition stores positions as separate 
x,y,z and rotation matrices
      as individual components, xx, xy, ...... Now, I would prefer to 
store this as array position[4] and
      orientation[3,3]. Or may be, the whole lot together as a 4x4 matrix.

- Time stamps. NX_DATE_TIME is in ISO8601 which alllows to have the 
seconds with as much precision as
   required. Time offset can be floating point values. Thus the NeXus 
time recording system is accurate
   enough.
  - In the detector group the name data is first used for what I call 
dimensions (data[1],data[2]) and later
    for the actual detector data. I assume that this is a typo and that 
in the first case dim[] was really meant.
    Otherwise I do not understand this. Strictly speaking, a separate 
field for dimensions is not necessary
    as the attributes to the detector data already contain that 
information (rank and dims).
- Otherwise there are just a few new names which have to synchronized.

Sorry that this response took to long.....

Best Regards and Happy Easter,

                Mark Koennecke

From Mark.Koennecke at psi.ch  Wed May  2 13:34:24 2012
From: Mark.Koennecke at psi.ch (Mark Koennecke)
Date: Wed, 02 May 2012 14:34:24 +0200
Subject: [Nexus-developers] Telephone
Message-ID: <4FA129D0.2020307@psi.ch>

Hi,

has everyone the problem with the bad reception?

Mark


From eugen.wintersberger at desy.de  Wed May  2 13:41:04 2012
From: eugen.wintersberger at desy.de (Wintersberger, Eugen)
Date: Wed, 2 May 2012 14:41:04 +0200
Subject: [Nexus-developers] Telephone
In-Reply-To: <4FA129D0.2020307@psi.ch>
References: <4FA129D0.2020307@psi.ch>
Message-ID: <35E004AD6290A7438FCA34BBF325F416022F4910@ADXV2.win.desy.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Das warst definitiv du.


On 05/02/2012 02:34 PM, Mark Koennecke wrote:
> Hi,
> 
> has everyone the problem with the bad reception?
> 
> Mark
> 
> _______________________________________________ NeXus-developers
> mailing list NeXus-developers at nexusformat.org 
> http://lists.nexusformat.org/mailman/listinfo/nexus-developers


- -- 
- ---------------------------------------
| DI. Dr. Eugen Wintersberger         |
|                                     |
| FS-EC                               |
| HASYLAB at DESY                     |
| Notkestr. 85                        |
| D-22607 Hamburg                     |
| Germany                             |
|                                     |
| E-Mail: eugen.wintersberger at desy.de |
| Telefon: +49-40-8998-1917           |
- ---------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk+hK2AACgkQlIP0H82W0vBM0wD+KZjFaSBtCMdfpzQ+DETFua0t
Bw6T7pf+SLJigAf3ApcA/1pzKhksS7lGaoUL38dYw6u5Q/kV9m3qBlmKCYlYur4d
=j3fL
-----END PGP SIGNATURE-----


From yaya at bernstein-plus-sons.com  Wed May  2 14:45:58 2012
From: yaya at bernstein-plus-sons.com (Herbert J. Bernstein)
Date: Wed, 02 May 2012 09:45:58 -0400
Subject: [Nexus-developers] Telephone
In-Reply-To: <4FA129D0.2020307@psi.ch>
References: <4FA129D0.2020307@psi.ch>
Message-ID: <4FA13A96.7090703@bernstein-plus-sons.com>

I have had considerable success with Skype conference calls, including 
ones involving
people from Hawaii to Austria, with my machine as the hub in NY. For a 
large group
voice-only is best, but for small groups (1-5) I have also had success 
with Skype
group video.

Regards,
Herbert

On 5/2/12 8:34 AM, Mark Koennecke wrote:
> Hi,
>
> has everyone the problem with the bad reception?
>
> Mark
>
> _______________________________________________
> NeXus-developers mailing list
> NeXus-developers at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus-developers
>


From zikovskyjl at ornl.gov  Thu May 24 19:37:40 2012
From: zikovskyjl at ornl.gov (Zikovsky, Janik L.)
Date: Thu, 24 May 2012 14:37:40 -0400
Subject: [Nexus-developers] Farewell and contact info
Message-ID: <5C691E518F345F4882FAB9E9839E60BA17CC38DE8C@EXCHMB.ornl.gov>

Hello everyone,

Since this is my last day I wanted to give you all my contact information so we can stay in touch... Email me at jzikovsky at hotmail.com ; cell phone is 865-964-2116 ; and if you have a LinkedIn account I'd like to add you too.

Please don't hesitate to get in touch, ask questions, or just chat! I might not have much time for the first couple of months but I'll try to answer ASAP. And Mantid is open source so I can even continue contributing (a little :) )!

For snail mail I will put a forward on my current address:

1137 Snyder Ridge Ln
Knoxville, TN, 37932.

Thanks a lot - it was a pleasure and an awesome learning experience. I'll miss all of you - and you are all welcome to crash at my place (when I have one) if you visit New York City!

Sincerely,

Janik Zikovsky



From reghosh at gmail.com  Thu May 31 23:24:12 2012
From: reghosh at gmail.com (Ron Ghosh)
Date: Thu, 31 May 2012 23:24:12 +0100
Subject: [Nexus-developers] NeXus Fortran bindings OSX,Linux
Message-ID: <CAMVussOA5_7jfLfYd8wU41T7MmkzvM2sGEMagkc_A6YcRWFHfA@mail.gmail.com>

Installation of NeXus libraries

To examine new ILL data in .nxs format I attempted using
the NeXus software donload from the web site onto Mac-OSX
version 10.5.8 (leopard, 2008), and fedora core 11 (x86_64, 2009)

Mac_osx
Using hdf5-1.8.5
The .dmg package installed without any indications of the location.
I subsequently found this in /usr/local/... There was no manifest.
There was no uninstall.  There were no fortran header file napif.inc
or NXmodule.f90.  I failed to build the examples; I did not have the
hdf4 library installed. I was using an HDF5 library which should
match the leopard system, which installed and checked through its
tests. There are two variants of hdf5, with fortran, without shareable
libraries, and without fortran, with shareable libraries.  I built
both; the latter is used with h5py, which I built successfully.

Since I had no idea of the configuration of the nexus build I decided to
copy the sources and build the library configuring without hdf4,
without xml, with fortran

I noted that the fortran bindings were not installed, and the fortran
test evidently failed.

Taking NXmodule.f90 from the /bindings directory the program compiled
manually but then crashed on running; gdb example in script.

I tried the napi_test.c  After editing napiconfig.h the program compiled
and ran.

I finally tried running napif5_test.f with the napif.inc header.  The
fortran entry points are not in the library libNexus.a

The build and running scripts are in build31may.rtf

Linux
I checked the rpm and found that the fortran headers were missing.  Again
there is no manifest, or indication of the configuration used. Installation
failed through missing dependencies.

Script in fed11inst



There are a few conflicts between the installation instructions on the WIKI
and
the main site; it is not clear which is the more relevant; those on the
WIKI seem
better.  For the distributions the documentation in the READme and INSTALL
and RELEASE notes constitute rather a mixed bag.

The distributed fortran headers NXmodule.f90 (3.9) doesn't match the current
version 4.2.


I am thus a little disappointed in that none of the fortran examples seem
to work,
and there is a lack of information on installing and checking.  It is
really hard work to find the necessary matching components.  For HDF4 the
website note on potential problems on mac-intel is broken.

Distributing a run-time set of libraries could be considered; this is
a necessary option for OSX since they are easily located with the
DYLD_LIBRARY_PATH environment variable.

For programs that only read data use of the hdf5 libraries only is a
possibility.  This would reduce the problem of installation to a single
package.

I have not tried the Windows versions.


I would be grateful for comments on these apparent system sensitivities;
this summary note is the consequence of more than 10 builds and tests.


Ron Ghosh

-- 
Ron Ghosh
62 Hookfield
Epsom KT19 8JG
UK
(+44)1372728294
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nexusformat.org/pipermail/nexus-developers/attachments/20120531/40cade94/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build31may.rtf
Type: application/rtf
Size: 181906 bytes
Desc: not available
URL: <http://lists.nexusformat.org/pipermail/nexus-developers/attachments/20120531/40cade94/attachment-0001.rtf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fed11inst
Type: application/octet-stream
Size: 11099 bytes
Desc: not available
URL: <http://lists.nexusformat.org/pipermail/nexus-developers/attachments/20120531/40cade94/attachment-0001.obj>

From Mark.Koennecke at psi.ch  Tue Jun  5 13:25:46 2012
From: Mark.Koennecke at psi.ch (Mark Koennecke)
Date: Tue, 05 Jun 2012 14:25:46 +0200
Subject: [Nexus-developers] NeXus Fortran bindings OSX,Linux
In-Reply-To: <CAMVussOA5_7jfLfYd8wU41T7MmkzvM2sGEMagkc_A6YcRWFHfA@mail.gmail.com>
References: <CAMVussOA5_7jfLfYd8wU41T7MmkzvM2sGEMagkc_A6YcRWFHfA@mail.gmail.com>
Message-ID: <4FCDFACA.2000008@psi.ch>

Hi Ron,

nice to hear from you again!

Sorry that you have so much trouble with Fortran. I am sorry, Fortran is
no a longer a priority these days. We are preparing for a new release.
May  be that one fixes some of the issues.

On 06/01/2012 12:24 AM, Ron Ghosh wrote:
> Installation of NeXus libraries
>
> To examine new ILL data in .nxs format I attempted using
> the NeXus software donload from the web site onto Mac-OSX
> version 10.5.8 (leopard, 2008), and fedora core 11 (x86_64, 2009)
>
> Mac_osx
> Using hdf5-1.8.5
> The .dmg package installed without any indications of the location.
> I subsequently found this in /usr/local/... There was no manifest.
> There was no uninstall.  There were no fortran header file napif.inc
> or NXmodule.f90.  I failed to build the examples; I did not have the
> hdf4 library installed. I was using an HDF5 library which should
> match the leopard system, which installed and checked through its
> tests. There are two variants of hdf5, with fortran, without shareable
> libraries, and without fortran, with shareable libraries.  I built
> both; the latter is used with h5py, which I built successfully.
>
> Since I had no idea of the configuration of the nexus build I decided to
> copy the sources and build the library configuring without hdf4,
> without xml, with fortran
>
> I noted that the fortran bindings were not installed, and the fortran
> test evidently failed.
>
> Taking NXmodule.f90 from the /bindings directory the program compiled
> manually but then crashed on running; gdb example in script.
>
I am not sure that we put the Fortran bindings still into binary kits...
It should build from source though. The F90 binding has not been 
maintained for
some time. We concentrated on the F77 one which works for F90 too.
> I tried the napi_test.c  After editing napiconfig.h the program compiled
> and ran.
>
> I finally tried running napif5_test.f with the napif.inc header.  The
> fortran entry points are not in the library libNexus.a
>
They are in libNeXusF77.a

> The build and running scripts are in build31may.rtf
>
> Linux
> I checked the rpm and found that the fortran headers were missing.  Again
> there is no manifest, or indication of the configuration used. 
> Installation
> failed through missing dependencies.
>
> Script in fed11inst
>
>
>
> There are a few conflicts between the installation instructions on the 
> WIKI and
> the main site; it is not clear which is the more relevant; those on 
> the WIKI seem
> better.  For the distributions the documentation in the READme and INSTALL
> and RELEASE notes constitute rather a mixed bag.
>
> The distributed fortran headers NXmodule.f90 (3.9) doesn't match the 
> current
> version 4.2.
>
>
> I am thus a little disappointed in that none of the fortran examples 
> seem to work,
> and there is a lack of information on installing and checking.  It is
> really hard work to find the necessary matching components.  For HDF4 the
> website note on potential problems on mac-intel is broken.
>
> Distributing a run-time set of libraries could be considered; this is
> a necessary option for OSX since they are easily located with the
> DYLD_LIBRARY_PATH environment variable.
>
> For programs that only read data use of the hdf5 libraries only is a
> possibility.  This would reduce the problem of installation to a single
> package.
>
> I have not tried the Windows versions.
>
>
> I would be grateful for comments on these apparent system sensitivities;
> this summary note is the consequence of more than 10 builds and tests.
>
>
Please try the next release kit: 
http://wiki.nexusformat.org/NeXus_43_Testing
This will be the one we fix issues against.

Best Regards,

             Mark

> Ron Ghosh
>
> -- 
> Ron Ghosh
> 62 Hookfield
> Epsom KT19 8JG
> UK
> (+44)1372728294
>
>
>
> _______________________________________________
> NeXus-developers mailing list
> NeXus-developers at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus-developers


From Mark.Koennecke at psi.ch  Fri Jul 13 12:12:30 2012
From: Mark.Koennecke at psi.ch (Mark Koennecke)
Date: Fri, 13 Jul 2012 13:12:30 +0200
Subject: [Nexus-developers] Next TelCo
Message-ID: <5000029E.8050402@psi.ch>

Hi,

if both Stuart and Pete J cannot make it on the 25, how about tuesday 24 
or thursday 26?

Regards,

          Mark

From jemian at anl.gov  Fri Jul 13 12:15:19 2012
From: jemian at anl.gov (Pete R. Jemian)
Date: Fri, 13 Jul 2012 06:15:19 -0500
Subject: [Nexus-developers] Next TelCo
In-Reply-To: <5000029E.8050402@psi.ch>
References: <5000029E.8050402@psi.ch>
Message-ID: <50000347.3030205@anl.gov>

the 26th works for me

On 7/13/2012 6:12 AM, Mark Koennecke wrote:
> Hi,
>
> if both Stuart and Pete J cannot make it on the 25, how about tuesday 24
> or thursday 26?
>
> Regards,
>
>           Mark
> _______________________________________________
> NeXus-developers mailing list
> NeXus-developers at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus-developers

-- 
----------------------------------------------------------
  Pete R. Jemian, Ph.D.                <jemian at anl.gov>
  Beam line Controls and Data Acquisition, Group Leader
  Advanced Photon Source,   Argonne National Laboratory
  Argonne, IL  60439                   630 - 252 - 3189
-----------------------------------------------------------
     Education is the one thing for which people
        are willing to pay yet not receive.
-----------------------------------------------------------



From eugen.wintersberger at desy.de  Fri Jul 13 12:21:45 2012
From: eugen.wintersberger at desy.de (Wintersberger, Eugen)
Date: Fri, 13 Jul 2012 13:21:45 +0200
Subject: [Nexus-developers] Next TelCo
In-Reply-To: <50000347.3030205@anl.gov>
References: <5000029E.8050402@psi.ch> <50000347.3030205@anl.gov>
Message-ID: <35E004AD6290A7438FCA34BBF325F416022F496D@ADXV2.win.desy.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

All dates work for me except the 27th.

regards
 Eugen

On 07/13/2012 01:15 PM, Pete R. Jemian wrote:
> the 26th works for me
> 
> On 7/13/2012 6:12 AM, Mark Koennecke wrote:
>> Hi,
>> 
>> if both Stuart and Pete J cannot make it on the 25, how about
>> tuesday 24 or thursday 26?
>> 
>> Regards,
>> 
>> Mark _______________________________________________ 
>> NeXus-developers mailing list NeXus-developers at nexusformat.org 
>> http://lists.nexusformat.org/mailman/listinfo/nexus-developers
> 


- -- 
- ---------------------------------------
| DI. Dr. Eugen Wintersberger         |
|                                     |
| FS-EC                               |
| HASYLAB at DESY                     |
| Notkestr. 85                        |
| D-22607 Hamburg                     |
| Germany                             |
|                                     |
| E-Mail: eugen.wintersberger at desy.de |
| Telefon: +49-40-8998-1917           |
- ---------------------------------------


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAlAABMkACgkQlIP0H82W0vAYDwEAkYKleLTzic1R3Anzqi9VX3HU
9840gMDX12hac5OnTeQA/i1OpmuEztdegjg13llWAYx3Bmnj2h/jchMd2pwD940n
=+l4x
-----END PGP SIGNATURE-----


From pedro.vicente at space-research.org  Mon Jul 23 19:36:18 2012
From: pedro.vicente at space-research.org (Pedro Vicente)
Date: Mon, 23 Jul 2012 13:36:18 -0500
Subject: [Nexus-developers] Release candidate of HDF5 NeXus writer API (H5NX)
Message-ID: <60A34E41E0F94054ACABB612F6497EF1@pvnVAIO>

Hello everyone,

Release candidate of HDF5 NeXus writer API (H5NX)
==========================

We are pleased to announce the release candidate of H5NX version 1.0,
available at the "NeXus" section at

http://www.space-research.org/

The HDF5 NeXus writer API (H5NX) is a set of functions that allow to write
data in the NeXus data format, using only HDF5 function calls.
It is being used at the at the Spallation Neutron Source of the Oak Ridge
National Laboratory.

The API is subject to changes at this time, please let me know of any
possible changes that you think should be done to the API.

The API is slightly based on the "High-Level HDF5 Lite" API, that I wrote
back in 2001

http://www.hdfgroup.org/HDF5/hdf5_hl/doc/RM_hdf5lt.html


H5Nx is written in C++. It has functions for writing scalar and vectors as 
well as strings, the
numerical functions make use of C++ templates for the data type, avoiding
the multitude of the dedicated type functions done for Lite HDF5.


H5tools version 1.0
==========================

The "HDF5" section has a new version of the h5tools package.
It is now possible to build h5tools in UNIX using the GNU autotools system.

Please visit the page for instructions and download.

H5tools includes:
. h5merge -- Merges two HDF5 files.
. h5nx -- HDF5 NeXus writer API and examples.

H5merge also merges netCDF files version4, since netCDF4 uses HDF5 as the
underlying file format, like NeXus does.

HDF Explorer needs friends
==========================

HDF Explorer now has a Facebook page.

https://www.facebook.com/hdf.explorer


About HDF Explorer:
"HDF Explorer is a data visualization program that reads Hierarchical Data
Format files (HDF, HDF-EOS and HDF5) and also netCDF data files."

It reads the netCDF "classic" format version 3 as well the netCDF4 format,
that is handled as a HDF5 file.

Space Research Software in the press
==========================

I was recently interviewed by the team of "Garage Games", the makers of the
Torque game engine.

http://www.garagegames.com/community/blogs/view/21745


Our App Store published game "Word Build" was made with the Torque game
engine.

http://itunes.apple.com/us/app/word-build/id467303721?mt=8


About Word Build
"Designed for all ages to help learners develop language skills, these word
puzzle games are for the iPhone/iPad and Macintosh computers."


----------------------
Pedro Vicente
pedro.vicente at space-research.org
http://www.space-research.org/ 


From cpascual at cells.es  Wed Aug 29 08:59:59 2012
From: cpascual at cells.es (Carlos Pascual)
Date: Wed, 29 Aug 2012 09:59:59 +0200
Subject: [Nexus-developers] Python Tree API
Message-ID: <201208291000.00054.cpascual@cells.es>

******************
Sorry if this message is duplicated, the list reported a delivery error and I 
haven't seen the message appear afterwards, so I am resending.
******************


Hi,
I reply to this old thread because only now I got to play with the tree api 
(using the Nexus 4.3 release). 

First of all, I love the tree api. It makes the life *so* much easier than the 
napi...

Here are some comments/questions/suggestions I have so far:

1- The docstring of the nxs module should mention the napi and the tree api, 
possibly with a summary of both and stating its differences/purposes. This way 
a user doing help(nxs) would learn learn where to start looking for help. It 
could also give a simple example on how to open a NeXus file using each API. 
And It should at least mention the relevant classes whose docstrings may help 
the user in understanding the tree api (e.g., it should recommend to read 
NXgroup and NXfield docstrings)

2- I think that even more stress should be put in recommending the dictionary 
approach to access data (over the member approach) for anything other than 
interactive use. Although it is said several times, many of the examples state 
both methods as "equivalent", or even only use the member access for the 
example. This is calling for users to get annoyed 

3- I find the info provided by the docstrings of NXgroup.save (and .write) 
methods not sufficient. For example, if I want to save to a file incrementally, I 
could start by (e.g.) calling save on an empty NXentry, then inserting 
groups/fields on that NXentry and then calling ".write()" the NXentry when I 
want to make the changes permanent. But it is not clear to me from the 
docstrings whether this will waste time rewriting already written groups/data.

4- How do I make a named link? I would expect a keyword argument to the 
NXgroup.makelink() method

5- Is the "name" keyword of the NXgroup.insert() method actually honored? 
Consider the following code:

++++++++++++++++
import nxs
e = nxs.NXentry()
s = nxs.NXsample(name='some_name')
e.insert(s, name='other_name')
print e.tree  

#this outputs:
#
#entry:NXentry
#  some_name:NXsample
++++++++++++++++

I would expect that the NXsample group would be called 'other_name'. This is 
what I understand from the following phrase in the NXgroup docsting:
> insert(self, NXobject, name='unknown'):
>     Insert a valid NXobject (NXfield or NXgroup) into the group.
>     If NXobject has a 'name' attribute and the 'name' keyword is not given,
>     then the object is inserted with the NXobject name.


6- I miss an example on how to write slabs of data, and some comment about how 
to do it efficiently. For example, what would be the best (efficient) way of 
implementing the following napi code using the tree api? (specifically, how can 
I keep the handle for both slabs open using the "with statement"?):

+++++++++++++++++++++
import nxs,numpy
xarray = numpy.arange(5)                                                                                                                                                                                                                          
yarray = x**2                                                                                                                                                                                                                                    
f = nxs.open('test.nex', 'w5')                                                                                                                                                                                                                 
f.makegroup('entry', 'NXentry')
f.opengroup('entry')                                                                                                                                                                                                                       
f.makegroup('data', 'NXdata')
f.opengroup('data')
f.makedata('x',dtype='int64', shape=[nxs.UNLIMITED])
f.makedata('y',dtype='int64', shape=[nxs.UNLIMITED])
for i,(sx,sy) in enumerate(zip(xarray, yarray)):
    f.opendata('x')
    f.putslab([sx], i, [1])
    f.closedata()
    f.opendata('y')
    f.putslab([sy], i, [1])
    f.closedata()
f.close()
+++++++++++++++++++++

7- related to the previous question: it would be very useful if the docstrings 
of NXfield.put and .get provided a code example. Also, what does the "refresh" 
keyword argument do in the put method?

8-Some methods (such as NXfield.put or NXgroup.makelink) seem to require that 
the group/field is already saved to a file. This should be explained in the 
documentation of the methods.

9- Finally a suggestion: if the matplotlib plot support is to be kept (I 
remember to having read somewhere that it might be dropped?), then I suggest 
to restrict the dependency to just the matplotlib.pyplot submodule instead of 
using the whole pylab module (I am not sure, but I think that everything that 
the tree api currently uses from matplotlib, actually comes from the pyplot 
submodule). The reason is that in this way it could easily be made also 
compatible with the guiqwt library, which provides its own compatible 
implementation of pyplot (guiqwt.pyplot): 
http://packages.python.org/guiqwt/reference.html


On Wed 9 November 2011 21:29:56 Ray Osborn wrote:
> Dear colleagues,
> I have been working extensively on the Python tree API following the recent
> NeXus code camp at Argonne that involve some major structural changes that
> I think make the code more robust and convenient, so I think it is time to
> get some feedback from other NeXus developers. There are two issues - one
> is whether these changes are the right way to go and the other is how
> backwardly compatible this needs to be. The Python port of NAPI has not
> been changed, so I am only talking about tree.py, which I suspect has not
> been used that much since it is still not officially a part of the NeXus
> distribution. Python is flexible enough that it may be possible to map
> much of the old API onto the new one, but I only want to do that if it is
> really necessary. However, because the changes are so substantial, I have
> not loaded this on to the Subversion server. If I get enough encouragement
> to do this, I am happy to do so. In the meantime, I attach a tar file with
> the nexus subdirectory. I think that if NEXUSLIB is defined then 'import
> nexus' should work if you put the package in your site-packages directory.
> 
> I don't know the schedule for the next NeXus release, but I suspect that we
> won't be able to get this in, but I would really appreciate it if you can
> find the time to check this out, and send some feedback. We may need to
> check for some backward compatibility issues, although Paul and I thought
> it unlikely that many people have been using the tree part of the API. The
> napi part I haven't touched.
> 
> I have tried to document the changes in the docstrings, so the simplest
> thing is probably to read what I have written particularly for the NXfield
> (formerly SDS) and NXgroup classes. I would be interested how the
> documentation looks in doxygen.
> 
> To summarize, the main change is to explicitly place the NeXus items
> (NXfields or NXgroups) within each group into a dictionary named
> 'entries', but to use the __getattr__ and __setattr__ methods to preserve
> the convenience of the direct syntax.
> 
> i.e., In the example below, after assigning the NXgroup, the following four 
NeXus object assignments are all equivalent:
> >>> entry.sample = NXsample()
> >>> entry.sample.entries['temperature'] = NXfield(40.0,name='temperature')
> >>> entry.sample.temperature = NXfield(40.0)
> >>> entry.sample.temperature = 40.0
> 
> There are a few internal Python attributes that have special meaning, e.g., 
'name', 'group', 'path', so if a NeXus NXfield needs to be called 'group', then 
it has to be entered into the 'entries' dictionary explicitly (as in the first 
example above) or using the insert method:
> >>> entry.sample.insert(NXfield(40.0,name='temperature'))
> 
> This saves typing the name twice. The number of such attributes is pretty
> small - at the moment, they are 'name', 'group', 'entries', 'attrs',
> 'dtype','shape', 'link', 'path', and 'head'. I don't think I have seen any
> of those defined within a NeXus NDL file (I'm not sure about 'shape'), but
> it gives us a way of coping with them if there is a name clash.
> 
> This means that we can relax the requirement that all the methods start
> with 'nx'. Now, we have the 'tree' method, instead of 'nxtree'. Only
> 'nxdata' and 'nxaxes' are kept, because they are both common names used in
> NeXus files.
> 
> In particular, the NXfield attributes can have the same name as the
> standard Numpy attributes (e.g., 'reshape', not 'nxreshape').
> 
> Furthermore, we can make is so that all the Numpy ndarray attributes work
> as well, using the __getattr__ again. So now, we can use them like this.
> 
> >>> x=NXfield(np.linspace(0,100.,11),name='x')
> >>> x.size
> 
>        4
> 
> >>> x.sum()
> 
>        10.0
> 
> >>> x.max()
> 
>        4.0
> 
> >>> x.mean()
> 
> Paul also showed me how to cast NXfields as ndarrays, using the __array__
> method, so we can also do other operations.
> 
> >>> np.sin(x)
> 
>        array([ 0.84147098,  0.90929743,  0.14112001, -0.7568025 ])
> 
> I think this gets as close as possible to making NXfields true subclasses
> of ndarrays, without major surgery.
> 
> I have done the same trick with NeXus attributes, which are stored in the
> 'attrs' dictionary, with class NXattr. This make NXgroup attributes work
> the same way as NXfields. In both cases, I think we could recommend that
> anyone writing scripts should use the wordier dictionary assignments to be
> completely safe. The shorter versions are to make it more convenient and
> intuitive for people in an interactive session, and are important, in my
> opinion, to people finding this attractive to use.
> 
> The docstrings are quite extensive, although they are not complete. Let me
> know if there are things that really need further explanation.
> 
> Thanks,
> Ray

-- 
+----------------------------------------------------+
 Carlos Pascual Izarra
 Scientific Software Coordinator
 Computing Division
 Cells / Alba Synchrotron  [http:/www.cells.es]
 Carretera BP 1413 de Cerdanyola-Sant Cugat, Km. 3.3
 E-08290 Cerdanyola del Valles (Barcelona), Spain
 E-mail: cpascual at cells.es
 Phone: +34 93 592 4428
+----------------------------------------------------+

From cpascual at cells.es  Mon Aug 27 10:23:42 2012
From: cpascual at cells.es (Carlos Pascual)
Date: Mon, 27 Aug 2012 11:23:42 +0200
Subject: [Nexus-developers] Python Tree API
In-Reply-To: <83C25D65-8202-4BE1-A10C-62FF6552134F@anl.gov>
References: <83C25D65-8202-4BE1-A10C-62FF6552134F@anl.gov>
Message-ID: <201208271123.42568.cpascual@cells.es>

Hi,
I reply to this old thread because only now I got to play with the tree api 
(using the Nexus 4.3 release). 

First of all, I love the tree api. It makes the life *so* much easier than the 
napi...

Here are some comments/questions/suggestions I have so far:

1- The docstring of the nxs module should mention the napi and the tree api, 
possibly with a summary of both and stating its differences/purposes. This way 
a user doing help(nxs) would learn learn where to start looking for help. It 
could also give a simple example on how to open a NeXus file using each API. 
And It should at least mention the relevant classes whose docstrings may help 
the user in understanding the tree api (e.g., it should recommend to read 
NXgroup and NXfield docstrings)

2- I think that even more stress should be put in recommending the dictionary 
approach to access data (over the member approach) for anything other than 
interactive use. Although it is said several times, many of the examples state 
both methods as "equivalent", or even only use the member access for the 
example. This is calling for users to get annoyed 

3- I find the info provided by the docstrings of NXgroup.save (and .write) 
methods not sufficient. For example, if I want to save to a file incrementally, I 
could start by (e.g.) calling save on an empty NXentry, then inserting 
groups/fields on that NXentry and then calling ".write()" the NXentry when I 
want to make the changes permanent. But it is not clear to me from the 
docstrings whether this will waste time rewriting already written groups/data.

4- How do I make a named link? I would expect a keyword argument to the 
NXgroup.makelink() method

5- Is the "name" keyword of the NXgroup.insert() method actually honored? 
Consider the following code:

++++++++++++++++
import nxs
e = nxs.NXentry()
s = nxs.NXsample(name='some_name')
e.insert(s, name='other_name')
print e.tree  

#this outputs:
#
#entry:NXentry
#  some_name:NXsample
++++++++++++++++

I would expect that the NXsample group would be called 'other_name'. This is 
what I understand from the following phrase in the NXgroup docsting:
> insert(self, NXobject, name='unknown'):
>     Insert a valid NXobject (NXfield or NXgroup) into the group.
>     If NXobject has a 'name' attribute and the 'name' keyword is not given,
>     then the object is inserted with the NXobject name.


6- I miss an example on how to write slabs of data, and some comment about how 
to do it efficiently. For example, what would be the best (efficient) way of 
implementing the following napi code using the tree api? (specifically, how can 
I keep the handle for both slabs open using the "with statement"?):

+++++++++++++++++++++
import nxs,numpy
xarray = numpy.arange(5)                                                                                                                                                                                                                          
yarray = x**2                                                                                                                                                                                                                                    
f = nxs.open('test.nex', 'w5')                                                                                                                                                                                                                 
f.makegroup('entry', 'NXentry')
f.opengroup('entry')                                                                                                                                                                                                                       
f.makegroup('data', 'NXdata')
f.opengroup('data')
f.makedata('x',dtype='int64', shape=[nxs.UNLIMITED])
f.makedata('y',dtype='int64', shape=[nxs.UNLIMITED])
for i,(sx,sy) in enumerate(zip(xarray, yarray)):
    f.opendata('x')
    f.putslab([sx], i, [1])
    f.closedata()
    f.opendata('y')
    f.putslab([sy], i, [1])
    f.closedata()
f.close()
+++++++++++++++++++++

7- related to the previous question: it would be very useful if the docstrings 
of NXfield.put and .get provided a code example. Also, what does the "refresh" 
keyword argument do in the put method?

8-Some methods (such as NXfield.put or NXgroup.makelink) seem to require that 
the group/field is already saved to a file. This should be explained in the 
documentation of the methods.

9- Finally a suggestion: if the matplotlib plot support is to be kept (I 
remember to having read somewhere that it might be dropped?), then I suggest 
to restrict the dependency to just the matplotlib.pyplot submodule instead of 
using the whole pylab module (I am not sure, but I think that everything that 
the tree api currently uses from matplotlib, actually comes from the pyplot 
submodule). The reason is that in this way it could easily be made also 
compatible with the guiqwt library, which provides its own compatible 
implementation of pyplot (guiqwt.pyplot): 
http://packages.python.org/guiqwt/reference.html


On Wed 9 November 2011 21:29:56 Ray Osborn wrote:
> Dear colleagues,
> I have been working extensively on the Python tree API following the recent
> NeXus code camp at Argonne that involve some major structural changes that
> I think make the code more robust and convenient, so I think it is time to
> get some feedback from other NeXus developers. There are two issues - one
> is whether these changes are the right way to go and the other is how
> backwardly compatible this needs to be. The Python port of NAPI has not
> been changed, so I am only talking about tree.py, which I suspect has not
> been used that much since it is still not officially a part of the NeXus
> distribution. Python is flexible enough that it may be possible to map
> much of the old API onto the new one, but I only want to do that if it is
> really necessary. However, because the changes are so substantial, I have
> not loaded this on to the Subversion server. If I get enough encouragement
> to do this, I am happy to do so. In the meantime, I attach a tar file with
> the nexus subdirectory. I think that if NEXUSLIB is defined then 'import
> nexus' should work if you put the package in your site-packages directory.
> 
> I don't know the schedule for the next NeXus release, but I suspect that we
> won't be able to get this in, but I would really appreciate it if you can
> find the time to check this out, and send some feedback. We may need to
> check for some backward compatibility issues, although Paul and I thought
> it unlikely that many people have been using the tree part of the API. The
> napi part I haven't touched.
> 
> I have tried to document the changes in the docstrings, so the simplest
> thing is probably to read what I have written particularly for the NXfield
> (formerly SDS) and NXgroup classes. I would be interested how the
> documentation looks in doxygen.
> 
> To summarize, the main change is to explicitly place the NeXus items
> (NXfields or NXgroups) within each group into a dictionary named
> 'entries', but to use the __getattr__ and __setattr__ methods to preserve
> the convenience of the direct syntax.
> 
> i.e., In the example below, after assigning the NXgroup, the following four 
NeXus object assignments are all equivalent:
> >>> entry.sample = NXsample()
> >>> entry.sample.entries['temperature'] = NXfield(40.0,name='temperature')
> >>> entry.sample.temperature = NXfield(40.0)
> >>> entry.sample.temperature = 40.0
> 
> There are a few internal Python attributes that have special meaning, e.g., 
'name', 'group', 'path', so if a NeXus NXfield needs to be called 'group', then 
it has to be entered into the 'entries' dictionary explicitly (as in the first 
example above) or using the insert method:
> >>> entry.sample.insert(NXfield(40.0,name='temperature'))
> 
> This saves typing the name twice. The number of such attributes is pretty
> small - at the moment, they are 'name', 'group', 'entries', 'attrs',
> 'dtype','shape', 'link', 'path', and 'head'. I don't think I have seen any
> of those defined within a NeXus NDL file (I'm not sure about 'shape'), but
> it gives us a way of coping with them if there is a name clash.
> 
> This means that we can relax the requirement that all the methods start
> with 'nx'. Now, we have the 'tree' method, instead of 'nxtree'. Only
> 'nxdata' and 'nxaxes' are kept, because they are both common names used in
> NeXus files.
> 
> In particular, the NXfield attributes can have the same name as the
> standard Numpy attributes (e.g., 'reshape', not 'nxreshape').
> 
> Furthermore, we can make is so that all the Numpy ndarray attributes work
> as well, using the __getattr__ again. So now, we can use them like this.
> 
> >>> x=NXfield(np.linspace(0,100.,11),name='x')
> >>> x.size
> 
>        4
> 
> >>> x.sum()
> 
>        10.0
> 
> >>> x.max()
> 
>        4.0
> 
> >>> x.mean()
> 
> Paul also showed me how to cast NXfields as ndarrays, using the __array__
> method, so we can also do other operations.
> 
> >>> np.sin(x)
> 
>        array([ 0.84147098,  0.90929743,  0.14112001, -0.7568025 ])
> 
> I think this gets as close as possible to making NXfields true subclasses
> of ndarrays, without major surgery.
> 
> I have done the same trick with NeXus attributes, which are stored in the
> 'attrs' dictionary, with class NXattr. This make NXgroup attributes work
> the same way as NXfields. In both cases, I think we could recommend that
> anyone writing scripts should use the wordier dictionary assignments to be
> completely safe. The shorter versions are to make it more convenient and
> intuitive for people in an interactive session, and are important, in my
> opinion, to people finding this attractive to use.
> 
> The docstrings are quite extensive, although they are not complete. Let me
> know if there are things that really need further explanation.
> 
> Thanks,
> Ray

-- 
+----------------------------------------------------+
 Carlos Pascual Izarra
 Scientific Software Coordinator
 Computing Division
 Cells / Alba Synchrotron  [http:/www.cells.es]
 Carretera BP 1413 de Cerdanyola-Sant Cugat, Km. 3.3
 E-08290 Cerdanyola del Valles (Barcelona), Spain
 E-mail: cpascual at cells.es
 Phone: +34 93 592 4428
+----------------------------------------------------+

From cpascual at cells.es  Mon Sep 10 12:22:45 2012
From: cpascual at cells.es (Carlos Pascual)
Date: Mon, 10 Sep 2012 13:22:45 +0200
Subject: [Nexus-developers] PyTree: NXfield should give morere control over
	compression
Message-ID: <201209101322.46185.cpascual@cells.es>


Hello,

I see that the NXfield object "automagically" chooses compression if the set is 
large (checking if np.prod(shape) > 10000).

This has two problems for me:
a) It will never compress an "extendable" field, regardless of the dimnension. 
(e.g. consider a field with shape=[nxs.UNLIMITED, 1000,1000]). Note that 
nxs.UNLIMITED=-1

b) The automatic choice of the slab_dims ("chunk size" in the napi lingo) may 
not always be the optimal one. For example, if I am writing data from a 
800x600 camera during a 100 points scan, my field will have shape [100,800,600] 
and I want the slab_dims to be [1,800,600]since all I/O is naturally done one 
image at a time. The current implementation of NXfield would choose [1,1,600] 
instead, which is less performant.

To fix these two issues, I propose to add a slab_dims property to the NXfield 
object. If this property is not set (or set to None), everything stays as 
before. But if the user sets it, it is used when calling to the write() method 
of NXfield.

Please find attached my implementation. I did it as a derived class but I 
suggest to modify the code of NXfield itself, except maybe for the constructor 
part (which would make it easier to use, but it also would add another 
reserved keyword)

Cheers,

Carlos

-- 
+----------------------------------------------------+
 Carlos Pascual Izarra
 Scientific Software Coordinator
 Computing Division
 Cells / Alba Synchrotron  [http:/www.cells.es]
 Carretera BP 1413 de Cerdanyola-Sant Cugat, Km. 3.3
 E-08290 Cerdanyola del Valles (Barcelona), Spain
 E-mail: cpascual at cells.es
 Phone: +34 93 592 4428
+----------------------------------------------------+
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nxfieldcomp.py
Type: text/x-python
Size: 2278 bytes
Desc: not available
URL: <http://lists.nexusformat.org/pipermail/nexus-developers/attachments/20120910/688c9ebe/attachment.py>

From Mark.Koennecke at psi.ch  Tue Sep 18 17:59:43 2012
From: Mark.Koennecke at psi.ch (Koennecke Mark)
Date: Tue, 18 Sep 2012 18:59:43 +0200
Subject: [Nexus-developers] NeXus Manula Build 18:00
Message-ID: <843B3B802BEE5C488FFED106C895EE9E06C03977@MAILBOX0A.psi.ch>



The latest manual build ....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nxmanual.pdf
Type: application/pdf
Size: 2275381 bytes
Desc: nxmanual.pdf
URL: <http://lists.nexusformat.org/pipermail/nexus-developers/attachments/20120918/af4aebb4/attachment-0001.pdf>

From Tobias.Richter at diamond.ac.uk  Wed Sep 19 14:54:42 2012
From: Tobias.Richter at diamond.ac.uk (Tobias.Richter at diamond.ac.uk)
Date: Wed, 19 Sep 2012 13:54:42 +0000
Subject: [Nexus-developers] For multi dim axis discussion
Message-ID: <4669C175DBA03A4981471A4B07FEC37447AF6786@EXCHMBX03.fed.cclrc.ac.uk>

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

 







-------------- next part --------------
A non-text attachment was scrubbed...
Name: 02axes.pdf
Type: application/pdf
Size: 15229 bytes
Desc: 02axes.pdf
URL: <http://lists.nexusformat.org/pipermail/nexus-developers/attachments/20120919/f0840f91/attachment.pdf>

From sole at esrf.fr  Wed Sep 19 21:41:27 2012
From: sole at esrf.fr (V. Armando Sole)
Date: Wed, 19 Sep 2012 22:41:27 +0200
Subject: [Nexus-developers] For multi dim axis discussion
In-Reply-To: <4669C175DBA03A4981471A4B07FEC37447AF6786@EXCHMBX03.fed.cclrc.ac.uk>
References: <4669C175DBA03A4981471A4B07FEC37447AF6786@EXCHMBX03.fed.cclrc.ac.uk>
Message-ID: <8237053ee0d3db0caa7e8c64dc1a41dc@esrf.fr>

Hi Tobias,

If besides the signal attribute, you add the (already approved) 
interpretation attribute, you can resolve some of the ambiguities.

For instance, a dimension [n, m, 100, 100] with attribute 
interpretation="image" already allows you to understand that you are 
dealing with nxm images of 100x100 and, even if your software is unable 
to provide an adequate multidimensional visualization, at least it will 
be able to show images providing the coordinates associated to n and m 
indexes.

Armando


On 19.09.2012 15:54, 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


From Tobias.Richter at diamond.ac.uk  Thu Sep 20 01:12:49 2012
From: Tobias.Richter at diamond.ac.uk (Tobias.Richter at diamond.ac.uk)
Date: Thu, 20 Sep 2012 00:12:49 +0000
Subject: [Nexus-developers] For multi dim axis discussion
In-Reply-To: <8237053ee0d3db0caa7e8c64dc1a41dc@esrf.fr>
References: <4669C175DBA03A4981471A4B07FEC37447AF6786@EXCHMBX03.fed.cclrc.ac.uk>,
 <8237053ee0d3db0caa7e8c64dc1a41dc@esrf.fr>
Message-ID: <u12ufen8y60948pps07dgrt2.1348099671350@email.android.com>

Hi Armando,

Yes, we're doing that. I just left it out of the example (likewise with units) to keep the amount of characters at a level digestible in one sitting. And it is not too closely related to the axis.
But we both agree that the use of "interpretation" should be promoted.

Tobias


Sent from a portable device.

"V. Armando Sole" <sole at esrf.fr> wrote:
Hi Tobias,

If besides the signal attribute, you add the (already approved)
interpretation attribute, you can resolve some of the ambiguities.

For instance, a dimension [n, m, 100, 100] with attribute
interpretation="image" already allows you to understand that you are
dealing with nxm images of 100x100 and, even if your software is unable
to provide an adequate multidimensional visualization, at least it will
be able to show images providing the coordinates associated to n and m
indexes.

Armando


On 19.09.2012 15:54, 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

_______________________________________________
NeXus-developers mailing list
NeXus-developers at nexusformat.org
http://lists.nexusformat.org/mailman/listinfo/nexus-developers

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





From ROsborn at anl.gov  Thu Sep 20 06:38:40 2012
From: ROsborn at anl.gov (Ray Osborn)
Date: Thu, 20 Sep 2012 07:38:40 +0200
Subject: [Nexus-developers] For multi dim axis discussion
In-Reply-To: <4669C175DBA03A4981471A4B07FEC37447AF6786@EXCHMBX03.fed.cclrc.ac.uk>
References: <4669C175DBA03A4981471A4B07FEC37447AF6786@EXCHMBX03.fed.cclrc.ac.uk>
Message-ID: <C019F845-7880-4C71-979B-05821234895D@anl.gov>

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





From Tobias.Richter at diamond.ac.uk  Thu Sep 20 07:41:03 2012
From: Tobias.Richter at diamond.ac.uk (Tobias.Richter at diamond.ac.uk)
Date: Thu, 20 Sep 2012 06:41:03 +0000
Subject: [Nexus-developers] For multi dim axis discussion
In-Reply-To: <C019F845-7880-4C71-979B-05821234895D@anl.gov>
References: <4669C175DBA03A4981471A4B07FEC37447AF6786@EXCHMBX03.fed.cclrc.ac.uk>,
 <C019F845-7880-4C71-979B-05821234895D@anl.gov>
Message-ID: <4669C175DBA03A4981471A4B07FEC37447AF6D01@EXCHMBX03.fed.cclrc.ac.uk>

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

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

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.

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.

Kind regards,

Tobias

________________________________________
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
 





From rosborn at anl.gov  Thu Sep 20 08:19:32 2012
From: rosborn at anl.gov (Ray Osborn)
Date: Thu, 20 Sep 2012 09:19:32 +0200
Subject: [Nexus-developers] For multi dim axis discussion
In-Reply-To: <4669C175DBA03A4981471A4B07FEC37447AF6D01@EXCHMBX03.fed.cclrc.ac.uk>
References: <4669C175DBA03A4981471A4B07FEC37447AF6786@EXCHMBX03.fed.cclrc.ac.uk>,
 <C019F845-7880-4C71-979B-05821234895D@anl.gov>
 <4669C175DBA03A4981471A4B07FEC37447AF6D01@EXCHMBX03.fed.cclrc.ac.uk>
Message-ID: <04ECC4CC-F6A7-49EE-A311-8CCE8C3553DC@anl.gov>

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





From prjemian at gmail.com  Thu Sep 20 09:38:55 2012
From: prjemian at gmail.com (Pete Jemian)
Date: Thu, 20 Sep 2012 03:38:55 -0500
Subject: [Nexus-developers] For multi dim axis discussion
In-Reply-To: <04ECC4CC-F6A7-49EE-A311-8CCE8C3553DC@anl.gov>
References: <4669C175DBA03A4981471A4B07FEC37447AF6786@EXCHMBX03.fed.cclrc.ac.uk>,
 <C019F845-7880-4C71-979B-05821234895D@anl.gov>
 <4669C175DBA03A4981471A4B07FEC37447AF6D01@EXCHMBX03.fed.cclrc.ac.uk>
 <04ECC4CC-F6A7-49EE-A311-8CCE8C3553DC@anl.gov>
Message-ID: <505AD61F.6010006@gmail.com>



On 9/20/2012 2:19 AM, Ray Osborn wrote:
> 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.
>>

Ray:

It is very possible that you and others misunderstand this point.

The canSAS forum is fully independent of NeXus and makes its own 
decisions based on its own schedule and purposes.  NeXus chooses to 
support a larger, more diverse community.  CanSAS is highly focused on 
more specific goals for small-angle scattering.  In recent years, canSAS 
considers NeXus and compatibility with the NeXus format and that is a 
new activity; previously, no such interest existed.  To the extent that 
the NeXus hierarchy fits (either now or as suggestions for future 
change) the view of the canSAS community's interest in representing data 
for analyses, there is a positive benefit to NeXus from repeating the 
debates.  Part of the debate in various communities I've seen (APS, 
canSAS, workshop at DESY) is that the data model and its description is 
not an obvious perfect fit, otherwise the debate would be abbreviated.

Do not regret the actions of canSAS.  At worst, they are helpful to NeXus.

Pete

From cpascual at cells.es  Thu Sep 20 11:24:00 2012
From: cpascual at cells.es (Carlos Pascual)
Date: Thu, 20 Sep 2012 12:24:00 +0200
Subject: [Nexus-developers] For multi dim axis discussion
In-Reply-To: <4669C175DBA03A4981471A4B07FEC37447AF6786@EXCHMBX03.fed.cclrc.ac.uk>
References: <4669C175DBA03A4981471A4B07FEC37447AF6786@EXCHMBX03.fed.cclrc.ac.uk>
Message-ID: <201209201224.00505.cpascual@cells.es>


I welcome the proposal for change, especially the moving of the "plot 
description information" (i.e what currently is in @signal, @axes ...and 
possibly @interpretation??)  from the datasets to the NXdata group.

I just have the following suggestion:

1.- I would extend the @signal attribute of the NXdata to a comma (or colon)-  
separated list of dataset names. This way several signals can be pltted 
simultaneously (Roy rightly pointed that this would not be possible in the 
CanSAS example).


-- 
+----------------------------------------------------+
 Carlos Pascual Izarra
 Scientific Software Coordinator
 Computing Division
 Cells / Alba Synchrotron  [http:/www.cells.es]
 Carretera BP 1413 de Cerdanyola-Sant Cugat, Km. 3.3
 E-08290 Cerdanyola del Valles (Barcelona), Spain
 E-mail: cpascual at cells.es
 Phone: +34 93 592 4428
+----------------------------------------------------+

From sole at esrf.fr  Thu Sep 20 11:28:59 2012
From: sole at esrf.fr (V. Armando Sole)
Date: Thu, 20 Sep 2012 12:28:59 +0200
Subject: [Nexus-developers] For multi dim axis discussion
In-Reply-To: <201209201224.00505.cpascual@cells.es>
References: <4669C175DBA03A4981471A4B07FEC37447AF6786@EXCHMBX03.fed.cclrc.ac.uk>
 <201209201224.00505.cpascual@cells.es>
Message-ID: <8e9651db44ff96d64ceb5920777141a4@esrf.fr>



On 20.09.2012 12:24, Carlos Pascual wrote:
> I just have the following suggestion:
>
> 1.- I would extend the @signal attribute of the NXdata to a comma (or
> colon)-
> separated list of dataset names. This way several signals can be 
> pltted
> simultaneously (Roy rightly pointed that this would not be possible 
> in the
> CanSAS example).

I would just make signal="1", signal="2", signal="3", ...

Armando

From rosborn at anl.gov  Thu Sep 20 11:43:29 2012
From: rosborn at anl.gov (Ray Osborn)
Date: Thu, 20 Sep 2012 12:43:29 +0200
Subject: [Nexus-developers] For multi dim axis discussion
In-Reply-To: <8e9651db44ff96d64ceb5920777141a4@esrf.fr>
References: <4669C175DBA03A4981471A4B07FEC37447AF6786@EXCHMBX03.fed.cclrc.ac.uk>
 <201209201224.00505.cpascual@cells.es>
 <8e9651db44ff96d64ceb5920777141a4@esrf.fr>
Message-ID: <50DEBFAA-5C9B-4BD1-9BAE-F319E319256B@anl.gov>


On Sep 20, 2012, at 12:28 PM, V. Armando Sole wrote:

> 
> I would just make signal="1", signal="2", signal="3", ...
> 
> Armando

Unfortunately, that's not an option with the new scheme. The signal attribute has to have the value of the signal data since it is no longer an attribute of the signal field. Carlos' suggestion would allow multiple fields to be specified, and we already parse the axes attribute in this way.

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





From sole at esrf.fr  Thu Sep 20 11:57:32 2012
From: sole at esrf.fr (V. Armando Sole)
Date: Thu, 20 Sep 2012 12:57:32 +0200
Subject: [Nexus-developers] For multi dim axis discussion
In-Reply-To: <50DEBFAA-5C9B-4BD1-9BAE-F319E319256B@anl.gov>
References: <4669C175DBA03A4981471A4B07FEC37447AF6786@EXCHMBX03.fed.cclrc.ac.uk>
 <201209201224.00505.cpascual@cells.es>
 <8e9651db44ff96d64ceb5920777141a4@esrf.fr>
 <50DEBFAA-5C9B-4BD1-9BAE-F319E319256B@anl.gov>
Message-ID: <980d81d43d585bd850e0f92d0925a43a@esrf.fr>

On 20.09.2012 12:43, Ray Osborn wrote:
> On Sep 20, 2012, at 12:28 PM, V. Armando Sole wrote:
>
>>
>> I would just make signal="1", signal="2", signal="3", ...
>>
>> Armando
>
> Unfortunately, that's not an option with the new scheme. The signal
> attribute has to have the value of the signal data since it is no
> longer an attribute of the signal field. Carlos' suggestion would
> allow multiple fields to be specified, and we already parse the axes
> attribute in this way.
>


Sorry, it seems I have missed something that must have been discussed 
somewhere:

If a dataset in an NXdata has an attribute signal="1", why other 
dataset in the same NXdata group have an attribute signal="2"?

Armando

From ROsborn at anl.gov  Thu Sep 20 12:01:26 2012
From: ROsborn at anl.gov (Ray Osborn)
Date: Thu, 20 Sep 2012 13:01:26 +0200
Subject: [Nexus-developers] For multi dim axis discussion
In-Reply-To: <980d81d43d585bd850e0f92d0925a43a@esrf.fr>
References: <4669C175DBA03A4981471A4B07FEC37447AF6786@EXCHMBX03.fed.cclrc.ac.uk>
 <201209201224.00505.cpascual@cells.es>
 <8e9651db44ff96d64ceb5920777141a4@esrf.fr>
 <50DEBFAA-5C9B-4BD1-9BAE-F319E319256B@anl.gov>
 <980d81d43d585bd850e0f92d0925a43a@esrf.fr>
Message-ID: <F721D056-C0DE-4343-85C5-8FA4884ED4C1@anl.gov>


On Sep 20, 2012, at 12:57 PM, V. Armando Sole wrote:

> 
> Sorry, it seems I have missed something that must have been discussed somewhere:
> 
> If a dataset in an NXdata has an attribute signal="1", why other dataset in the same NXdata group have an attribute signal="2"?

Because the new proposal is to make this an NXdata group attribute, i.e., not attached to the signal itself.

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





From sole at esrf.fr  Thu Sep 20 12:06:19 2012
From: sole at esrf.fr (V. Armando Sole)
Date: Thu, 20 Sep 2012 13:06:19 +0200
Subject: [Nexus-developers] For multi dim axis discussion
In-Reply-To: <F721D056-C0DE-4343-85C5-8FA4884ED4C1@anl.gov>
References: <4669C175DBA03A4981471A4B07FEC37447AF6786@EXCHMBX03.fed.cclrc.ac.uk>
 <201209201224.00505.cpascual@cells.es>
 <8e9651db44ff96d64ceb5920777141a4@esrf.fr>
 <50DEBFAA-5C9B-4BD1-9BAE-F319E319256B@anl.gov>
 <980d81d43d585bd850e0f92d0925a43a@esrf.fr>
 <F721D056-C0DE-4343-85C5-8FA4884ED4C1@anl.gov>
Message-ID: <12307551ca4e0f57cc5f4d14d55e39e6@esrf.fr>



On 20.09.2012 13:01, Ray Osborn wrote:
> On Sep 20, 2012, at 12:57 PM, V. Armando Sole wrote:
>
>>
>> Sorry, it seems I have missed something that must have been 
>> discussed somewhere:
>>
>> If a dataset in an NXdata has an attribute signal="1", why other 
>> dataset in the same NXdata group have an attribute signal="2"?
>
> Because the new proposal is to make this an NXdata group attribute,
> i.e., not attached to the signal itself.
>


Ok, understood: That allows the same dataset to be used at two NXdata 
groups without data duplication or name conflicts.

Armando

From Tobias.Richter at diamond.ac.uk  Thu Sep 20 12:08:29 2012
From: Tobias.Richter at diamond.ac.uk (Tobias.Richter at diamond.ac.uk)
Date: Thu, 20 Sep 2012 11:08:29 +0000
Subject: [Nexus-developers] For multi dim axis discussion
In-Reply-To: <F721D056-C0DE-4343-85C5-8FA4884ED4C1@anl.gov>
References: <4669C175DBA03A4981471A4B07FEC37447AF6786@EXCHMBX03.fed.cclrc.ac.uk>
 <201209201224.00505.cpascual@cells.es>
 <8e9651db44ff96d64ceb5920777141a4@esrf.fr>
 <50DEBFAA-5C9B-4BD1-9BAE-F319E319256B@anl.gov>
 <980d81d43d585bd850e0f92d0925a43a@esrf.fr>,
 <F721D056-C0DE-4343-85C5-8FA4884ED4C1@anl.gov>
Message-ID: <6yrtw0kkc4gu7tbkuacotrnr.1348139147687@email.android.com>

Something like @signal=2 isn't defined. In the current way of working you have a second NXdata group. Otherwise you run into problems mapping axes anyway, for example when some axes are detector specific.
Links are cheap.

Tobias


Sent from a portable device.

Ray Osborn <ROsborn at anl.gov> wrote:

On Sep 20, 2012, at 12:57 PM, V. Armando Sole wrote:

>
> Sorry, it seems I have missed something that must have been discussed somewhere:
>
> If a dataset in an NXdata has an attribute signal="1", why other dataset in the same NXdata group have an attribute signal="2"?

Because the new proposal is to make this an NXdata group attribute, i.e., not attached to the signal itself.

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




_______________________________________________
NeXus-developers mailing list
NeXus-developers at nexusformat.org
http://lists.nexusformat.org/mailman/listinfo/nexus-developers

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





From ROsborn at anl.gov  Thu Sep 20 12:12:13 2012
From: ROsborn at anl.gov (Ray Osborn)
Date: Thu, 20 Sep 2012 13:12:13 +0200
Subject: [Nexus-developers] For multi dim axis discussion
In-Reply-To: <505AF8C0.2080403@gmail.com>
References: <4669C175DBA03A4981471A4B07FEC37447AF6786@EXCHMBX03.fed.cclrc.ac.uk>
 <201209201224.00505.cpascual@cells.es>
 <8e9651db44ff96d64ceb5920777141a4@esrf.fr>
 <50DEBFAA-5C9B-4BD1-9BAE-F319E319256B@anl.gov>
 <980d81d43d585bd850e0f92d0925a43a@esrf.fr>
 <F721D056-C0DE-4343-85C5-8FA4884ED4C1@anl.gov> <505AF8C0.2080403@gmail.com>
Message-ID: <7256DB99-1BD9-4992-B175-34E5DC1EBF85@anl.gov>

Sure, we could still do that, but I understand that the whole point of the new scheme is to remove attributes from the datasets themselves so that they (the datasets) can be used differently in different NXdata groups. 

Ray

On Sep 20, 2012, at 1:06 PM, Pete Jemian wrote:

> 
> Isn't Armando's question about the signal="2" attribute on a dataset within the NXdata?  That's a design that has been in NeXus for a long time.
> 
> On 9/20/2012 6:01 AM, Ray Osborn wrote:
>> 
>> On Sep 20, 2012, at 12:57 PM, V. Armando Sole wrote:
>> 
>>> 
>>> Sorry, it seems I have missed something that must have been discussed somewhere:
>>> 
>>> If a dataset in an NXdata has an attribute signal="1", why other dataset in the same NXdata group have an attribute signal="2"?
>> 
>> Because the new proposal is to make this an NXdata group attribute, i.e., not attached to the signal itself.
>> 
>> Ray
>> 

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





From cpascual at cells.es  Thu Sep 20 12:32:24 2012
From: cpascual at cells.es (Carlos Pascual)
Date: Thu, 20 Sep 2012 13:32:24 +0200
Subject: [Nexus-developers] For multi dim axis discussion
In-Reply-To: <7256DB99-1BD9-4992-B175-34E5DC1EBF85@anl.gov>
References: <4669C175DBA03A4981471A4B07FEC37447AF6786@EXCHMBX03.fed.cclrc.ac.uk>
 <505AF8C0.2080403@gmail.com> <7256DB99-1BD9-4992-B175-34E5DC1EBF85@anl.gov>
Message-ID: <201209201332.24703.cpascual@cells.es>

On Thu 20 September 2012 13:12:13 Ray Osborn wrote:
> the whole point of the
> new scheme is to remove attributes from the datasets themselves so that
> they (the datasets) can be used differently in different NXdata groups.

Yes, that is the whole point

-- 
+----------------------------------------------------+
 Carlos Pascual Izarra
 Scientific Software Coordinator
 Computing Division
 Cells / Alba Synchrotron  [http:/www.cells.es]
 Carretera BP 1413 de Cerdanyola-Sant Cugat, Km. 3.3
 E-08290 Cerdanyola del Valles (Barcelona), Spain
 E-mail: cpascual at cells.es
 Phone: +34 93 592 4428
+----------------------------------------------------+

From freddie.akeroyd at stfc.ac.uk  Thu Oct  4 11:13:54 2012
From: freddie.akeroyd at stfc.ac.uk (freddie.akeroyd at stfc.ac.uk)
Date: Thu, 4 Oct 2012 10:13:54 +0000
Subject: [Nexus-developers] Closing of separate nexus-developers mailing list
Message-ID: <8CB55BA9D873DA42AA26C3BDD72F5628484BB865@EXCHMBX03.fed.cclrc.ac.uk>

At the recent NIAC 2012 meeting it was decided to close the nexus-developers at nexusformat.org mailing list. The members of this list are a subset of the general nexus at nexusformat.org list and nexus-developers was originally intended for NeXus programming API related matters, but with increased use of directly writing NeXus from HDF5 (e.g. via h5py) a separate list was felt to be no longer required. The presence of the developer list could also lead to confusion about where to post messages concerning e.g. NeXus Application Definitions, which are of more widespread interest than just that list. Though the developer list is now closed to new postings, previous messages can still be accessed via the archive http://lists.nexusformat.org/pipermail/nexus-developers/

Freddie Akeroyd


-- 
Scanned by iCritical.