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:

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

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

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

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).

# 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

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.