Overview

The RAA processor is a framework designed to tackle one of the problems central to the analysis of SNO data: dealing with correlations between temporally separated events. The way it works can be demonstrated by looking at a Programmable Event Loop (see section 9):-

$return_eof $enabled
$event_limit 0

define event_loop

   call INP           
   if_eof goto ANALYSE_FILE
   call UPK
   call CAL
   call RAA($raa_user_3,$raa_user_1)        
   quit_event

ANALYSE_FILE:
   call RAA
   call FTT
   call ANL
   call OUT

end_def

The system works as follows:-

• The $return_eof $enabled flips a switch which makes the input processor INP return an ``internal EOF'' at the end of each file, including the last one. Normally these are all swallowed up and INP only returns a final ``external EOF'' after the last file which forces SNOMAN into termination phase. If file input is limited by a MAX= option this also generates an internal EOF. However the job limit ($event_limit) acts like an external EOF which is why it is switched off.

• The Programmable Event Loop starts with a call to INP to read the next event.

• When an internal EOF is returned, control passes to the ANALYSE_FILE label.

• Otherwise the unpacker and calibration processors are called as normal.

• The RAA processor is called. In this example RAA is told to apply the two subprocessors 3 and 1, in that order, to the data. RAA has 5 dummy user subprocessors now but will eventually have a set of hardwired set as well. RAA places a copy of the event in a random access file and also keeps a short n-tuple summary record of it in memory.

• After RAA has processed the event, the loop ends and the next event is processed.

• When an internal EOF is reached, control transfers to the second call to RAA. Note that this call does not have a subprocessor list, which is how RAA knows that this is the second call. RAA now calls each of its active subprocessors in turn (3 followed by 1 in this case) to analyse the set of summary records. As these are in memory a multi-pass strategy is not expensive. If really necessary subprocessors can recall the full event from the random access event buffer although this costs time of course.

  One all subprocessors have analysed the summary record set, and possibly marked events that are to be discarded, RAA sends a lock signal to INP and restores the first acceptable event from the buffer.

• Further analysis proceeds, in this case it is just the time fitter and the analyser, on the restored event.

• The event loop ends and begins again. However INP is locked and continues to return the internal EOF so that control passes to the second RAA call. It knows the context and restores the next event from the buffer.

• Eventually the RAA buffer is exhausted at which time RAA unlocks INP and returns a failure. The Programmable Event Loop picks up this failure and proceeds directly to the next event, which results in a call INP which now reads the first event of the next file.

The one weakness of RAA is that it works at a file level and won't properly handle phenomena that straddle file boundaries. In practice this is unlikely to represent a significant problem as the time windows of interest are very small compared with a the time interval of a file.

RAA has two advantages over other multi-pass analyses:-

• The system will work on tape input, other schemes would either involve two passes over the full tape which means storing a great deal of information between passes, or finding some way to backspace the tape to the previous EOF within SNOMAN.

• RAA checks the time ordering of events during input and sorts the summary records into strict time order. This simplifies analysis which does not have to worry about slight time disordering.