[Nexus] Re: NXdetector questions, and NXfermi_chopper

[Timothy Kelley]

Mark,

Thanks for the quick response. I think your answer clears things up to a 
large extent. I failed to appreciate that a linear PSD's subelements are 
meant to be implicitly defined. We will consider something along the 
lines of an XSLT to make the relationships explicit.

As for the instrument spec (ARCS.xml), it was a modification of a file 
"NXtofndgs.xml", which was on the nexus swiki. I must have introduced 
some errors in modifying the original, thanks for pointing them out. I'm 
not sure when I can get a revision up, but if anyone else notices 
mistakes in the meantime, we're always happy to improve things.

A question I keep coming back to is, is it considered a violation of 
nexus to have child elements  that are not in the DTD for a given class? 
Will nexus software pass over unexpected elements in silence, or will it 
return an error code?

Regarding NXfermi_chopper, I thought we would want to store a few 
additional things. I don't expect them to come up in routine analysis, 
but they might be important for detailed simulations or instrument 
debugging:
-- an identifier for the particular slit package (on Pharos we could 
load different slit packages onto the same rotor)
-- an identifier for the rotor
-- identifier for the housing/bearing
-- Can the absorbing parts of a slit package ('slats') be of different 
width than the transmitting parts ('slits')? If so, it might be good to 
record that information.
--phasing information? (I.e. time offset. One might ask for both nominal 
and calibrated values here--on Pharos we used to have a formula which 
corrected for things like where the magnetic pick up on the rotor was 
located.
-- presumably <wavelength> means the optimal wavelength for the slit 
package?
-- Is it necessary to record the scattering properties of the slits and 
slats? Or are there a set of unambiguous identifiers like B_4C that 
refer to well-known compositions?

If nexus doesn't care about (ignores) extensions, then it really 
shouldn't matter--we'll just put these things in.

Regards,
Tim

Mark Koennecke wrote:

>Dear Timothy Kelly,
>
>On Mon, 22 Nov 2004, Timothy Kelley wrote:
>
>  
>
>>Hello,
>>
>>I'd like to repost some earlier questions about NX classes. If anyone 
>>can offer any insight, I would appreciate it. If these questions are 
>>meaningless or groundless, or if there is a better place to raise these 
>>questions, please let me know.
>>
>>We are attempting to create a data file template for the ARCS 
>>spectrometer, and encountered some ambiguities in storing metadata. We 
>>want to have no duplication and no implicit definitions of metadata. You 
>>can see a draft version of our data file at:
>>
>>http://wiki.cacr.caltech.edu/danse/index.php/XML_template_for_ARCS_data_files
>>
>>While I had questions about a number of classes, I wanted to start with 
>>just one class: NXdetector.
>>
>>My principle question is, how do we describe a composite detector like a
>>linear PSD. Many of the fields in NXdetector, such as <id>, are
>>presented as arrays of length i.
>>1) Is <id> meant to be an array of the id's of the composite's children?
>>1.a.1) If so, where do I put the id for the detector itself?
>>1.a.2) Does this mean all the other property arrays like gas_pressure
>>are meant to implicitly define the children? Wasn't nexus supposed to
>>get us out of implicitly defining things and into explicitly defining them?
>>1.b) If no, where do I put the children's id's, and why do I need arrays?
>>
>>Or are NXdetectors meant to be nested? This would make
>>the hierarchy clear and lovely, but then why have arrays for everything?
>>
>>    
>>
>  I looked at your description and one of the things which struck me is
>  that the definition you are working from appears to be outdated. The
>  NIAC decided upon base classes which live on the NeXus Swiki. In this
>  for instance user information lives in a NXuser group. I recommend to
>  check your definitions against the base classes on the Swiki.  
>
>  I'am confused by your ID's. What do you need them for? Lacking further
>  information on the instrument I assume that you have some linear PSD 
>  with time resolution. This could look like this:
>  <NXdetector name="bank_name>
>	<data
>	    type="NX_INT32[n_elem,tof]" signal="1" axis="polar_angle,tof"/> 
>        <polar_angle type="NX_FLOAT32[n_elem]" axis="1"/>
>        <time_of_flight type="NX_FLOAT32[tof]" axis="2" units="usec"/>
>	<distance/>
>        .....
>  </NXdetector>
>  n_elem stands for the number of elements, tof for the number of time
>  channels. NeXus is meant to be array based for easier handling. The
>  object NeXus worries about is the dataset and not the detector element.
>  The detector "ID" is implicit in the array subscripts. Having a
>  NXdetector for each detector element within a PSD would be a lot of
>  overhead both in reading and writing.
>
>  Is there a problem with this array based model? Is there something you
>  cannot store in this model?  
>
>  On the other hand if you have another detector bank, for instance a
>  second PSD of a different type or in another position in the instrument, 
>  a second NXdetector would be called for.  
>
>		I hope this helps a little,
>
>			Mark Koennecke
>
>
>
>
>  
>