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
>