
On the topic of repeated similar measurements, Mark wrote:

     you are right about the additional I/O overhead. But an additional
     requirement was a facility to mark a frame as invalid to the analysis
     software. For instance if the kryostat turned out to be a heater. This
     means that I had to process each frame individually anyway.

For validation, I would include yet another vector in the NXData, with
boolean valid/invalid flag.

     Another argument is common usage: The expected operation of the
     instrument is like a protein crystallography rotation camera. And these
     people store each frame in a separate file! And the processing software
     works frame by frame as well. (In order to reduce memory requirements)
     So I thought a frame can at least have a entry group of its own.

Hmm, the processing software needs a NeXus reading unit (a subroutine or a filter)
anyway, so you could split frames there.

     In the previous section I mentioned "expected operation": The instrument
     scientist wants to operate the instrument like this. But doubts have
     been raised by people who have to be taken serious that he has not
     enough intensity to do that. Then another option would be to center the 
     PSD on a reflection and just use it for integration. This would make
     each entry completely separate.

If it was just integration, you'd just add them up and write out the
end result---but I agree that it does make sense sometimes to keep
individual frames: we have been using this for statistical checks (if
combined counts in a frame deviate in a statistically meaningful way
up (noise?) or down (reactor power dip?), the frame is rejected).
Another scenario might be that in long-running integration, one can
reject frames in which some other environmental parameter deviated
from the desired value, as you pointed out in the first quoted paragraph.

     And I still feel bad about additional unphysical dimensions which just
     represent frame numbers.....

It would only be unphysical dimension in the 'integration' case---otherwise 
there is some physical iterated variable (temperature, etc). In any case,
there is always _some_ variable that characterizes every frame---whether
a physical quantity or some statistical variable, hidden behind a frame number.
I agree with Ray that it is more consistent to make it explicit rather than
simulate via VGroup names.

			przemek klosowski, Ph.D. <przemek@nist.gov>  (301) 975-6249
			NIST Center for Neutron Research (bldg. 235), E111 
			National Institute of Standards and Technology
			Gaithersburg, MD 20899,      USA
                        .. and for spam extractors, FCC Commisioners' email is: 
			wkennard@fcc.gov,sness@fcc.gov,pmisener@fcc.gov,mpowell@fcc.gov







