ROOT Analyzer/Notes

Put here random notes and thoughts about the C++ analyzer that don't have another place to go yet. Please preface your notes with a signature/timestamp. (By putting

--~~~~

on a line by itself before your notes.)

Pedestal Events

--Saw 21:24, 17 August 2012 (UTC)

The Hall C DAQ is usually setup to acculumate 1000 (event type 4) pedestal events (trigger by a pulser) before starting to take regular events. How can this be added to the Hall A frame work. In the Hall C ENGINE, all events, including pedestal events are analyzed by g_reconstruction which looks like

 decode raw event
 if(evtype==4)
   accumulate pedestal data
   update_peds = true
   return
 endif
 if(update_peds)
   compute pedestals
   update_peds = false
 endif
 do normal physics event analysis

How can we add pedestal analysis in a clean way? In THcAnalyzer (our version of THaAnalyzer, which doesn't add anything at the moment) add a Set method for the user to declare the pedestal event type. Then in each detector's decode or coarse method, do the above type of analysis, if this event type has been set. Each detector will need to, at a minimum, ignore pedestal events. There may be some methods common to all detectors desired to help with this. Could we use multiple-inheritance? (Each Hall C detector already inherits from both THaNonTrackingDetector and THcHitList.)

--Saw 18:42, 20 August 2012 (UTC)

We will need to modify the event loop in THaAnalyzer.C so that pedestal events are always analyzed, even if the starting event chosen is beyond the first 1000 (pedestal) events.

How do we get the detector methods to know when they should be analyzing pedestal events. 1. Decode or CoarseProcess method can check to see if this is a pedestal event, and then do the appropriate thing for that event type. We need to tell the detector classes the event type for pedestals. Only way I see to do this is through a THcParameter we set in the script. 2. We are going to have to modify the event loop (THaAnalyzer) anyway to know about pedestal events so that the pedestal events always get analyzed, even if we skip events. THaAnalyzer can call a PedestalProcess method instead of CoarseProcess and then call a PedestalCalc method when the pedestal events are done with. Would need to make a THcApparatus that has these pedestal methods as well as the THcDetector base class.

Going with method 1 for now. I like method 2, but it means more hall C specfic classes.

Pedestal Events

--Saw 15:25, 13 September 2013 (UTC)

In ENGINE, there is a correction that accounts for the time of propagation along a drift chamber wire from the hit location to the discriminator. This correction can only be done once one has some kind of x/y information from a space point. In h_pattern_recognition.f, after the space points are found, the code loops over each hit in each space point and applies this propagation correction. If a given hit ends up belonging to two different space points, then this correction will get applied multiple times in a cumulative manner. In hcana (in THcDCHit.h and THcDriftChamber.cxx), we have changed this behaviour. A flag is saved with the hit so that the correction does not get applied more than once. This may be good enough, but the proper thing to do would be save the correction with the space point and not with the hit since the distance along the wire could be different when the hit is in different space points.

Notes on how decoding/hitlists are done

Event decoding for hcana uses the existing Podd decoder to unpack data into the evdata object As in Podd, each detector retrieves its data from evdata in the detectors Decode method. However, the grunt work of going through that detector's fDetMap is not done in the specific detector code, but rather in a call to

   THcHitList::DecodeToHistList.

hcana uses the ENGINE style detector maps. This map is held in a THcDetectorMap object, which is held by the global variable gHcDetectorMap. The map file must be loaded by the user in the analysis script with:

   gHcDetectorMap = new THcDetectorMap();
   gHcDetectorMap->Load( mapfilename );

THcDetectorMap::Load builds an array (fTable) with one structure element per electronics channel. Each element holds the roc, slot, channel number and module type for a given channel. In addition, the element holds the id number of the detector, the plane, the counter (or wire number), the signal number (indicating TDC/ADC, positive or negative) for the physics detector element.

The Load method also looks at the comments to find the mapping between detector names and detector ID numbers. (E.g. HSCIN_ID = 2). So it is important that these comments be up to date.

Hall C detector classes differ from Hall A detector classes in that the inherit from THcHitList as well as THaTrackingDetector. (Perhaps instead, the hitlist stuff should be built into THcTrackingDetector and we don't do multiple inheritance.)

In the Init method of each detector, call call is made to gHcDetectorMap->FillMap(fDetMap, idstring). This will populate THaDetectorBase::fDetMap with the list of channels belonging to that detector. idstring is a string like "HSCIN" and will used with the detector name to id mapping. The FillMap method will read through fTable to find each electronics element belonging to the detector and add it to fDetMap.

The Podd THaDetMap class has been modified to hold the plane and signal types for each channel in the detector map.

Also in the Init method of each detector, a hit list to hold the raw hits for that detector is created. This is done with

THcHitList::InitHitList(fDetMap, rawhitclassname, maxhits); The current choice of raw hit classes is

   THcRawDCHit
   THcRawShowerHit
   THcAerogelHit
   THcCherenkovHit
   THcHodoscopeHit

Each of these classes inherits from the THcRawHit base class.

The Decode method for each detector class starts with

   THcHitList::DecodeToHitList(evdata);