Various

[Freddie Akeroyd]

Hello - i've been doing other things this week, but now time to catch up with the
list. I hope those of you going to ICNS have an enjoyabe meeting and find lots
of interest in NeXus.

I've looked through the WWW interface page and downloaded (and built) the
example programs - all is looking fine, but i did spot a couple of minor
errors in the examples (none of which detract from the idea or message they are
trying to get across)

C example:
    The first two NXmakedata should take &n_t and &n_p respectively as their last 
arguments
    The final NXmakedata should end      2, dims    
    NXclose should take &file_id

FORTRAN:
    There is an extra NX_CHAR in the first NXputattr

I think a table for converting C types to FORTRAN types would
be useful to add to the pages somewhere e.g.

-----------------------------------------------
C                                 FORTRAN
-----------------------------------------------
int a, int* a                     INTEGER A
char* a                           CHARACTER*(*) A
NXhandle a, NXhandle* a           INTEGER A(NXHANDLESIZE)
NXstatus                          INTEGER
int[] a                           INTEGER A(*)
void* a                           REAL A(*) or DOUBLE A(*) or INTEGER A(*)
NXlink a, NXlink* a               INTEGER A(NXLINKSIZE)

The parameters NXHANDLESIZE and NXLINKSIZE are defined in NAPIF.INC, which
must be included in any FORTRAN program that uses NeXus

I'm happy with dropping the extra parameters from NXopen, and just writing
version, original filename and NeXus version attributes. I agree with Mark that a 
helper routine that takes all the other mandatory global parameters as 
arguments would be useful and avoid several NXputattr calls

I've no objections to the NXputdata() helper taking a units argument - will it be 
SI only?
All we need then is a package to parse the string and do the conversions for us -
i think i did see one out on the Internet somewhere or does somebody already 
have such a tool? An alternative to having to parse a units string would
be to define a restricted set of units using #define (C) or PARAMETER (Fortran),
then the conversion would be easy to obtain from a lookup table; however this
is far less flexible.

Assuming we take strings of SI units, it would probably be useful to provide
a set of pre-defined string constants in napif.inc/napi.h for common 
non-SI units: these would be passed as arguments to the routine and just 
contain the correct SI units: the routine would never know the difference!

By the way, will there be an NXputslab helper like the NXputdata helper?
Also, can "putdata" be restricted to numerical types i.e. no
multi-dimensional string arrays to worry about!

Using NX_ datatypes instead of DFNT_ datatypes also sounds a good idea.
There is a bit of choice in names though e.g

DFNT_UINT16		NX_UNSIGNED_SHORT or NX_UINT16 ?
DFNT_INT16		NX_SHORT or NX_SHORT_INTEGER or NX_INT16 ?
DFNT_INT32		NX_INTEGER or NX_INT32 ?
DFNT_INT64		NX_LONG or NX_LONG_INTEGER or NX_INT64 ?	! HDF doesn't do this yet, but 
will one day
DFNT_FLOAT32		NX_DOUBLE or NX_FLOAT64 ?

I'm happy with NX_INT32, NX_CHAR etc, which is what Ray used in the example 
programs,
though we should give a table of NeXus -> C and FORTRAN types somewhere e.g.

----------------------------------------------------
NeXus                 C              FORTRAN
----------------------------------------------------
NX_CHAR               char           CHARACTER
NX_INT16              short          INTEGER*2
NX_INT32              int            INTEGER*4
NX_FLOAT32            float          REAL*4
NX_FLOAT64            double         REAL*8

Freddie

-- 
Freddie Akeroyd                        Email:  faa at isise.rl.ac.uk
ISIS Facility                          Tel:    +44 1235 445457   
Rutherford Appleton Laboratory         Fax:    +44 1235 445720   
Chilton,   DIDCOT,   OX11 OQX          WWW:    http://www.isis.rl.ac.uk/
--------------------------------------------------------------------------------
Return-Path: <faa at isise.rl.ac.uk>
Received: from dns2.anl.gov by ipns.pns.anl.gov (MX V4.2 AXP) with SMTP; Thu,
          14 Aug 1997 15:00:32 CST
Received: from osborn.msd.anl.gov (osborn.msd.anl.gov [146.139.244.39]) by
          dns2.anl.gov (8.6.11/8.6.11) with ESMTP id PAA28447 for
          <ROsborn at anl.gov>; Thu, 14 Aug 1997 15:00:31 -0500
Received: from dns2.anl.gov (146.139.254.3) by osborn.msd.anl.gov with SMTP
          (Eudora Internet Mail Server 1.1.2); Thu, 14 Aug 1997 15:00:14 -0500
Received: from isolde.nd.rl.ac.uk (isolde.nd.rl.ac.uk [130.246.49.21]) by
          dns2.anl.gov (8.6.11/8.6.11) with SMTP id PAA28433 for
          <napi at anl.gov>; Thu, 14 Aug 1997 15:00:07 -0500
Received: by isolde.nd.rl.ac.uk; (5.65/1.1.8.2/07Aug95-0902AM) id AA05781; Thu,
          14 Aug 1997 21:00:27 +0100
Message-ID: <9708142000.AA05781 at isolde.nd.rl.ac.uk>