[Nexus] NX tas instrument definition and ISIS NX classes comments

Emmanuel Farhi farhi at ill.fr
Fri Oct 24 13:26:52 BST 2003


Hello Dear NeXus people everywhere !

Just a few comments I thought about when reading some of the ISIS NX classes,
and the recent TAS instrument submission on Swiki/NeXus.
Then I have a few propositions about the maintainance of the NXclasses and
instrument descriptions.

Comments:
--------
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.

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.
In this view, it would be a never ending story to try to describe THE
triple-axis instrument definition.

Then, I've started to compare one by one all submitted NX classes from
Swiki/NeXus <http://www.neutron.anl.gov:8080/NeXus/5> and from ISIS/NeXus
<http://www.isis.rl.ac.uk/computing/NeXus/>.

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.

Perhaps an NXdimension or NXgeometry class could be defined as well in order to
be used for all classes...

On the other hand, some Swiki classes are sometimes more accurate, such as the
NXflipper.

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 ?

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...
Sometinmes, there are magnets not only around the sample...

Propositions:
--------
* The NX classes definitions (namely the ISIS with the Swiki ones)  should be
merged  in a 'NeXus/XML version 2' list.
* define a NXgeometry or NXdimension
* define a NXmagnet (eihter with a 3D matrix of B field vectors, or a
formula/model)
* 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.

Question: who should merge definitions ?

Emmanuel FARHI @ ILL.



--
What's up Doc ?
--------------------------------------------
Emmanuel FARHI, http://www.ill.fr/tas/people/Farhi.html   \|/ ____ \|/
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_/


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.nexusformat.org/pipermail/nexus/attachments/20031024/b2ed15d3/attachment.html 


More information about the NeXus mailing list