(r1) OVChannelMapping < Main

Main Web>TWikiUsers>MattToups>OVChannelMapping (revision 1) (raw view)~~EditAttach~~
---++ OV Channel Mapping Conventions

There are 4 different numbering conventions used to indicate the 64 "channels" in an OV "module":
   * Pixel #: Hamamatsu labeling physically written on the M64s (1-64).
   * Maroc2 Channel #: Convention used in the Maroc2 and FPGA firmware (0-63). Maroc2# = (64 - Pixel#)
   * UC Strip #: Convention used at the UC to number a strip within a module.
   * MC Strip #: Convention used in the MC ($DOGS_PATH/DCDB/data/Geometry) to number a strip within a module.
There are 2 different numbering conventions used to indicate the 44 (68) "modules" in the OV far (near) detector
   * UC Module #: Convention used by UC to identify a module within the OV far detector hall.
   * MC Module #: Convention used in the MC to identify a module at the far/near detector.
There is another numbering conventiono closely related to, but not exactly the same as, the number of modules
   * pmtboard_u #: Convention used in the data to identify each module AND trigger box in the OV far/near detector.
---++ Data Format

The OV data is stored in a TClonesArray of OVHitInfo objects, each of which contains:

DC::ChNum fChNum; ///&lt; Full channel number (including OV offset, online-based) <br />DC::PMTPixelNum fPMTPixelNum; ///&lt; Full PMT pixel number (including OV offset) <br /><br />UShort_t fStatus; ///&lt; readout status mask <br /><br />DC::DUQ fQ; ///&lt; integrated digitized charge, 0 if not available <br />DC::PE fQPE; ///&lt; # PE correponding to integrated charge, 0 if not available

Bool_t fWasHit; ///&lt; true if signal above threshold and if being read out <br /><br />DC::T_ns fTime; ///&lt; Time of signal <br />DC::T_s fTimeUnix; ///&lt; Unix time of signal

The fChNum variable encodes the channel of the OV signal. *fChNum = DC::OV_CHANNEL_INDEX + 100*(pmtboard_u) + (Maroc2 Channel #)*, where DC::OV_CHANNEL_INDEX = 4000 and is defined in $DOGS_PATH/DCBase/DCEnvironment.h.
---++ Monte Carlo Format

There are 3 separate data classes used to store simulated OV data in DOGS: OVHit, OVHitThInfo, and OVHitInfo.
---+++ OVHit (DCGLG4sim)

The OVHit class is defined in DCEvent/DCEOVHit.hh:

DC::T_ns fHitTime; ///&lt; Time of energy deposition <br />DC::MEV fHitEnergy; ///&lt; Total energy injected (truth with no scintillator physics) <br />UInt_t fHitID; ///&lt; What is this??? Useful??? <br />DC::StripNum fStripNum; ///&lt; Strip Number <br />DC::L_mm fStripZ; ///&lt; Position of energy deposition along strip-axis <br />DC::L_mm fX0; ///&lt; Position of energy deposition in global frame of reference X <br />DC::L_mm fY0; ///&lt; Position of energy deposition in global frame of reference Y <br />DC::L_mm fZ0; ///&lt; Position of energy deposition in global frame of reference Z <br />UInt_t fG4GenerationID; ///&lt; Add generated number in G4

This variable is filled in 3 steps:
   * Strip, module, and detector numbers are retrieved from the MC DB entries in $DOGS_PATH/DCDB/data/Geometry. Then an id is associated to each strip and each module in $DOGS_PATH/DCGLG4sim/src/DCGLG4_Construct_Veto.cc (via G4PVPlacement constructors) as follows: 
      * strip_id = MC strip #
      * module_id = (MC det #)*100 + (MC module #)
   * A GLG4PTSDHit is assigned an ID corresponding to (module_id)*100 + strip_id in $DOGS_PATH/DCGLG4sim/GLG4sim/src/GLG4PTSD.cc.
   * An OVHit object filled with the fStripNum variable corresponding to this ID is added to the GlobalThInfo capsule in $DOGS_PATH/DCGLG4sim/ffs/MyEventAction_DOGS_ETh.cc (and presumably the other "MyEventActions" in the same folder).
In conclusion, DCGLG4sim fills GlobalThInfo with OVHit objects whose fStripNum variable is assigned as *(MC det #)*10000 + (MC module #)*100+(MC strip #)*, where each of these variables is read from the appropriate data file in $DOGS_PATH/DCDB/data/Geometry.
---+++ OVHitThInfo

The OVHitThInfo class is defined in $DOGS_PATH/DCEvent/DCEOVHitThInfo.hh. This class defines an info capsule which is filled during the DC read-out simulation (RoSS). The OV read-out simulation is coded in a function called DoOVRoSS in $DOGS_PATH/DCRoSS/DCRRoSS.cc.

OVHitThInfo objects are filled as follows:
   * The fStripNum variable is retrieved from each OVHit object stored in GlobalThInfo. 
      * Module lengths are decoded from fStripNum via Geo::GetME()-&gt;GetOVMStripLength(Geo::GetME()-&gt;DecodeModuleOV(numStrip)) 
         * These module lengths then affect the attenuation and light propagation corrections which are applied to the MC
      * The fStripNum variable is passed to Calib in 2 separate calls: 
         * Calib::GetME()-&gt;GetMeV2PEOV(myOVH-&gt;GetE(), numStrip) and
         * Calib::GetME()-&gt;OVAttenuation(fiber_l, numStrip), where fiber_l depends on the module length
   * The "hitchan" is determined from fStripNum via *Geo::GetME()-&gt;Strip2Channel(numStrip);* 
      * There are conversions between this "hitchan" and "pixel #" which must be self-consistent. They are called in DoOVRoSS_map_lightdist. 
         * const Pixel pixnum = Geo::GetME()-&gt;DecodePixelOV(hitchan),
         * const PMTNum pmtnum = Geo::GetME()-&gt;DecodePMTOV(hitchan), and
         * const ChNum channel = Geo::GetME()-&gt;DecodeChOV(pmtnum, xpix), where xpix is of the same type as pixnum.
   * The OV pulse info is then added to the FEE PMT pulse repository via FEE::AddOVPulse(), indexed by this "hitchan"
   * Finally, the OVHitThInfo is added via ElectOV::GetME()-&gt;AddOVHitThInfo(), again indexed by this "hitchan"
In conclusion, the OVHitThInfo objects are filled with *Geo::GetME()-&gt;Strip2Channel(* *(MC det #)*10000 + (MC module #)*100+(MC strip #)* <strong>). </strong>In order for DoOVRoSS to function correctly, there are also internal mapping functions and interfaces to Calib which must be maintained.
---+++ OVHitInfo

The OVHitInfo class is defined in $DOGS_PATH/DCEvent/DCEOVHitInfo.hh. This class defines the info capsule which is filled by both the DOGSifier for data and by the DC read-out simulation (RoSS) for MC. For MC, this object is filled in a function called Apply() in $DOGS_PATH/DCRoSS/DCRElectOV.cc.

In this file, OVHitInfo objects are filled as follows:
   * The "hitchan" is retrieved from the pulses in the FEE repository
   * This is converted into a "module number" via Geo::GetME()-&gt;DecodeModuleOV(Geo::GetME()-&gt;Channel2Strip(hitchan)). 
      * These "module numbers" are then used to organize the application of OV readout schemes (including edge strip readout described later)
   * Then, a "LocalStripNumber" is determined from the "hitchan" via Geo::GetME()-&gt;DecodeLocalStripOV(Geo::GetME()-&gt;Channel2Strip(hitchan)). 
      * Readout conditions are then enforced via Geo::GetME()-&gt;GetOVMuLikeNeighbor1(LocalStripNumber)
      * These local strip numbers must correspond to a specific geometry for GetOVMuLikeNeighbor* to function properly (commented in function).
   * For non-edge strip packets, *"hitchan" is propagated directly to the OVHitInfo object* if the readout conditions are satisfied.
   * A separate Trigger Box section simulates the readout of edge strips. The following functions depend on the "module number" obtained via Geo::GetME()-&gt;DecodeModuleOV(Geo::GetME()-&gt;Channel2Strip(hitchan)): 
      * myTrigBox1 = Geo::GetME()-&gt;GetOVMTrigBox(myMod1);
      * ElectOV::LowerLeftEdgeFirmware(Geo::GetME()-&gt;GetOVMTrigChan(myMod1),Geo::GetME()-&gt;GetOVMTrigChan(myMod2))
   * Finally, OVHitInfo objects are created for the edge strip packets. Since edge strip packets are special, we build the final channel as: 
      * chan = DC::OV_CHANNEL_INDEX+100*Geo::GetME()-&gt;GetOVMTrigBox(myMod)+(myMod), where myMod=Geo::GetME()-&gt;DecodeModuleOV(Geo::GetME()-&gt;Channel2Strip(hitchan)).
In conclusion, the OVHitInfo objects for non-edge-strip packets are filled with *Geo::GetME()-&gt;Strip2Channel(* *(MC det #)*10000 + (MC module #)*100+(MC strip #)* <strong>). </strong>On the other hand, edge-strips packets are filled with <strong>DC::OV_CHANNEL_INDEX + 100*Geo::GetME()-&gt;GetOVMTrigBox(Geo::GetME()-&gt;DecodeModuleOV(Geo::GetME()-&gt;Channel2Strip( </strong><strong>Geo::GetME()-&gt;Strip2Channel(</strong><strong>(MC det #)*10000 + (MC module #)*100+(MC strip #))))) + Geo::GetME()-&gt;DecodeModuleOV(Geo::GetME()-&gt;Channel2Strip( </strong> *Geo::GetME()-&gt;Strip2Channel(* *(MC det #)*10000 + (MC module #)*100+(MC strip #)))).*

These are both wrong, as you can verify by comparing with the channel numbering given in the data format above.
---++ Conclusion

There is a lot we need to clean up.

-- Nevis.MattToups - 23 Feb 2011
Topic revision: r1 - 2011-02-24 - MattToups
Main
Webs
ATLAS
DOE
Main
TWiki
Veritas