Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
OV Channel Mapping Proposal1) Resolve Strip # Geometry Inconsistencies: | ||||||||
Changed: | ||||||||
< < | UC Strip # (Looking from PMT end down the length of the module) | |||||||
> > | UC Strip # and OV firmware assumed layout (Looking from PMT end down the length of the module) | |||||||
+ 33 + 34 + 35 + 36 + 37 + ... + 1 + 2 + 3 + 4 + 5 + ... | ||||||||
Changed: | ||||||||
< < | MC Strip # (Looking from PMT end down the length of the module) 0 + 1 + 2 + 3 + 4 + ... + 32 + 33 + 34 + 35 + 36 + ... | |||||||
> > | MC Strip # and MC layout (Looking from PMT end down the length of the module) 0 + 1 + 2 + 3 + 4 + ... + 32 + 33 + 34 + 35 + 36 + ...Implications: Affects the edge strip firmware, which assumes the first layout above. Status: Needs to be fixed and propagated to MC, if necessary. UC should take the lead on this. | |||||||
2) Eliminate MC strip # and instead use UC Strip # Solves: Issue that fStrip2Pixel tacitly assumes UC Strip number as input | ||||||||
Changed: | ||||||||
< < | Implications: Modify GetMuLikeNeighbor, Edge Strip conditions | |||||||
> > | Implications: Modify GetMuLikeNeighbor, Edge Strip condition. Any other problems? RecoOV? | |||||||
Status: Not yet implemented, add or replace column in ascii table? | ||||||||
Changed: | ||||||||
< < | 3) Enforce equivalency of pmtboard_u and 100*det + MC module # (or MC trig box #) | |||||||
> > | 3) Enforce equivalency of pmtboard_u numbering scheme and MC module # scheme | |||||||
Solves: Inconsistency with data | ||||||||
Line: 29 to 33 | ||||||||
Solves: Inconsistency with MC | ||||||||
Changed: | ||||||||
< < | Implications: RoSS, RecoOV, CalibApply look OK, but should be tested | |||||||
> > | Implications: RoSS, RecoOV, CalibApply look OK, but should be tested by Arthur & Emily. | |||||||
Changed: | ||||||||
< < | Status: Not yet implemented (takes 5 minutes to implement). | |||||||
> > | Status: Tested with OV DAQ, can be fully implemented in a matter of minutes. | |||||||
5) Eliminate dCH_OFFSET_OV in favor of DC::OV_CHANNEL_INDEX |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Added: | ||||||||
> > |
OV Channel Mapping Proposal1) Resolve Strip # Geometry Inconsistencies: UC Strip # (Looking from PMT end down the length of the module)+ 33 + 34 + 35 + 36 + 37 + ... + 1 + 2 + 3 + 4 + 5 + ... MC Strip # (Looking from PMT end down the length of the module) 0 + 1 + 2 + 3 + 4 + ... + 32 + 33 + 34 + 35 + 36 + ...2) Eliminate MC strip # and instead use UC Strip # Solves: Issue that fStrip2Pixel tacitly assumes UC Strip number as input Implications: Modify GetMuLikeNeighbor, Edge Strip conditions Status: Not yet implemented, add or replace column in ascii table? 3) Enforce equivalency of pmtboard_u and 100*det + MC module # (or MC trig box #) Solves: Inconsistency with data Implications: pmtboard_u and MC table must be always in sync, manual or mysql Status: Work already done by Arthur, should be double-checked? 4) Encode detector in pmtboard_u on mySQL Solves: Inconsistency with MC Implications: RoSS, RecoOV, CalibApply look OK, but should be tested Status: Not yet implemented (takes 5 minutes to implement). 5) Eliminate dCH_OFFSET_OV in favor of DC::OV_CHANNEL_INDEX Solves: Inconsistency with data, max OV channel out of range of ushort int Implications: Far detector OV channel range: 14,100 – 18,763 Near detector OV channel range: 24,100 – 31,363 Status: Completed 6) Separate Physical Quantities from Electronic quantities Solves: Inconsistency between # of pmt boards and # of modules Implications: GetPMTBoardPMT_OV, GetChannel_OV, PMTBoardWithinOV added. ChWithinOV, StripWithinOV modified. dTRIGBOX_OUTVETOFD_MAX, dTRIGBOX_OUTVETOND_MAX added. Status: Completed 7) Verify xtalk code works on Maroc2 channel number (and not Hamamatsu pixel #) Solves: Inconsistency between channel/pixel # Implications: None. I think the code does work in Maroc2 pixel number (it's symmetric) Status: Crosscheck by Matt Strait? -- MattToups - 17 Mar 2011 |