Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
Added: | ||||||||
> > | ProposalLook here for the OVChannelMappingFix. | |||||||
OV Channel Mapping ConventionsThere are 5 different numbering conventions used to indicate the 64 "channels" in an OV "module": |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
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": | |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < | There are 2 different numbering conventions used to indicate the 44 (68) "modules" in the OV 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
| ||||||||
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 FormatThe OV data is stored in a TClonesArray of OVHitInfo objects, each of which contains: | ||||||||
Line: 136 to 149 | ||||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
| |||||||
Implications
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Added: | ||||||||
> > |
|
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
OV Channel Mapping Conventions | ||||||||
Line: 43 to 43 | ||||||||
OVHitThInfo objects are filled as follows:
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Line: 62 to 62 | ||||||||
In this file, OVHitInfo objects are filled as follows:
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
| ||||||||
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: | ||||||||
< < | ConclusionThere is a lot we need to clean up. | |||||||
> > | DCGeo
| |||||||
-- MattToups - 23 Feb 2011 \ No newline at end of file |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Added: | ||||||||
> > |
OV Channel Mapping ConventionsThere are 4 different numbering conventions used to indicate the 64 "channels" in an OV "module":
Data FormatThe 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 FormatThere 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 depositionDC::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:
OVHitThInfoThe 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:
OVHitInfoThe 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:
ConclusionThere is a lot we need to clean up. -- MattToups - 23 Feb 2011 |