[Nexus] NeXus - a solution to what is not the real problem ?
Wellenreuther, Gerd
gerd.wellenreuther at desy.de
Wed Mar 10 08:20:55 GMT 2010
Hi Joachim,
Wuttke, Joachim wrote:
> this little example illustrates perfectly my point: at SPHERES, a scan
> consists of several subscans, each stored in a separate file. Each
> subscan contains the two parameters scan_since and subscan_since.
> Therefore, start_time would be ambiguous.
>
> This shows: you cannot unify a raw data format without unifying all
> experimental procedures. Therefore, you will always have different
> flavors of raw data formats at different instruments, just as described
> by Gerd (http://lists.nexusformat.org/pipermail/nexus/2010/000371.html).
Well, I disagree :). Nobody will stop you from saving individual times
for all your subscans. You will not, repeat, will not break NeXus by
saving additional data in your file. It will still be NeXus compliant.
If pushed to the extremes every HDF5-file is NeXus-compliant, as long as
it is not using anything defined by NeXus in a different way.
But of course the aim is to use common fields like start_time,
wavelength, energy, etc.
What I meant with flavor is that e.g. at Soleil the software is assuming
that you do not only follow NeXus, but also some further Soleil-specific
definitions (e.g. about how to find images in a NeXus-file). Of course,
nobody else was using this definitions, so nobody else is able to use
that software. But this is a problem on the software-side. Armando Sole
has demonstrated that you can always interpret any NeXus-file as HDF5,
and let the user decide which data to interpret as a picture. That is a
very safe fallback solution!
So, I can not see why there is a need to "unify all experimental
procedures". Just do what you have ever done. Data for which a sensible
definition in NeXus exists should be written in that field properly.
Everything else can be stored in the NeXus-file, hopefully roughly at
the right place, just under names which are not conflicting with NeXus
(just using a pre- or postfix like _SPHERES should do).
> To be perfectly sincere: effort is not even the main argument. If you offered me
> to do the complete conversion, I fear I would still refuse for esthetic reasons.
> For my taste, the NeXus documentation looks hopelessly bloated. As one
> contributor said today: for my purpose, NeXus would be overkill.
Aesthetic is a hole different can of worms. To you, a solid ASCII-file
appears beautiful (at least that is my impression). From my perspective,
working at the synchrotron, I would have to face working with hundred
thousands of these nice, human-readable files for each mapping. All
containing a couple of counters, and a spectrum of lets say 4096 points.
That is a scientists nightmare, for several reasons:
* you need high performance file systems to be able to do *anything*
with these files
* you waste approximately a factor of 10 in hard drive space for storing
the files
* you have to transform the numeric data into strings during acquisition
time, open a single file, write that data, close the file. This is much
more time consuming than writing HDF5/NeXus. Our experiments are
currently limited by the overhead if we are writing single ASCII-files.
* you have to do the same transformation back again if you want to use
the data - this goes well into the couple of minutes / hours for the
above mentioned example. Using HDF5/NeXus we are talking about seconds.
I hope, you understand my perspective. And, as you might have guessed,
there are a lot of facilities with a lot of instruments each going into
operation in the next years which are facing the same problems!
I can understand your point, though. For you and your users comparing
data from one instrument to others is not a high priority. You just want
to have an easy access to the data, and keep things as simple as they
are now. As long as you can live with the constraints of an isolated
environment everything is fine.
But as you just mentioned, the workload put on you to implement NeXus
itself does not seem to be the actual problem - so maybe you are talking
to the wrong people right now. Who is actually trying to force you to
use NeXus?
Cheers, Gerd
--
Dr. Gerd Wellenreuther
beamline scientist P06 "Hard X-Ray Micro/Nano-Probe"
Petra III project
HASYLAB at DESY
Notkestr. 85
22603 Hamburg
Tel.: + 49 40 8998 5701
More information about the NeXus
mailing list