New hlt susy developments

[parbol]

This is the full suite of SUSY DQM HLT modules covering all the triggers we have proposed so far.

[cmsbuild]

A new Pull Request was created by @parbol for CMSSW_7_3_X.

New hlt susy developments

It involves the following packages:

HLTriggerOffline/SUSYBSM

@nclopezo, @danduggan, @rovere, @cmsbuild, @deguio, @ojeda can you please review it and eventually sign? Thanks.
You can sign-off by replying to this message having '+1' in the first line of your reply.
You can reject by replying to this message having '-1' in the first line of your reply.
@nclopezo, @ktf you are the release manager for this.
You can merge this pull request by typing 'merge' in the first line of your comment.

[cmsbuild]

+1
Tested at: e3e7f56
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-6255/716/summary.html

[cmsbuild]

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-6255/716/summary.html

[jruizvar]

I checked the DQM output test results, in particular this file

https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-6255/716/DQMTestsResults/DQMTestsResults/9/DQM_V0001_R000000001__Global__CMSSW_X_Y_Z__RECO.root

There are not histograms in the directory "DQMData/Run 1/HLT/Run summary/SUSYBSM/ ", only empty folders. Is it normal?

[parbol]

I'm not sure whether this is normal or not. To be honest I don't know very well how that root file was generated. Is it using an updated HLT with the latest greatest triggers?

[jruizvar]

I don't know either how this tests are run. My intention is not to delay this PR, it's just a matter of curiosity

[parbol]

Hi Jose,

There are things in this PR unchanged from the previous code that was working well and doesn't appear in that root file, so I think this is OK.

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next CMSSW_7_3_X IBs unless changes or unless it breaks tests.

[cmsbuild]

+1
Tested at: 68a0b6c
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-6255/905/summary.html

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next CMSSW_7_3_X IBs unless changes (tests are also fine). This pull request will be automatically merged.

[cmsbuild]

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-6255/905/summary.html

[davidlange6]

Seems that this PR is bringing crashes in the integration builds - Could you provide a quick fix? (I likely will back it out this change for the 0200 if no fix)

https://cmssdt.cern.ch/SDT/cgi-bin/buildlogs/slc6_amd64_gcc491/CMSSW_7_3_X_2014-11-17-0200/pyRelValMatrixLogs/run/22.0_SingleMuPt1000+SingleMuPt1000INPUT+DIGI+RECO+HARVEST/step3_SingleMuPt1000+SingleMuPt1000INPUT+DIGI+RECO+HARVEST.log

[parbol]

Hi David,

Is it possible to have the root file where this problem showed up? I'm running with my own root files and I cannot reproduce the error.

Pablo

[parbol]

Hi David,

I have found the problem but couldn't really see if it worked because I cannot reproduce the error (since I have very limited statistics and was not lucky enough to reach the error).

Let me describe the problem: the module

SUSY_HLT_MET_MUON_ER

looks for triggers with an eta cut on the muon. When in the code I do:

std::vector offlineMuons;
for(reco::MuonCollection::const_iterator muon = MuonCollection->begin(); muon != MuonCollection->end() ; ++muon) {
if(fabs(muon->eta())>etaMuonOffline_) continue;
Lepton theMuon; theMuon.pt = muon->pt(); theMuon.phi = muon->phi(); theMuon.eta = muon->eta();
offlineMuons.push_back(theMuon);
}

since I'm applying this eta cut, the size of "offlineMuons" can be actually smaller than the size of the MuonCollection (for example when MuonCollection has muons with high eta). Then later in the code I was doing operations requiring that MuonCollection was greater than 0, but then using offlineMuons again.

if((hasFiredAuxiliaryForMuonLeg || !e.isRealData()) && MuonCollection->size()>0 && pfMETCollection->begin()->et() > METOffline_ && pfHT > HTOffline_) {
if(hasFired && indexOfMatchedMuon >= 0) {
h_MuTurnOn_num-> Fill(offlineMuons.at(indexOfMatchedMuon).pt);
h_MuTurnOn_den-> Fill(offlineMuons.at(indexOfMatchedMuon).pt);
} else {
h_MuTurnOn_den-> Fill(offlineMuons.at(0).pt);
}
}
I think this was crashing because as I said MuonCollection could have more than one element, while offlineMuons not, and therefore offlineMuons.at(0).pt could fail.

I have updated the code in such a way that MuonCollection is not used anymore anywhere. So I think this should be fine. I would be pleased if you could check again (comitted new code).

Thanks,

Pablo

[davidlange6]

Hi

Sounds promising - you will need to make a new pull request for integration. Meanwhile you can likely reproduce the error via

runTheMatrix -l 22 -i all

Cheers-
David

On Nov 17, 2014, at 8:46 PM, parbol notifications@github.com
wrote:

Hi David,

I have found the problem but couldn't really see if it worked because I cannot reproduce the error (since I have very limited statistics and was not lucky enough to reach the error).

Let me describe the problem: the module

SUSY_HLT_MET_MUON_ER

looks for triggers with an eta cut on the muon. When in the code I do:

std::vector offlineMuons;
for(reco::MuonCollection::const_iterator muon = MuonCollection->begin(); muon != MuonCollection->end() ; ++muon) {
if(fabs(muon->eta())>etaMuonOffline_) continue;
Lepton theMuon; theMuon.pt = muon->pt(); theMuon.phi = muon->phi(); theMuon.eta = muon->eta();
offlineMuons.push_back(theMuon);
}

since I'm applying this eta cut, the size of "offlineMuons" can be actually smaller than the size of the MuonCollection (for example when MuonCollection has muons with high eta). Then later in the code I was doing operations requiring that MuonCollection was greater than 0, but then using offlineMuons again.

if((hasFiredAuxiliaryForMuonLeg || !e.isRealData()) && MuonCollection->size()>0 && pfMETCollection->begin()->et() > METOffline_ && pfHT > HTOffline_) {
if(hasFired && indexOfMatchedMuon >= 0) {
h_MuTurnOn_num-> Fill(offlineMuons.at(indexOfMatchedMuon).pt);
h_MuTurnOn_den-> Fill(offlineMuons.at(indexOfMatchedMuon).pt);
} else {
h_MuTurnOn_den-> Fill(offlineMuons.at(0).pt);
}
}
I think this was crashing because as I said MuonCollection could have more than one element, while offlineMuons not, and therefore offlineMuons.at(0).pt could fail.

I have updated the code in such a way that MuonCollection is not used anymore anywhere. So I think this should be fine. I would be pleased if you could check again (comitted new code).

Thanks,

Pablo

—
Reply to this email directly or view it on GitHub.

[parbol]

Hi,

I run it and I don't get the error anymore. I have made a new PR:

#6457

Thanks for your help David,

PAblo