Suggestions for NAPI and utilities

[Mark Koennecke]

High Tanya, high everyone,

my 2c worth of opinion to tanya's suggestions:

On Mon, 26 Mar 2001, Tanya Maria Riseman wrote:

> ========================================================================
> NXget_slab() and NXput_slab()
>  	I'm not sure of the current definition nor its flexibility.
> 
> 	Say one has 3-D data NXdata mydata(1:K,1:N,1:M). Perhaps one would
> 	like to read/store parts of it in a different rank order than is
> 	natural from the construction of the data. Is this currently possible?
> 
> 	For example, 
> 	NXget_slab( handle, pointer, start=1, size=N, K=3,1:N, M=102)
> 	i.e. sort of...  pointer :== &mydata(3,1:N,102).
> 	where the pointer is to an array of size (1:N).
> 
 Is this in terms of the API:
	start[0] = 3; start[1] = 0; start[2] = 102;
        size[0] =  1; size[1] = N; size[2] = 1;
 ?
 Then it will most certainly work. Note that I start counting at 0.

> ========================================================================
> 	For HDF5 version with file "mounts" (links to groups in external files
>  rather than for groups within the files):
> 
 I looked into the HDF-5 documentation. In there it says:

	Closing the parent unmounts and closes all children.
 
 This means that HDF-5 mounts are transient in nature and are NOT stored
 in the file. Additional files will have to be mounted again each time
 the file is opened. 

 So, what we can have is a special group NXmount which lists the filenames
 to mount and the mount points. But this  would not be HDF-4
 compatible. The latter worries me. Concerning filenames: Anyone out there
 with a good scheme? 

> NXUtar_ball
  
  would need to be a separate program. Could be solved by a shell script
  provided by the instrument scientist.

> NXU_CD_image
> NXU_DVD_image

  Again could be solved by shell scripts provided by the instrument
  scientist. 

> ========================================================================
> 
> Issue: maintaining "mounted" file links when moving NeXus files about.
> (My apologies if these issues have already been addressed.)
> 
  This is a maintainance nightmare which actually is, IMHO, an argument
  against NXmount groups.

> ========================================================================
> 
> 	Add NXspin_rotator (for muon spin rotators and separators) 
>  under NXinstrument for muSR. Muons are 100% polarized and
>  the spin rotator rotated the spin from antiparallel to the momentum
>  towards perpendicular (anywhere from 15 degrees to 90 degrees.)
>  This is similar to NXspin_flipper, as used in neutron scattering.
> 
> ========================================================================
> ========================================================================
> 
> 	Add arrays of names for the dectors, which is useful for
>  instruments with only a few detectors (like "up" "down", "left", "right"
>  and "cup_veto") used in muSR. This is particularly useful for 
>  beamlines where the detectors are frequently re-configured. 
> 
> ========================================================================

  Forward a description of this to Steve Cottrell at ISIS who seems to be
  the editor for muons.
> 
> 	Add a new data type "3vector" which will be 
>  		(value, value, value) 
  Why is an array of three floats not good enough? Own datatypes would
  only be possible in HDF-5, we would loose the HDF-4 NAPI compatibility.

>  NXUremove_origin(handle, pointer, new_coord_system, name, old_origin)
> 
>  NXU_dot_product(handle, pointer, new_coord_system, name1, name2) ?
>  NXU_cross_product(handle, pointer, new_coord_system, name1, name2)? 
> 
>  NXU_3vector_operator(handle,pointer,new_coord_system,name1,"operation", name2)
>  NXU_determinent(handle, scalar, name1, name2, name3)? 
> 
  These utilities belong into a standard matrix package but not into the
  NeXus API, IMHO. What does everybody else think? Should the NeXus API
  be extended to support data analysis? 


		Regards,

			Mark Koennecke