[Nexus-developers] Application Definition Tutorial

[Mark Koennecke]

Hi,

this is the first draft of the promised tutorial on writing application 
definitions.  As this  is not such a critical document 
I invite one round of comments before I finish this. Writing this got me 
thinking: Reading a standard conforming
NeXus file would be much easier for a data analysis programmer if we 
would be more specific about group names in
application definitions, at  least for the most common case: a single 
entry, single detector file. Let me make some suggestions. First for 
NXentry:

The name of the NXentry group is entry. If there are multiple entries it 
must be something else. The algorithm here is that
a data analysis programmer checks for the presence of entry,NXentry. If 
this is not present, she has to scan the file and
give the looser a choice which data to process.

I suggest a similar scheme for NXdetector (default name=detector) and 
NXdata (default name=data).

The NXinstrument should be easy to find too. Two options:
- Let it be instrument, NXinstrument  and put the name of the instrument 
as a field into NXinstrument
- Pull the name of the instrument down into NXentry; then a programmer 
can read that name and construct the
  path into Nxinstrument from it.
I gravitate to the second option as it is more pleasing when looking at 
the file in hdfview.

More name suggestions:
- sample, NXsample
- control, NXmonitor for the main calibration monitor
- user, NXuser for the main user information

Define more names as needed in application definitions. My point here is 
that I want to make it easy for a data analysis
programmer to construct path strings and use NXopenpath to grab data 
items out of a file for which an application
definition exists. With our current, free, naming scheme a lot of 
scanning would be required:
- first search a NXentry group at root level
- search a NXinstrument, NXdata, NXsample groups at entry level.
- search more classes in NXinstrument

For processed data, I came to think that processed data does not really 
fit into NXdetector, as it is data which has been
derived from detector data but is not really detector data. My idea is 
to simply dump the results of a reduction or analysis into NXdata and 
use NXinstrument and the other groups only to convey additional 
information as needed. Not to forget the NXprocess group which contains 
the program and the parameters which resulted in this processed data 
set. I am not sure
if we ever have been clear about this; thus I seek confirmation before I 
put a section on processed data into the tutorial.

All this is may be something to discuss on our next VC, Wednesday, 18


Best Regards,

          Mark

-------------- next part --------------
A non-text attachment was scrubbed...
Name: NXDLTutorial.pdf
Type: application/pdf
Size: 174166 bytes
Desc: not available
Url : http://lists.nexusformat.org/pipermail/nexus-developers/attachments/20090211/6c1ccdef/attachment-0001.pdf