strip digitizer stores tofBin, hitAssociator uses CFpos #4520
Conversation
|
A new Pull Request was created by @wmtford for CMSSW_7_2_X. strip digitizer stores tofBin, hitAssociator uses CFpos It involves the following packages: SimDataFormats/TrackerDigiSimLink @cmsbuild, @civanch, @Degano, @mdhildreth, @nclopezo can you please review it and eventually sign? Thanks. |
|
+1 |
|
This pull request is fully signed and it will be integrated in one of the next CMSSW_7_2_X IBs unless changes (tests are also fine). |
| @@ -6,11 +6,16 @@ | |||
|
|
|||
| class StripDigiSimLink { | |||
| public: | |||
| StripDigiSimLink(unsigned int ch, unsigned int tkId, unsigned int counter, EncodedEventId e,float a ): | |||
There was a problem hiding this comment.
Dumb question: do we allow sim data format changes in 72X wrt 71X?
@davidlange6
|
I realized that I should add protection against an out-of-range index in case the hitAssociator is taking data from prompt collections when the digitization had inserted pileup into the crossing frame. So I committed that change as noted above. I don't know if such commits made while the PR approval is pending get picked up seamlessly or not. |
|
This pull request is fully signed and it will be integrated in one of the next CMSSW_7_2_X IBs unless changes or unless it breaks tests. |
|
-1 runTheMatrix-results/4.22_RunCosmics2011A+RunCosmics2011A+RECOCOSD+ALCACOSD+SKIMCOSD+HARVESTDC/step2_RunCosmics2011A+RunCosmics2011A+RECOCOSD+ALCACOSD+SKIMCOSD+HARVESTDC.log 4.53 step2 runTheMatrix-results/4.53_RunPhoton2012B+RunPhoton2012B+HLTD+RECODreHLT+HARVESTDreHLT/step2_RunPhoton2012B+RunPhoton2012B+HLTD+RECODreHLT+HARVESTDreHLT.log 1000.0 step2 runTheMatrix-results/1000.0_RunMinBias2011A+RunMinBias2011A+TIER0+SKIMD+HARVESTDfst2+ALCASPLIT/step2_RunMinBias2011A+RunMinBias2011A+TIER0+SKIMD+HARVESTDfst2+ALCASPLIT.log 1001.0 step2 runTheMatrix-results/1001.0_RunMinBias2011A+RunMinBias2011A+TIER0EXP+ALCAEXP+ALCAHARVD/step2_RunMinBias2011A+RunMinBias2011A+TIER0EXP+ALCAEXP+ALCAHARVD.log 1003.0 step2 runTheMatrix-results/1003.0_RunMinBias2012A+RunMinBias2012A+RECODDQM+HARVESTDDQM/step2_RunMinBias2012A+RunMinBias2012A+RECODDQM+HARVESTDDQM.log 50101.0 step2 runTheMatrix-results/50101.0_SingleMuPt10+SingleMuPt10FSIdINPUT+SingleMuPt10FS_ID/step2_SingleMuPt10+SingleMuPt10FSIdINPUT+SingleMuPt10FS_ID.log you can see the results of the tests here: |
|
This pull request is fully signed and it will be integrated in one of the next CMSSW_7_2_X IBs unless changes (but tests are reportedly failing). |
|
If I look at the last of the failed tests, I see that the dasquery step executes the query When I run the same query myself, I get File: /store/relval/CMSSW_6_2_0_pre8/RelValSingleMuPt10/GEN-SIM-DIGI-RECO/PRE_ST62_V8_FastSim-v1/00000/74C2A876-DFE0-E211-BAFA-BCAEC5329703.root File: /store/relval/CMSSW_6_2_0_pre8/RelValSingleMuPt10/GEN-SIM-DIGI-RECO/PRE_ST62_V8_FastSim-v1/00000/88951C57-DBE0-E211-A14B-003048F0117C.root For the other failed workflows the step1_dasquery.log file is empty. The step2 failures indicate an empty list of files to run on. |
|
This pull request is fully signed and it will be integrated in one of the next CMSSW_7_2_X IBs unless changes (tests are also fine). |
|
This pull request is fully signed and it will be integrated in one of the next CMSSW_7_2_X IBs unless changes (tests are also fine). |
strip digitizer stores tofBin, hitAssociator uses CFpos
ghost
merged commit 
|
@wmtford, all - it seems that this pull request has a bit adverse timing effect on stripRecHitsValid and globalrechitsanalysis modules when running on pileup events (maybe always, but we noticed on the pileup workflows, e.g., 25203, which now take minutes per event). We will back out for now - as this would prevent us from doing any pileup relvals. |
|
Hi David, I think I see where the problem is. Now to seek a cure. The time is Bill On 7/14/14, 3:18 AM, David Lange wrote:
|
ghost
mentioned this pull request
With this PR we fully restore the hit association functionality to what it was before CMSSW_6_2_0_pre8. That is, for the strip tracker we follow the digiSimLink directly back to the simHit. This is in contrast to the previous fix (PRs 2279, 2285, 3021, 3637), where the match was indirect through the simTrack, and is sometimes ambiguous.
Here we add a bit to the stripDigiSimLink to specify the Low- vs High-Tof collection, which in combination with the detID.subDet allows the collection-relative pointers to be used. The digitizer supplies this information on creation of the digiSimLink. The hitAssociator now uses this information. I hope I've implemented this in a way that preserves the thread-safe behavior of the hitAssociator.