Difference: OVChannelMapping (1 vs. 5)

Revision 52011-03-17 - MattToups

Line: 1 to 1
 
META TOPICPARENT name="MattToups"
Added:
>
>

Proposal

Look here for the OVChannelMappingFix.

 

OV Channel Mapping Conventions

There are 5 different numbering conventions used to indicate the 64 "channels" in an OV "module":

Revision 42011-03-02 - MattToups

Line: 1 to 1
 
META TOPICPARENT name="MattToups"

OV Channel Mapping Conventions

Line: 149 to 149
 
    • Strip = (100*module#) + (local strip)
    • module = (100*det#) + detector-specific module
    • The number of channels is between dCH_OFFSET_OV and 2*dCH_OFFSET_OV
Changed:
<
<
    • fStrip2Pixel converts UC strip # to Maroc2 Channel according to Mark's email
>
>
    • As coded, fStrip2Pixel conversion is only valid if input is UC strip # and output is Maroc2 Channel (agrees with Mark's emai).
 
  • This is wrong because
    • There are more PMTs (boards) than (physical) modules and therefore
    • There are more channels than strips
    • The offset that should be used is DC::OV_CHANNEL_INDEX and for this offset the number of OV channels is not between DC::OV_CHANNEL_INDEX and 2*DC::OV_CHANNEL_INDEX.
Changed:
<
<
    • fStrip2Pixel should convert MC strip # to Hammamatsu Pixel #
>
>
    • fStrip2Pixel should convert MC strip # to Hammamatsu Pixel # (or should we get rid of this completely?)
 
    • fStrip2Maroc2 should convert MC strip # to Maroc2 Channel #
  • Implications

  • Revision 32011-03-02 - MattToups

    Line: 1 to 1
     
    META TOPICPARENT name="MattToups"

    OV Channel Mapping Conventions

    Changed:
    <
    <
    There are 4 different numbering conventions used to indicate the 64 "channels" in an OV "module":
    >
    >
    There are 5 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#)
    Changed:
    <
    <
    • UC Strip #: Convention used at the UC to number a strip within a module.
    >
    >
      • This is the "channel number" referenced in Emily's email verifying the MC channel mapping (channelstripMapping.txt -- see attached).
      • This is the "channel number" (offset by 1) referenced in Mark's original email giving the channel mapping (see attached)
    • UC Strip #: Convention used at the UC to identify a number a strip within a module.
      • This is the "strip number" referenced in Mark's original email giving the channel mapping (see attached)
      • This is the "UC strip number" referenced in Emily's email verifying the MC channel mapping (channelstripMapping.txt -- see attached).
      • This is the "strip number" referenced in Arthur's updated channel map he sent around (but didn't update on Doc DB, see attatched).
     
    • MC Strip #: Convention used in the MC ($DOGS_PATH/DCDB/data/Geometry) to number a strip within a module.
    Changed:
    <
    <
    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.
    >
    >
      • This is referenced in Emily's email (channelstripMapping.txt -- see attached).
    • Fiber #: Only used internally by UC.
      • This is referenced in Mark's original email
    It has been verified that the edge strip firmware, which treats Maroc2 channels 0 and 63 differently, maps onto the actual edge strips.

    There are 3 different numbering conventions used to indicate the 44 (68) "modules" in the OV far (near) detector

    • UC Module Position #: 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.
    Added:
    >
    >
    It has been verified by Arthur (before the commits by Matt W.) that the MC module #, Trigbox #, and Trig box channel # matched Camillo's spreadsheet which was used to code the OV firware for the 3 trigger boxes. We must program the address of each pmt board and trigger box according to this spreadsheet for our scheme to be self-consistent.
     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.
    Added:
    >
    >
    There are also numberings related to the extrusion of each strip and the construction of each module, but the mapping between these and the module position # will be maintained by UC via a log book.
     

    Data Format

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

    Line: 136 to 149
     
      • Strip = (100*module#) + (local strip)
      • module = (100*det#) + detector-specific module
      • The number of channels is between dCH_OFFSET_OV and 2*dCH_OFFSET_OV
    Added:
    >
    >
      • fStrip2Pixel converts UC strip # to Maroc2 Channel according to Mark's email
     
    • This is wrong because
      • There are more PMTs (boards) than (physical) modules and therefore
      • There are more channels than strips
      • The offset that should be used is DC::OV_CHANNEL_INDEX and for this offset the number of OV channels is not between DC::OV_CHANNEL_INDEX and 2*DC::OV_CHANNEL_INDEX.
    Added:
    >
    >
      • fStrip2Pixel should convert MC strip # to Hammamatsu Pixel #
      • fStrip2Maroc2 should convert MC strip # to Maroc2 Channel #
     
  • Implications

    • The ChWithinOV and StripWithinOV functions should be separated
    • DCGeo should be able to access and apply the mapping between module # and pmtboard_u.
    • Information about about the detector should be added to the data stream.
    • dCH_OFFSET_OV or DC::OV_CHANNEL_INDEX?
  • Changed:
    <
    <
    • Verify that "pixel" in the DB refers to MAROC2 CHANNEL
    >
    >
    • Disentangle the usage of fStrip2Pixel from fStrip2Maroc2, which must be implemented.
     
    • How should DCCalib access OV data? At the OVHit level?
    • A call to Geo::GetME()->GetOVMTrigChan() should be added to the section of DCRElectoOV where OVHitInfo objects for edge strips packets are created.
    -- MattToups - 23 Feb 2011
    Added:
    >
    >
    META FILEATTACHMENT attachment="MarkEmail.txt" attr="" comment="" date="1299085181" name="MarkEmail.txt" path="MarkEmail.txt" size="813" user="MattToups" version="1"
    META FILEATTACHMENT attachment="channelStripMapping.txt" attr="" comment="" date="1299085181" name="channelStripMapping.txt" path="channelStripMapping.txt" size="1771" user="MattToups" version="1"
    META FILEATTACHMENT attachment="channel_maps.pdf" attr="" comment="" date="1299085181" name="channel_maps.pdf" path="channel_maps.pdf" size="5762" user="MattToups" version="1"

    Revision 22011-03-01 - MattToups

    Line: 1 to 1
     
    META TOPICPARENT name="MattToups"

    OV Channel Mapping Conventions

    Line: 43 to 43
      OVHitThInfo objects are filled as follows:
    • The fStripNum variable is retrieved from each OVHit object stored in GlobalThInfo.
    Changed:
    <
    <
      • Module lengths are decoded from fStripNum via Geo::GetME()->GetOVMStripLength(Geo::GetME()->DecodeModuleOV(numStrip))
    >
    >
      • Module lengths are decoded from fStripNum via Geo::GetME()->GetOVMStripLength(Geo::GetME()->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:
    Changed:
    <
    <
        • Calib::GetME()->GetMeV2PEOV(myOVH->GetE(), numStrip) and
        • Calib::GetME()->OVAttenuation(fiber_l, numStrip), where fiber_l depends on the module length
    >
    >
        • Calib::GetME()->GetMeV2PEOV(myOVH->GetE(), numStrip) and
        • Calib::GetME()->OVAttenuation(fiber_l, numStrip), where fiber_l depends on the module length
     
    • The "hitchan" is determined from fStripNum via Geo::GetME()->Strip2Channel(numStrip);
      • There are conversions between this "hitchan" and "pixel #" which must be self-consistent. They are called in DoOVRoSS_map_lightdist.
    Changed:
    <
    <
        • const Pixel pixnum = Geo::GetME()->DecodePixelOV(hitchan),
        • const PMTNum pmtnum = Geo::GetME()->DecodePMTOV(hitchan), and
        • const ChNum channel = Geo::GetME()->DecodeChOV(pmtnum, xpix), where xpix is of the same type as pixnum.
    >
    >
        • const Pixel pixnum = Geo::GetME()->DecodePixelOV(hitchan),
        • const PMTNum pmtnum = Geo::GetME()->DecodePMTOV(hitchan), and
        • const ChNum channel = Geo::GetME()->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()->AddOVHitThInfo(), again indexed by this "hitchan"
    In conclusion, the OVHitThInfo objects are filled with Geo::GetME()->Strip2Channel( (MC det #)*10000 + (MC module #)*100+(MC strip #) ). In order for DoOVRoSS to function correctly, there are also internal mapping functions and interfaces to Calib which must be maintained.
    Line: 62 to 62
      In this file, OVHitInfo objects are filled as follows:
    • The "hitchan" is retrieved from the pulses in the FEE repository
    Changed:
    <
    <
    • This is converted into a "module number" via Geo::GetME()->DecodeModuleOV(Geo::GetME()->Channel2Strip(hitchan)).
    >
    >
    • This is converted into a "module number" via Geo::GetME()->DecodeModuleOV(Geo::GetME()->Channel2Strip(hitchan)).
     
      • These "module numbers" are then used to organize the application of OV readout schemes (including edge strip readout described later)
    Changed:
    <
    <
    • Then, a "LocalStripNumber" is determined from the "hitchan" via Geo::GetME()->DecodeLocalStripOV(Geo::GetME()->Channel2Strip(hitchan)).
      • Readout conditions are then enforced via Geo::GetME()->GetOVMuLikeNeighbor1(LocalStripNumber)
    >
    >
    • Then, a "LocalStripNumber" is determined from the "hitchan" via Geo::GetME()->DecodeLocalStripOV(Geo::GetME()->Channel2Strip(hitchan)).
      • Readout conditions are then enforced via Geo::GetME()->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.
    Changed:
    <
    <
    • A separate Trigger Box section simulates the readout of edge strips. The following functions depend on the "module number" obtained via Geo::GetME()->DecodeModuleOV(Geo::GetME()->Channel2Strip(hitchan)):
      • myTrigBox1 = Geo::GetME()->GetOVMTrigBox(myMod1);
      • ElectOV::LowerLeftEdgeFirmware(Geo::GetME()->GetOVMTrigChan(myMod1),Geo::GetME()->GetOVMTrigChan(myMod2))
    >
    >
    • A separate Trigger Box section simulates the readout of edge strips. The following functions depend on the "module number" obtained via Geo::GetME()->DecodeModuleOV(Geo::GetME()->Channel2Strip(hitchan)):
      • myTrigBox1 = Geo::GetME()->GetOVMTrigBox(myMod1);
      • ElectOV::LowerLeftEdgeFirmware(Geo::GetME()->GetOVMTrigChan(myMod1),Geo::GetME()->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()->GetOVMTrigBox(myMod)+(myMod), where myMod=Geo::GetME()->DecodeModuleOV(Geo::GetME()->Channel2Strip(hitchan)).
    Changed:
    <
    <
    In conclusion, the OVHitInfo objects for non-edge-strip packets are filled with Geo::GetME()->Strip2Channel( (MC det #)*10000 + (MC module #)*100+(MC strip #) ). On the other hand, edge-strips packets are filled with DC::OV_CHANNEL_INDEX + 100*Geo::GetME()->GetOVMTrigBox(Geo::GetME()->DecodeModuleOV(Geo::GetME()->Channel2Strip( Geo::GetME()->Strip2Channel((MC det #)*10000 + (MC module #)*100+(MC strip #))))) + Geo::GetME()->DecodeModuleOV(Geo::GetME()->Channel2Strip( Geo::GetME()->Strip2Channel( (MC det #)*10000 + (MC module #)*100+(MC strip #)))).
    >
    >
    In conclusion, the OVHitInfo objects for non-edge-strip packets are filled with Geo::GetME()->Strip2Channel( (MC det #)*10000 + (MC module #)*100+(MC strip #) ). On the other hand, edge-strips packets are filled with DC::OV_CHANNEL_INDEX + 100*Geo::GetME()->GetOVMTrigBox(Geo::GetME()->DecodeModuleOV(Geo::GetME()->Channel2Strip( Geo::GetME()->Strip2Channel( (MC det #)*10000 + (MC module #)*100+(MC strip #))))) + Geo::GetME()->DecodeModuleOV(Geo::GetME()->Channel2Strip( Geo::GetME()->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.
    Changed:
    <
    <

    Conclusion

    There is a lot we need to clean up.

    >
    >

    DCGeo

    • StripWithinOV

      • Bool_t StripWithinOV(const DC::StripNum stp) const
        • return this->ChWithinOV(stp+dCH_OFFSET_OV);
      • Bool_t ChWithinOV(const DC::ChNum ch) const
        • if(ch<dCH_OFFSET_OV || ch>2*dCH_OFFSET_OV) return false
        • if(this->DecodeDetFromChOV(ch) == DCDetector::kUnknownDET) return false;
        • if(this->PixelWithinOV(this->DecodePixelOV(ch))) return false;
        • if(this->PMTWithinOV(this->DecodePMTOV(ch))) return false;
        • return true;
      • DCDetector::Detector_t DecodeDetFromChOV(const DC::ChNum ch) const
        • if((ch-dCH_OFFSET_OV)/10000 == 1) return DCDetector::kFAR;
        • else if ((ch-dCH_OFFSET_OV)/10000 == 2) return DCDetector::kNEAR;
        • else return DCDetector::kUnknownDET;
      • DC::Pixel DecodePixelOV(const DC::ChNum ch) const
        • return (DC::Pixel) ch%100;
      • DC::PMTNum DecodePMTOV(const DC::ChNum ch) const
        • return (ch - dCH_OFFSET_OV)/100;
      • Bool_t PixelWithinOV(const DC::Pixel pixel) const
        • return (pixel < dSTRIPSperMODULE);
      • Bool_t PMTWithinOV(const DC::PMTNum pmt) const
        • return (pmt%100 < this->GetPMT_OV(this->DecodeDetFromPMTOV(pmt)));
      • DCDetector::Detector_t DecodeDetFromPMTOV(const DC::PMTNum pmt) const
        • return this->DecodeDetFromChOV((DC::ChNum) (pmt*100 + dCH_OFFSET_OV) );
      • DCDetector::Detector_t DecodeDetFromChOV(const DC::ChNum ch) const;
        • if((ch-dCH_OFFSET_OV)/10000 == 1) return DCDetector::kFAR;
        • else if ((ch-dCH_OFFSET_OV)/10000 == 2) return DCDetector::kNEAR;
        • else return DCDetector::kUnknownDET;
      • DC::PMTNum GetPMT_OV(const DCDetector::Detector_t det) const
        • return this->GetModule_OV(det);
      • DC::PMTNum GetModule_OV(const DCDetector::Detector_t det) const
        • if(det==DCDetector::kFAR) return dMODULE_OUTVETOFD_MAX;
        • else if(det == DCDetector::kNEAR) return dMODULE_OUTVETOND_MAX;
        • else return 0;
    • Strip2Channel

      • DC::ChNum Strip2Channel(const DC::StripNum stp) const
        • If(this->StripWithinOV(stp)
          return this->DecodeChOV((DC::PMTNum)this->DecodeModuleOV(stp),fStrip2PixelDB[this->DecodeLocalStripOV(stp)]);
      • DC::ModuleNum DecodeModuleOV(const DC::StripNum stp) const
        • return (DC::ModuleNum) stp/100;
      • DC::StripNum DecodeLocalStripOV(const DC::StripNum stp) const
        • return (DC::StripNum) stp%100;
      • DC::ChNum DecodeChOV(const DC::PMTNum pmt, const DC::Pixel pixel) const
        • if(this->PixelWithinOV(pixel) && this->PMTWithinOV(pmt)) return (100*pmt + dCH_OFFSET_OV + pixel);
    • Channel2Strip

      • DC::StripNum Channel2Strip(const DC::ChNum ch) const
        • if(this->ChWithinOV(ch)) {
          for(UInt_t i=0;i<dSTRIPSperMODULE; i++) {
          if(fStrip2PixelDB[i] == this->DecodePixelOV(ch)) return this->DeocdeStripOV(this->DecodePMTOV(ch),i);
          } return 9999;
          } else return 9999;
      • DC::ChNum DecodeStripOV(const DC::ModuleNum mod, const DC::StripNum stp) const
        • if(this->PixelWithinOV(stp%100) && this->PMTWithinOV(mod)) return (mod*100 + stp);
    • Conclusions

      • DCGeo assumes:
        • PMT == module
        • 1-to-1 mapping fStrip2Pixel[64]: pixel <-> (local strip)
        • Channel = (100*module#) + pixel + dCH_OFFSET_OV
        • Strip = (100*module#) + (local strip)
        • module = (100*det#) + detector-specific module
        • The number of channels is between dCH_OFFSET_OV and 2*dCH_OFFSET_OV
      • This is wrong because
        • There are more PMTs (boards) than (physical) modules and therefore
        • There are more channels than strips
        • The offset that should be used is DC::OV_CHANNEL_INDEX and for this offset the number of OV channels is not between DC::OV_CHANNEL_INDEX and 2*DC::OV_CHANNEL_INDEX.
    • Implications

      • The ChWithinOV and StripWithinOV functions should be separated
      • DCGeo should be able to access and apply the mapping between module # and pmtboard_u.
      • Information about about the detector should be added to the data stream.
      • dCH_OFFSET_OV or DC::OV_CHANNEL_INDEX?
      • Verify that "pixel" in the DB refers to MAROC2 CHANNEL
      • How should DCCalib access OV data? At the OVHit level?
      • A call to Geo::GetME()->GetOVMTrigChan() should be added to the section of DCRElectoOV where OVHitInfo objects for edge strips packets are created.
     -- MattToups - 23 Feb 2011 \ No newline at end of file

    Revision 12011-02-24 - MattToups

    Line: 1 to 1
    Added:
    >
    >
    META TOPICPARENT name="MattToups"

    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; ///< Full channel number (including OV offset, online-based)
    DC::PMTPixelNum fPMTPixelNum; ///< Full PMT pixel number (including OV offset)

    UShort_t fStatus; ///< readout status mask

    DC::DUQ fQ; ///< integrated digitized charge, 0 if not available
    DC::PE fQPE; ///< # PE correponding to integrated charge, 0 if not available

    Bool_t fWasHit; ///< true if signal above threshold and if being read out

    DC::T_ns fTime; ///< Time of signal
    DC::T_s fTimeUnix; ///< 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; ///< Time of energy deposition
    DC::MEV fHitEnergy; ///< Total energy injected (truth with no scintillator physics)
    UInt_t fHitID; ///< What is this??? Useful???
    DC::StripNum fStripNum; ///< Strip Number
    DC::L_mm fStripZ; ///< Position of energy deposition along strip-axis
    DC::L_mm fX0; ///< Position of energy deposition in global frame of reference X
    DC::L_mm fY0; ///< Position of energy deposition in global frame of reference Y
    DC::L_mm fZ0; ///< Position of energy deposition in global frame of reference Z
    UInt_t fG4GenerationID; ///< 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()->GetOVMStripLength(Geo::GetME()->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()->GetMeV2PEOV(myOVH->GetE(), numStrip) and
        • Calib::GetME()->OVAttenuation(fiber_l, numStrip), where fiber_l depends on the module length
    • The "hitchan" is determined from fStripNum via Geo::GetME()->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()->DecodePixelOV(hitchan),
        • const PMTNum pmtnum = Geo::GetME()->DecodePMTOV(hitchan), and
        • const ChNum channel = Geo::GetME()->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()->AddOVHitThInfo(), again indexed by this "hitchan"
    In conclusion, the OVHitThInfo objects are filled with Geo::GetME()->Strip2Channel( (MC det #)*10000 + (MC module #)*100+(MC strip #) ). 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()->DecodeModuleOV(Geo::GetME()->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()->DecodeLocalStripOV(Geo::GetME()->Channel2Strip(hitchan)).
      • Readout conditions are then enforced via Geo::GetME()->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()->DecodeModuleOV(Geo::GetME()->Channel2Strip(hitchan)):
      • myTrigBox1 = Geo::GetME()->GetOVMTrigBox(myMod1);
      • ElectOV::LowerLeftEdgeFirmware(Geo::GetME()->GetOVMTrigChan(myMod1),Geo::GetME()->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()->GetOVMTrigBox(myMod)+(myMod), where myMod=Geo::GetME()->DecodeModuleOV(Geo::GetME()->Channel2Strip(hitchan)).
    In conclusion, the OVHitInfo objects for non-edge-strip packets are filled with Geo::GetME()->Strip2Channel( (MC det #)*10000 + (MC module #)*100+(MC strip #) ). On the other hand, edge-strips packets are filled with DC::OV_CHANNEL_INDEX + 100*Geo::GetME()->GetOVMTrigBox(Geo::GetME()->DecodeModuleOV(Geo::GetME()->Channel2Strip( Geo::GetME()->Strip2Channel((MC det #)*10000 + (MC module #)*100+(MC strip #))))) + Geo::GetME()->DecodeModuleOV(Geo::GetME()->Channel2Strip( Geo::GetME()->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.

    -- MattToups - 23 Feb 2011

     
    This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
    Ideas, requests, problems regarding TWiki? Send feedback