bug fix for Me0 segments #14306
bug fix for Me0 segments #14306
Conversation
|
A new Pull Request was created by @jshlee (Jason Lee) for CMSSW_8_1_X. It involves the following packages: RecoMuon/DetLayers @cmsbuild, @cvuosalo, @slava77, @davidlange6 can you please review it and eventually sign? Thanks. cms-bot commands are list here #13028 |
| @@ -164,6 +164,8 @@ void ME0SegmentMatcher::produce(edm::Event& ev, const edm::EventSetup& setup) { | |||
|
|
|||
| //Remove later | |||
| if (std::abs(thisTrack->eta()) < 1.8) continue; | |||
| // low pt tracks cannot be propagated to me0 | |||
| if (thisTrack->pt() < 1.0) continue; | |||
There was a problem hiding this comment.
Are you sure about using pt?
The p at eta~2.8 and pt=1 is about 8 GeV;
for the eta ~4 option, if it resurfaces, there is even larger ratio.
There was a problem hiding this comment.
Hi Slava,
I didnt really check what the min was and assumed a lower pt wouldnt be used.
I think using pt would be the easiest and fastest way.
Do you have a better idea?
There was a problem hiding this comment.
Hi Jason,
|pz|>2.5 || p > 3 may be a more inclusive selection to expect the propagation to succeed.
You should anyways add a check lastrecostate.isValid after the propagation before using lastrecostate.
There was a problem hiding this comment.
lastrecostate.isValid works well. I changed to that.
|
@cmsbuild please test |
|
The tests are being triggered in jenkins. |
|
Pull request #14306 was updated. @cmsbuild, @cvuosalo, @slava77, @davidlange6 can you please check and sign again. |
|
@cmsbuild please test |
|
The tests are being triggered in jenkins. |
|
|
||
| LogTrace(metname) << "About to make a MuRingForwardLayer"; | ||
| if(frontRings.size()!=0) result = new MuRingForwardLayer(frontRings); |
There was a problem hiding this comment.
Where is this MuRingForwardLayer object deleted? I couldn't find the deletion anywhere.
There was a problem hiding this comment.
@cvuosalo - I only added the me0 layers.
I think it isnt deleted since this object is only created at the start.
This is also the case for all the other MuonDetLayerGeometryBuilders.
There was a problem hiding this comment.
It appears the design of the MuonDetLayerGeometryBuilders incorporates a memory leak. If so, the design should be fixed now before any more code is written based upon it.
There was a problem hiding this comment.
@cvuosalo - should I delete all these pointers at the destructor for all MuonDetLayerGeometryBuilders in this PR?
There was a problem hiding this comment.
@jshlee: Yes, it would be good to fix this issue. Changing to pointers to std::shared_ptr or std::unique_ptr (as appropriate) would mean the deletion would happen automatically.
There was a problem hiding this comment.
@cvuosalo - looking at this further, these are already assigned as std::shared_ptr upstream in https://github.com/cms-sw/cmssw/blob/CMSSW_8_1_X/RecoMuon/DetLayers/plugins/MuonDetLayerGeometryESProducer.cc#L98
There was a problem hiding this comment.
@jshlee: In answer to my original question, we found where the memory is deleted, so there is no problem:
https://github.com/cms-sw/cmssw/blob/CMSSW_8_1_0_pre4/RecoMuon/DetLayers/src/MuonDetLayerGeometry.cc#L33
|
@cvuosalo @slava77 @davidlange6 can we please go ahead with this PR? it is needed because otherwise the muon reconstruction crushes in the phase2 scenario |
|
+1 Bug fix to prevent segmentation fault that occurred with an invalid ME0 trajectory state. There should be no change in standard workflows. The code changes are satisfactory, and Jenkins tests against baseline CMSSW_8_1_X_2016-04-29-2300 show no significant differences, as expected. |
|
This pull request is fully signed and it will be integrated in one of the next CMSSW_8_1_X IBs (tests are also fine). This pull request requires discussion in the ORP meeting before it's merged. @slava77, @davidlange6, @Degano, @smuzaffar |
cmsbuild
added
reconstruction-approved
fully-signed
and removed
reconstruction-pending
labels
|
+1 |
MuonME0DetLayerGeometryBuilder - added layers for ME0DetId
ME0SegmentMatcher - low pt tracks were not reaching ME0 resulting in a seg fault