Storing repeating structures

F.A.Akeroyd at rl.ac.uk F.A.Akeroyd at rl.ac.uk
Mon Nov 1 12:50:18 GMT 1999


HDF5 may help ... i haven't read much on it, but the following example seems
to address some of the problems

http://hdf.ncsa.uiuc.edu/HDF5/doc/H5.intro.html#Intro-Examples

The go to "Example 4. Working with compound datatypes"

Freddie 

--
Freddie Akeroyd
ISIS Facility
Rutherford Appleton Laboratory
Chilton, DIDCOT, OX11 OQX, GB


-----Original Message-----
From: C.M.Moreton-Smith at rl.ac.uk [mailto:C.M.Moreton-Smith at rl.ac.uk]
Sent: 01 November 1999 11:31
To: napi at anl.gov
Subject: Storing repeating structures


This is an issue which has been left on one side for a while but which is
becoming fairly critical when I look at translating/storing ISIS instrument
descriptions in a standard way.

As you know, there is no standard way in NeXus of storing an array of record
structures, something which most programming languages including FORTRAN 90
and C will create and use quite easily.  e.g.

main()
{
	/* Define the record structure */
	typedef struct element_struct
	{
		int a;
		float b;
		char c[10];	/* Allocated in the struct */
	} elem;

	elem my_array[100];

	my_array[2].a = 1;
	my_array[55].b = 99.5;
	strcpy(my_array[33].c, "a string");

	/* How do we now store "my_array" in a NeXus file? */
}

The obvious way is to simply do what we do with the "Entry_" Vgroups and
just append the index of the array element creating a set similar but
differently named Vgroups my_array_1, my_array_2 etc.  But what if the array
is declared as a two dimensional array (e.g. in C my_array[25][4])?.  Would
we then write out my_array_23_2 or my_array_2_23.

Also, for a person reading this file, there is no rank information available
and hence without searching for each one, they will not even be able to tell
how many records of this type there are in the file to read.  Tricky if you
are dynamically allocating memory.

Has anyone else come across this problem yet?  Is there a legal method of
storing an array of Vgroups in the underlying HDF which we should be
exposing via the next version of the API?

	Chris

--
Chris Moreton-Smith, Software Development Manager
ISIS Science Instrumentation, CCLRC, Chilton, Didcot, OXON OX11 0QX
Telephone: +44 (0) 1235 446544, Fax: +44 (0) 1235 445720
Email: C.Moreton-Smith at rl.ac.uk



More information about the NeXus-developers mailing list