[NeXus-committee] Linking NXdata to NXdetector groups

[Peterson, Peter F.]

Freddie asked for a clarification so here it is.  (you should get a fresh cup of coffee before reading this)
 
At MLNSC they store both the traditional counts (for material science and such) and the pulse height spectra (for DAS/DAQ people). At the moment they are stored as two separate NXdata, but in principle could be in the same NXdata with different "signal" attributes. Here is how an abbreviated file looks:
<smarts type="NXinstrument">
  <panel1 type="NXdetector">
    <detector[1:i]/>
    <distance[1:i]/>
    <polar_angle[1:i]/>
    <azimuthal_angle[1:i]/>
  </panel1>
  <panel2 type="NXdetector"/>
  ...
  <panel6 type="NXdetector">
    <detector[k+1:N]
  </panel6>
</smarts>
<sed_tof type="NXdata">
  <data type="INT" signal="1" units="number"/>
  <detector type="INT[1:N]" axis="1" units="number"/>
  <tof type="INT" axis="2" units="100ns"/>
</sed_tof>
<sed_pulseheights type="NXdata">
  <data type="INT" signal="1"/>
  <detector type="INT[1:N]" axis="1" units="number"/>
  <pulse-height 1 type="FLOAT" axis="2" units="raw"/>
</sed_pulseheights>
 
As a quick note for those that don't hang out with DAS/DAQ people enough (you should) the pulse_height is the voltage that comes out of the end of the detector tube and gets fed into the pre-amps to determine when (in the case of having a voltage out of each end) where a neutron was detected. This is a neutron specific example, but the same sort of thing occurs with energy dispersive detectors used with an MCA at an x-ray source.
 
Here the NXdetectors are split up to how they are physically in the instrument while the data is grouped together in order to maintain rectangularness (yes I made up a word). For the moment drop any arguments about units and names (for simple plotting the names don't matter, they are just strings). While things can be linked (the "detector" array in both NXdata), it would be done so only to save space, not to tell where to find more information about the measurement. This was done because we discussed how you don't noticed something is linked unless you actually check if it is linked. Also the parent/source has no knowledge that it is linked. Ray's suggestion of a "link" attribute does solve this problem by advertising that something is a link. The way to work with data stored this way in an analysis package (anything that does more than "simple" plotting) is to load in all of the detector information (positions, orientations, sizes, etc.) then as you read the NXdata you can index into your built up structure using the detector number as the key. Note that the detector number can either be a physical detector (an area detector) or an individual pixel (of a area detector), that is for the file writer to decide. Some of the arguments against this scheme that I have heard are that it is lots of overhead for a single detector (which doesn't really need to have a method of connecting data to the detector) and that detector number is not a "physical" quantity. The answer to this is that any scheme we (a group from MLNSC, IPNS, and UW:Stout) came up with that didn't used detector number was a fabrication that always came down to detector number. The difference is that rather than having implicit parallel arrays this makes the means of being parallel explicit.
 
A quick note about connecting to things in the sample (magnetic field, pressure, etc.): this is similar to the situation of one detector: since there is only one sample (http://www.neutron.anl.gov.:8080/NeXus/6, the NXsample is with a "?", not a "*"), there is no need to tell people which sample the magnetic field is applied to.
 
I hope this clarifies things,
Peter Peterson

________________________________

From: nexus-committee-bounces at anl.gov on behalf of Akeroyd, FA (Freddie) 
Sent: Tue 4/27/2004 7:20 AM
To: 'nexus-committee at anl.gov'
Subject: RE: [NeXus-committee] Linking NXdata to NXdetector groups



> I guess so, but won't you need to provide some way of associating axis
> information within the NXdata group with the parent NXdetector group, such
> as proposed in Proposal 3?
>
>  e.g., how do you link the polar angle with distance in this example?
>
>   <NXinstrument>
>    <NXdetector>
>       <NXdata name="Bank1">
>          <data axes="polar_angle(1:i)">
>          <polar_angle>
>       </NXdata>
>       <NXdata name="Bank2">
>          <data axes="polar_angle(i+1:N)">
>          <polar_angle>
>       </NXdata>
>       <distance(1:N)>
>    </NXdetector>
> </NXinstrument>
>
Ray,

A fair point. When I posted the question about multiple NXdata in a single
NXdetector on the SWIKI http://www.neutron.anl.gov.:8080/NeXus/32 I couldn't
initially think of a good example of it myself, but Peter posted a summary
of one that maybe he can clarify. From reading his text, it would appear the
second NXdata was information from the same detector bank, but which did not
share axes with the first NXdata and so a "splitting mechanism" was not
needed. If such a splitting up of a bank was needed then one way would be to
store separate polar_angle arrays in each NXdata etc. and not have such
arrays in the NXdetector - you would still know to what detector bank they
referred to as the NXdata is within the NXdetector. However if you are
starting to split up polar_angle then there are other arrays that need
splitting up as well so you should probably be looking at having another
NXdetector. 

> > * Proposal 1 is currently the only one that addresses non-detector axes
> in
> > an NXdata group, but the same attribute linking scheme could be applied
> to
> > all the other proposals for non-detector axes. The choice then is still
> > about how and where you store the detector information.
>
> That's true, but then we are explicitly using links to associate data, as
> with Proposal 1.  Proposals 2 and 4 seem to be designed to work without
> links.
>
The SWIKI discussions neglected the issue of non-detector axes in NXdata,
but I think people can be forgiven a bit as the title of the page was
"connecting NXdata with NXdetector" rather than "NXdata with NX*" :-) Though
proposal 4 does state "links are used strictly to save space and not to
convey any information", I was assuming that this referred to the NXdata <->
NXdetector association only and not to all forms of linking; maybe this
could be clarified? As you say, we do need a mechanism that allows
non-detector axes to be linked into NXdata and their source determined.

Regards,

Freddie


_______________________________________________
NeXus-committee mailing list
NeXus-committee at anl.gov
http://www.neutron.anl.gov/mailman/listinfo/nexus-committee