NeXus use

[Ray Osborn]

on 2000/7/10 2:52 AM, zlokazov at e21pc164.e21.physik.tu-muenchen.de at
zlokazov at e21pc164.e21.physik.tu-muenchen.de wrote:

> Dear Sir,     Jul 9 2000
> 
> RE:  NeXus use at TU Munich FR II.
> 
> In the e-mail message of 6.5 you wrote: "Let me know how you get on".
> OK, I can comment my preliminary experience in dealing with the NeXus
> format and its software as follows.

I will pass on your comments to the other NeXus developers.  They should be
very useful.

> These are surely only our first steps in adjusting the NeXus programs to
> our purposes.  Still, one can summarize the impressions in the following
> statement:
> All seems to be excelent, and the only points which occur to me as
> delinquencies, can be reduced to these few items:
> 
> 1. Your Makefile is too universal and its editing for the platform
> needed requires too many tries and tests: it seems to me it would be
> better to have a set of makefiles for each specific platform.

I agree that the whole installation process could be refined.  We will look
into that when we next meet.

> 2. The C++ is now commonly acknowledged as the best and most efficient
> language for programming purposes and I considered it necessary to
> edit napi.c and testnx.c for C++ style. As yet I think that 3 sorts
> of corrections are enough to make them compatible with LINUX g++:
> 1) use of C++ key word (class) as variable name is an error.
> 2) implicit conversion from void pointers is no ANSI C++ standard and
> is marked by compiler as an error.

We were aware of the need to avoid the keyword "class" in napi.c, so I think
you will only find it defined within the test programs, which are written in
C rather than C++.  We don't have any plans to provide a specific C++ test
program at the moment unless there is a clear demand for it.

> 3) passing const char * as arguments if it discards qualifiers should
> be avoided; for compiler it is also an error.
> These having been corrected, all the rest seems to be OK.

Please let me know which changes you think are necessary.

> 3. The browser needs to be substantially improved. Now it:
> a) does not allow the user to make entries with names different from
> "NXentry" what certainly is an unacceptable restriction. At the
> same time, while writing a NeXus file, use of coinciding class
> names is not diagnosed as an error;

I'm not sure I understand this point.  NXbrowse.C doesn't do any writing
apart from an ASCII dump of individual SDS's.  What program are you
referring to?
  
> Also steady use of 2 commands (make and open) where logically only
> one action is performed leads to unnecessary program lines.
> It seems to me that it would be better to comply with the standard
> norm of practically all the languages in dealing with objects:
> 
> open an object,  get or put it,  and close the object.
> 
> From your descriptions I didn't sense the necessity to separate
> make and open, and to simplify the program writing I united
> the couple "make, open" in a single procedure, and additionally
> made a procedure for the full cycle of operations with data:
> make, open, write (optionally compressed) and close.
> This, certainly, does not discard your tools, but I think
> that many NeXus users will do the same again and again, unless
> something like this is included in the standard NeXus version.

The NeXus programmers decided to use the model of a unix filesystem for the
NeXus API, i.e. NXmakegroup is equivalent to mkdir, NXopengroup is
equivalent to cd etc.  It is true that this leads to extra lines of code,
but it makes the API both simple and general (e.g. the user may not want to
open immediately every group that s/he creates).  However, I wrote a number
of NXU (utility) routines in the Fortran 90 interface to do the sort of
combined operations that you call for.  These will eventually be ported to C
when we have the time.

> b) does not list the attribute entries;

If this refers to NXbrowse, the attributes are listed after a data item if
it is read without specifying an array index.

> c) uses a too small number of commands, which in addition are not
> those commonly used in such command languages as that of UNIX.

Please let us know what other commands you think are useful.  It would not
be difficult to allow the equivalent unix commands as alternatives, e.g. cd,
ls, cat etc.  My choice of commands was just a matter of taste.  For
example, I preferred to use OPEN to open a group since it seemed to me more
descriptive than CD.  Don't forget that NXbrowse works on Windows, VMS, and
even Macs, so unix conventions are not necessarily appropriate.  However, we
could allow both without too much problem.

> I revised the text of your browser and, to a certain extent, fixed the
> above-mentioned drawbacks; but this is surely only our first approach
> to develop a multi-purpose browser for dealing with the hierarchy of
> NeXus files, which we plan to create in the future.
> 

I would be interested to see whatever you produce.  If you wish, we can add
whatever you produce to the utilities listed on the web pages.  There are a
number of other browser projects underway using java and Tcl/Tk.  These can
all be useful.

> 
> That seems to be all. On the total, as I said, all is up to now OK.
> 

Thank you again for your interest.  We shall take your comments into account
in future developments.

Regards,
Ray Osborn
-- 
Dr Ray Osborn                Tel: +1 (630) 252-9011
Materials Science Division   Fax: +1 (630) 252-7777
Argonne National Laboratory  E-mail: ROsborn at anl.gov
Argonne, IL 60439-4845