<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi there,<br>
<br>
Just to clarify my position and that of the ESRF concerning what
Mark has written:<br>
<br>
"""<br>
NeXus-Armando-Light<br>
A better name is required here. The Armando is for Armando Sole who
more or less suggested this<br>
aproach if I read him correctly. This is another version of a
lighter NeXus. I believe the approach<br>
suggested here would formalize a practice of using NeXus which is
common at synchrotron sources. This<br>
version looks like this:<br>
1. Use HDF-5 as a file format<br>
"""<br>
<br>
100 % correct.<br>
<br>
"""<br>
2. Store your data in a simplified hierarchy using NXentry and
NXcollection groups. Apply a lot of<br>
freedom how you do this.<br>
"""<br>
<br>
NXentry mandatory.<br>
NXcollection for anything not dealt with by other NXclass.<br>
<br>
If you want to describe your beamline, then there is a group
(NXinstrument) for that. I would not write it into an NXcollection.<br>
Personally I like how ALBA is generating Nexus files.<br>
<br>
"""<br>
3. Have NXmethod groups at NXentry level which contain links to
those data items required for a<br>
specific use of the file. For example a group NXsas would contain
links to all data items required for<br>
small angle scattering analysis. The content of the NXmethod groups
can be derived from the<br>
existing application definitions. Just flatten the application
definition hierarchy and resolve name<br>
conflicts by prefixing.<br>
"""<br>
<br>
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.<br>
<br>
What we advocate is, for instance:<br>
<br>
/(root)<br>
/whatever_entry_name:<br>
@NX_CLASS:NXentry<br>
start_time<br>
end_time<br>
....<br>
/whatever_entry_name/whatever_group_name:<br>
@NX_CLASS:NXsubentry<br>
definition (string set to the particular technique implemented
helping to understand the rest of the fields in the subentry)<br>
.....<br>
<br>
That approach solves the issue of several techniques under the same
NXentry because you can have several NXsubentry groups. <br>
<br>
Our most common case is simultaneous fluorescence-diffraction. That
approach is compliant with NeXus and it is not against any NeXus
philosophy.<br>
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
<a class="moz-txt-link-freetext" href="http://ftp.esrf.fr/pub/scisoft/HDF5FILES/SOLE-HDF5NeXusAndBeyond.pdf">http://ftp.esrf.fr/pub/scisoft/HDF5FILES/SOLE-HDF5NeXusAndBeyond.pdf</a><br>
<br>
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?<br>
<br>
There are several consequences of the "Armando's approach":<br>
<br>
1 - If HDF5 is the format, the NeXus API is not necessary.<br>
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.<br>
3 - The NeXus application definition validation tool is a perfectly
valid tool.<br>
<br>
Other big mistakes are that the NIAC has tried to answer:<br>
<br>
a) how one had to store the data and<br>
b) how one had to analyze them<br>
<br>
<br>
It is our opinion that:<br>
<br>
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) <br>
<br>
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.<br>
<br>
I think NeXus can still play a role:<br>
<br>
1 - Acting as custodian of the community approved application
definitions and providing the corresponding validation tool(s). <br>
2 - Presenting anything else as a set of recommendations.<br>
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.<br>
<br>
Best regards,<br>
<br>
Armando<br>
<br>
On 20/02/2012 16:32, Mark Koennecke wrote:
<blockquote cite="mid:4F42677B.90509@psi.ch" type="cite">Hi, <br>
<br>
as promised at the last tele conference I send a short document
about some views I <br>
have about NeXus and the future of NeXus. It questions many of the
things we have done <br>
so far. So this may be a bit disruptive. My general ideas was to
discuss these topics at <br>
the next NIAC. But I first want your feedback. Depending on this:
<br>
- we can decide to bury the document <br>
- we can improve it to become a framework for discussion at NIAC <br>
<br>
I feel a little uneasy about writing such a document. On the other
hand, if times change <br>
NeXus may need to change too. <br>
<br>
This paper is for NIAC members only. <br>
<br>
Best Regards, <br>
<br>
Mark Koennecke <br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
NeXus-developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:NeXus-developers@nexusformat.org">NeXus-developers@nexusformat.org</a>
<a class="moz-txt-link-freetext" href="http://lists.nexusformat.org/mailman/listinfo/nexus-developers">http://lists.nexusformat.org/mailman/listinfo/nexus-developers</a>
</pre>
</blockquote>
<br>
<br>
</body>
</html>