Hall A Analyzer

h1. Event Type Handlers

Bob Michaels,     updated March 30, 2016

An Event Type Handler is an Analysis Object which can handle, i.e. process, the data from a set of event types. During the course of an analysis session, each event type handler has its "Init" method called at the start, an "End" method called at the end, and an "Analyze" method called for each event. The Analyze method is given the @THaEvData@ event data.

The base class is @THaEvtTypeHandler@. At the moment, I've written two classes which inherit from this, namely @THaScalerEvtHandler@ and @THaEpicsEvtHandler@, which may be used as examples to write your own. Note that @THaEvtTypeHandler@ inherits from @THaAnalysisObject@, which means it can use the @THaAnalysisObject@ methods such as reading from a database. A database is used by the @THaScalerEvtHandler@, for example.

An event type handler can be added to the analysis by invoking lines like this in your analysis script:

<pre><code class="cpp">

THaScalerEvtHandler *lscaler = new THaScalerEvtHandler("Left","HA scaler event type 140");

gHaEvtHandlers->Add (lscaler);

</code></pre>

In the Init method, your event type handler should create the list of event types to analyze, e.g.

<pre><code class="cpp">

eventtypes.push_back(140);  // what event(s) to look for

</code></pre>

Here are some notes about the usage of the @THaScalerEvtHandler@.

If you are familiar with putting event type 140 scaler data into output trees that has not changed much except that the scaler event handler uses a database file, sometimes referred to as the scaler map file, e.g. ``db_LeftScalevt.dat''. This database defines two things: (1) the map of where the scalers are in VME, and (2) the variables and how they correspond to the slots and channels. The variable names defined in this map file are automatically added to a ROOT tree for just the data from this class. In addition, those variables become global variables in Podd and therefore can be added to the standard ``T'' Tree using the "variable" line in the output definition file (see [[Output]]).

<pre>

# Example of db_LeftScalevt.dat database file

# map line starts with "map".  Then model#, crate, slot, header, mask, norm slot

# If >7 fields it's a norm slot and last 2 are clock chan#, clock frequency

map 1151 1 0 abc00000 ffff0000 1

map 3800 1 2 abc10000 ffff0000 1 7 1024

# variables become global variables and appear in an output tree

# "variable" slot, chan, (1=cnt, 2=rate), variable name, description

variable 2 4 1  TSbcmu1  BCM x1 counts

variable 2 4 2  TSbcmu1r  BCM x1 rate

</pre>

Finally, to do something with scalers that appear with events of type 1 to 14, i.e. triggered by the trigger supervisor, somebody should write a new event type handler. I think that Hall C is doing that.

A note about EPICS data.

The interface to users has not changed, in terms of how to define the EPICS variables and put them into the Podd output. @THaEpicsEvtHandler@ is a permanent member of @THaAnalyzer@ and provides the ROOT output. Even though the mechanism ``under the hood'' is quite different now, the interface and the results are the same.