Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

71 x taus quality cuts improvement #2843

Merged
merged 13 commits into from
Mar 23, 2014

Conversation

jpavel
Copy link
Contributor

@jpavel jpavel commented Mar 13, 2014

  • Speeding up the execution of tau quality cuts (commits by @makortel)
  • Reducing inefficiency of anti-mu discriminators at high PU (authored by @veelken)
  • Clean up to follow cmssw guidelines (i.e. removing couts where possible)

veelken and others added 10 commits February 21, 2014 12:04
	- do not veto track segments in innermost CSC chamber
	- count number of muon stations containing matched segments
	  rather than summing matched segments of different muons in the same muon station
	 (in the old implementation a tau was failing the anti-muon Loose discriminator in case there are 2 reco::Muons
	  each having 1 matched segment in the innermost CSC chamber. The new implementation requires that the matched segments are in at least 2 different chambers
	  before the tau fails the anti-muon discriminator)
@cmsbuild
Copy link
Contributor

A new Pull Request was created by @jpavel (Pavel Jez) for CMSSW_7_1_X.

71 x taus quality cuts improvement

It involves the following packages:

RecoTauTag/RecoTau

@nclopezo, @cmsbuild, @anton-a, @thspeer, @slava77, @Degano 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
Copy link
Contributor

@@ -252,7 +252,7 @@ double AntiElectronIDMVA5GBR::MVAValue(Float_t TauEtaAtEcalEntrance,
{

if ( !isInitialized_ ) {
std::cout << "Error: AntiElectronMVA not properly initialized.\n";
edm::LogError("ClassNotInitialized") << "Error: AntiElectronMVA not properly initialized.\n";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it's a configuration problem, an exception is more appropriate. Else we'll just keep running, which is probably not what's intended.

@jpavel
Copy link
Contributor Author

jpavel commented Mar 16, 2014

Hi Slava, thanks for suggestions - all are implemented.

@cmsbuild
Copy link
Contributor

Pull request #2843 was updated. @nclopezo, @cmsbuild, @anton-a, @thspeer, @slava77, @Degano can you please check and sign again.

@slava77
Copy link
Contributor

slava77 commented Mar 17, 2014

Hi Pavel,

What was changed on the physics side in this PR?
I see a difference in recoPFTauDiscriminator_hpsPFTauDiscriminationByMediumIsolation__
all_sign322vsorig_ttbarwf25p0c_recopftaudiscriminator_hpspftaudiscriminationbymediumisolation__reco_obj_data_

@slava77
Copy link
Contributor

slava77 commented Mar 17, 2014

nm, I see that changes are expected, as mentioned in the PR submission message

@slava77
Copy link
Contributor

slava77 commented Mar 17, 2014

Are there any plots describing changes in performance?
This would be helpful for keeping track of changes.
Please post them here or a link to some talk.

BTW, plots with discrimination by ChargedIsolation, by MuonRejection (2 and 3), by CombinedIsolationDBSumPtCorr, and by Isolation
are changed in some way. It's not obvious to me all are related to the declared change.

... what's more disturbing on a separate level is that nothing showed up in jenkins tests in
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-2843/478/summary.html

@@ -48,13 +48,12 @@
}

void RecoTauConstructor::addPFCand(Region region, ParticleType type, const PFCandidateRef& ref, bool skipAddToP4) {
//std::cout << "<RecoTauConstructor::addPFCand>:" << std::endl;
//std::cout << " region = " << region << ", type = " << type << ": Pt = " << ref->pt() << ", eta = " << ref->eta() << ", phi = " << ref->phi() << std::endl;
edm::LogInfo("TauConstructorAddPFCand") << " region = " << region << ", type = " << type << ": Pt = " << ref->pt() << ", eta = " << ref->eta() << ", phi = " << ref->phi();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these should be replaced as well.
I suggest you grep for LogInfo in all the code and change to LogDebug

@cmsbuild
Copy link
Contributor

Pull request #2843 was updated. @nclopezo, @cmsbuild, @anton-a, @thspeer, @slava77, @Degano can you please check and sign again.

@cmsbuild
Copy link
Contributor

@slava77
Copy link
Contributor

slava77 commented Mar 21, 2014

Nice, I will check results later today (including the Vertex::trackWeight in #2894 for CPU performance comparison)

@makortel
Copy link
Contributor

Hi Slava,

I'd actually expect no performance improvement in tau quality cut code with #2894, because AFAICT the vertex weight cut is currently disabled in RECO, and in this PR the reco::TrackBaseRef is constructed ("the heavy operation" that can be avoided with #2894) only if the cut is enabled.

@jpavel
Copy link
Contributor Author

jpavel commented Mar 21, 2014

Hi Matti, this is not exactly true. Although reco::TrackBaseRef is avoided by quality cuts, it is still being used heavily by https://github.com/jpavel/cmssw/blob/71X_taus_QualityCutsImprovement/RecoTauTag/RecoTau/src/RecoTauVertexAssociator.cc where the weight of tracks in vertex is used to find the tau vertex.

@makortel
Copy link
Contributor

Hi Pavel,

Thanks for the correction (I didn't look outside RecoTauQualityCuts.cc for the uses). However, in RecoTauVertexAssociator.cc you pointed, an intermediate reco::TrackBaseRef is actually constructed explicitly and therefore #2894 should not give any improvement in there either.

@VinInn
Copy link
Contributor

VinInn commented Mar 21, 2014

I think that if reco::TrackBaseRef is never dereferenced one gets the speed-up anyhow.
I agree that all those reco::TrackBaseRef in RecoTauVertexAssociator.cc should be removed
in favor of templates (or directly with RefWithIndex)

@jpavel
Copy link
Contributor Author

jpavel commented Mar 22, 2014

I agree - but it would work only after #2894 is merged, no? Otherwise the templates would not be defined in the code, or am I missing something?

@slava77
Copy link
Contributor

slava77 commented Mar 22, 2014

Results based on tests in CMSSW_7_1_X_2014-03-18-0200

  • only muon rejection related plots in tau DQM changed.

Here is one diff (red is new) that looked particularly large, just to check with you that they make sense.
Note that the background-like sample (qcd dijet wflow 38.0) doesn't have this large difference.

wf 20.0 (single muon pt=10, 2K events, no PU)
wf20_pftau_loosemurej3_eta

@jpavel
Copy link
Contributor Author

jpavel commented Mar 22, 2014

Hi Slava, something like this is indeed expected - the aim of Christian's fix was to improve efficiency at larger eta regions, while the fake rate should not change dramatically. I will also let @veelken to comment on this plot.

@veelken
Copy link
Contributor

veelken commented Mar 22, 2014

Hi Slava,

the plot is the probability for muons to pass the discriminatorAgainstMuons3Loose, right ?
Some change in this discriminator is indeed expected (we modified the cuts for taus within the CSC acceptance, because we saw a large drop in tau ID efficiency at |eta| > 1.2 as function of pile-up)
Do you happen to have the corresponding plot for discriminatorAgainstMuons3Tight also ?

Cheers,

Christian

On Mar 22, 2014, at 3:49 PM, Pavel Jez wrote:

Hi Slava, something like this is indeed expected - the aim of Christian's fix was to improve efficiency at larger eta regions, while the fake rate should not change dramatically. I will also let @veelken to comment on this plot.


Reply to this email directly or view it on GitHub.

@slava77
Copy link
Contributor

slava77 commented Mar 23, 2014

Hi Christian,

The tight one doesn't have as much of an increase near eta ~2
wf20_pftau_tightmurej3_eta

@slava77
Copy link
Contributor

slava77 commented Mar 23, 2014

+1

for #2843 ca398bb
tested in CMSSW_7_1_X_2014-03-18-0200 (sign322 )

No regressions other than in the muon rejection, which are expected.
CPU in TauDiscriminationProducerBase went down by about a factor of 2

@veelken
Copy link
Contributor

veelken commented Mar 23, 2014

Hi Slava,

thank you very much for sharing the plot. It is good to see that the Tight discriminator changed much less.
Analyses that depend on the mu -> tau fake-rate being small use the Tight discriminator.
We will investigate what is causing the difference at abs(eta) ~ 1.

Thanks again,

Christian

On Mar 23, 2014, at 8:24 AM, slava77 wrote:

Hi Christian,

The tight one doesn't have as much of an increase near eta ~2


Reply to this email directly or view it on GitHub.

@cmsbuild
Copy link
Contributor

This pull request is fully signed and it will be integrated in one of the next CMSSW_7_1_X IBs unless changes (tests are also fine). @nclopezo, @ktf can you please take care of it?

davidlange6 added a commit that referenced this pull request Mar 23, 2014
@davidlange6 davidlange6 merged commit c070ce0 into cms-sw:CMSSW_7_1_X Mar 23, 2014
jpavel added a commit to jpavel/cmssw that referenced this pull request Apr 1, 2014
@jpavel jpavel deleted the 71X_taus_QualityCutsImprovement branch May 23, 2014 10:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants