Storing repeating structures

Mark.Koennecke koenneck at psi.ch
Tue Nov 2 07:27:08 GMT 1999




On Mon, 1 Nov 1999 C.M.Moreton-Smith at rl.ac.uk wrote:

> 
> 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,

  I did indeed hit this problem. We have an instrument which will collect
  series of PSD frames when the detector electronics becomes
  available(sigh.....). At each frame a couple of values have to be
  stored. In C you would use a struct.

  To my knowledge there is no way to have arrays of vGroups either in HDF4
  nor in HDF 5. I'am not so sure about HDF5 though.

  Options available where to have F77 style arrays for each single  value
  to be stored or to have a vGroup per frame.
 
  I choose the vGroup option for two reasons: Each frame represents a
  single measurement. The structure of NeXus files required some data
  to be stored in different vGroups: i.e PSD data in NXdata, NXinstrument,
  NXdetector, sample data in NXsample etc. The vGroup option allowed to 
  preserve this structure. I also feel that the addition of an artifical
  dimension (frame number) is a bit dodgy especially if we consider 
  automatic data analysis.  

  I have a counter for the number of the frames available as a data item 
  in the first vGroup.    

  No, I did not solve the 2 dimensional problem. But what is that really?
  Do you have an example for that case?


                                       Mark





More information about the NeXus-developers mailing list