Difference between revisions of "ROOT Analyzer/Notes"

From HallCWiki
Jump to navigationJump to search
Line 31: Line 31:
  
 
Going with method 1 for now.  I like method 2, but it means more hall C specfic classes.
 
Going with method 1 for now.  I like method 2, but it means more hall C specfic classes.
 +
 +
--[[User:Saw|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.
  
 
[[category:12GeV Software]]
 
[[category:12GeV Software]]

Revision as of 10:25, 13 September 2013

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.

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