<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hello Dear NeXus people everywhere !
<p>Just a few comments I thought about when reading some of the ISIS NX
classes, and the recent TAS instrument submission on Swiki/NeXus.
<br>Then I have a few propositions about the maintainance of the NXclasses
and instrument descriptions.
<p>Comments:
<br>--------
<br>First of all, even if I could not attend the NeXus workshop in Pasadena
last September, I'd like to thank all of you who made constructive proposals
both for new and enhanced classe definitions, and also comments about these
classes.
<p>Anyway, I personnally think that no NX class, for any instrument and
instrument component will be definitive. Indeed, all instruments are unique,
even if we may classify them into categories (TAS, TOF, SANS, DIF...).
Most fields in the NX classes will thus cover some instrument, but there
might be instruments that will require particular additional fields (not
covered by existing NX definitions), and on the other hand some NX definitions/fields
that will not apply to an instrument. Thus I think most definitions contain
'optional' definitions, and may rather be understood as examples.
<br>In this view, it would be a never ending story to try to describe THE
triple-axis instrument definition.
<p>Then, I've started to compare one by one all submitted NX classes from
Swiki/NeXus <<A HREF="http://www.neutron.anl.gov:8080/NeXus/5">http://www.neutron.anl.gov:8080/NeXus/5</A>> and from ISIS/NeXus
<<A HREF="http://www.isis.rl.ac.uk/computing/NeXus/">http://www.isis.rl.ac.uk/computing/NeXus/</A>>.
<p>The main difference concerns the positionning. Indeed the position/orientation
inspired from McStas simplifies (and thus makes unneccessary) most the
classes distance/positioning fields. For instance, in the NX aperture,
<distance> is not needed as long as one uses the NXposition from ISIS.
Also, the duplication of many dimension fields in this same class makes
its usage more complicated. Following the ISIS group, it is suggested that
one <size> field is enough.
<p>Perhaps an NXdimension or NXgeometry class could be defined as well
in order to be used for all classes...
<p>On the other hand, some Swiki classes are sometimes more accurate, such
as the NXflipper.
<p>Finally, some classes are poorly defined in both propositions (or only
one sometimes), such as for instance the NXfilter. Perhaps a transmission
table as a function of the wavelength would be nice. What about the thickness/dimensions
?
<p>Now, concerning the NXmonoxtas instrument proposition which is nice
for a start, it should probably be improved by the inclusion for
instance of magnetic fields (a NXmagnet class should be written), in order
to describe spin-echo, magnet environments, etc...
<br>Sometinmes, there are magnets not only around the sample...
<p>Propositions:
<br>--------
<br>* The NX classes definitions (namely the ISIS with the Swiki ones)
should be merged in a 'NeXus/XML version 2' list.
<br>* define a NXgeometry or NXdimension
<br>* define a NXmagnet (eihter with a 3D matrix of B field vectors, or
a formula/model)
<br>* The instrument descriptions should only, whenever possible, be submitted
to Swiki as a list of 'official' NX classes. Only the non-official NX classes
could then be described. This would then enable to understand/visualize
very quickly the structure/content of an instrument.
<p>Question: who should merge definitions ?
<p>Emmanuel FARHI @ ILL.
<br>
<br>
<pre>--
What's up Doc ?
--------------------------------------------
Emmanuel FARHI, <A HREF="http://www.ill.fr/tas/people/Farhi.html">http://www.ill.fr/tas/people/Farhi.html</A> \|/ ____ \|/
CS-Group ILL4/156, Institut Laue-Langevin (ILL) Grenoble ~@-/ oO \-@~
6 rue J. Horowitz, BP 156, 38042 Grenoble Cedex 9,France /_( \__/ )_\
Work :Tel (33/0) 4 76 20 71 35. Fax (33/0) 4 76 20 76 48 \__U_/</pre>
</html>