-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Modification of cone based tau algorithm to furbish it as fallback solution for the HLT for upcoming data taking #18429
Conversation
Modified Cone-based Tau Builder
…pog_technical-developments_coneBasedTaus
A new Pull Request was created by @roger-wolf (Roger Wolf) for master. It involves the following packages: RecoTauTag/RecoTau @perrotta, @cmsbuild, @slava77, @davidlange6 can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
@cmsbuild please test |
The tests are being triggered in jenkins. |
+1 The following merge commits were also included on top of IB + this PR after doing git cms-merge-topic: |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
int charge = 0; | ||
int leadCharge = aTau.leadPFChargedHadrCand().isNonnull() ? aTau.leadPFChargedHadrCand()->charge() : 0; | ||
const std::vector<reco::PFCandidatePtr>& pfChs = aTau.signalPFChargedHadrCands(); | ||
for(std::vector<reco::PFCandidatePtr>::const_iterator pfCh = pfChs.begin(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Range based for loops must be preferred
piZero != piZeros.end(); ++piZero) { | ||
double photonSumPt_insideSignalCone = 0.; | ||
double photonSumPt_outsideSignalCone = 0.; | ||
int numPhotons = piZero->numberOfDaughters(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mantain indentation
PFTau::hadronicDecayMode dm = PFTau::kNull; | ||
unsigned int nPiZeros = 0; | ||
const std::vector<RecoTauPiZero>& piZeros = aTau.signalPiZeroCandidates(); | ||
for(std::vector<RecoTauPiZero>::const_iterator piZero = piZeros.begin(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Range based for loops must be preferred
const unsigned int maxPiZeros = PFTau::kOneProngNPiZero; | ||
// Determine our track index | ||
unsigned int nCharged = pfChs.size(); | ||
unsigned int trackIndex = (nCharged - 1)*(maxPiZeros + 1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If pfChs.size()=0 this may lead to an indefinite number (as unsigned int): can it happen?
…pog_technical-developments_coneBasedTaus
Comparison job queued. |
Comparison is ready Comparison Summary:
|
for producer in producers_by_type(process, "RecoTauProducer"): | ||
if hasattr(producer,'builders'): | ||
for pset in producer.builders: | ||
if not hasattr(pset,'minAbsPhotonSumPt_insideSignalCone'): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so this looks to be just a more inefficient version of existsAs... Could this not be replaced by a fillDescriptions instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@davidlange6 Yes, in principle fillDescriptions will solve this and similar issues caused by the fact that HLT configuration is dumped from ConfDB which knows on new parameters only when a new release is parsed into it. The thing is that the tau reco code uses quite heavily plugin factories which, at least in my understanding, are quite incompatible with the fillDescriptions mechanism. So mitigation from python cfi files to the fillDescriptions mechanism means rewriting tau code which is a big effort.
I'm not sure what prevents the plugins to use fillDescriptions - but in the meanwhile, i think I would then suggest the bad old fashioned existsAs as to avoid yet another loop over all producers in the HLT. but maybe i don't know all the constraints.
… On May 2, 2017, at 10:49 AM, mbluj ***@***.***> wrote:
@mbluj commented on this pull request.
In HLTrigger/Configuration/python/customizeHLTforCMSSW.py:
> @@ -71,6 +71,18 @@ def customiseFor18330(process):
for pset in producer.vertexCollections:
if pset.algorithm.value() == "AdaptiveVertexFitter" and not hasattr(pset, "chi2cutoff"):
pset.chi2cutoff = cms.double(3.0)
+ return process
+
+
+# Add new parameters required by RecoTauBuilderConePlugin
+def customiseFor18429(process):
+ for producer in producers_by_type(process, "RecoTauProducer"):
+ if hasattr(producer,'builders'):
+ for pset in producer.builders:
+ if not hasattr(pset,'minAbsPhotonSumPt_insideSignalCone'):
@davidlange6 Yes, in principle fillDescriptions will solve this and similar issues caused by the fact that HLT configuration is dumped from ConfDB which knows on new parameters only when a new release is parsed into it. The thing is that the tau reco code uses quite heavily plugin factories which, at least in my understanding, are quite incompatible with the fillDescriptions mechanism. So mitigation from python cfi files to the fillDescriptions mechanism means rewriting tau code which is a big effort.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
On Tue, May 2, 2017 at 12:16 PM, David Lange <notifications@github.com>
wrote:
I'm not sure what prevents the plugins to use fillDescriptions
Maybe it is my ignorance, but tau reco has a nested structure with one
plugin calling other ones. Depending on configuration the set of nested
plugins can be different, so I do not think that there is a way of sensible
configuration of them with fillDescriptions.
- but in the meanwhile, i think I would then suggest the bad old fashioned
existsAs as to avoid yet another loop over all producers in the HLT. but
maybe i don't know all the constraints.
It is what we agree, the existsAs constructions should be removed. But,
this particular customization (customiseFor18429) is not about this; it
just adds missing tracked parameters to HLT configuration as the
configuration does not know nothing about them. It is as it the HLT
configuration dumped from ConfDB where configuration templates come from an
older release. The customization is temporary and will disappear when
configuration in HLT ConfDB are refreshed with newer release. I hope, that
this time I was able to explain it more clear than previously.
…
> On May 2, 2017, at 10:49 AM, mbluj ***@***.***> wrote:
>
> @mbluj commented on this pull request.
>
> In HLTrigger/Configuration/python/customizeHLTforCMSSW.py:
>
> > @@ -71,6 +71,18 @@ def customiseFor18330(process):
> for pset in producer.vertexCollections:
> if pset.algorithm.value() == "AdaptiveVertexFitter" and not
hasattr(pset, "chi2cutoff"):
> pset.chi2cutoff = cms.double(3.0)
> + return process
> +
> +
> +# Add new parameters required by RecoTauBuilderConePlugin
> +def customiseFor18429(process):
> + for producer in producers_by_type(process, "RecoTauProducer"):
> + if hasattr(producer,'builders'):
> + for pset in producer.builders:
> + if not hasattr(pset,'minAbsPhotonSumPt_insideSignalCone'):
>
> @davidlange6 Yes, in principle fillDescriptions will solve this and
similar issues caused by the fact that HLT configuration is dumped from
ConfDB which knows on new parameters only when a new release is parsed into
it. The thing is that the tau reco code uses quite heavily plugin factories
which, at least in my understanding, are quite incompatible with the
fillDescriptions mechanism. So mitigation from python cfi files to the
fillDescriptions mechanism means rewriting tau code which is a big effort.
>
|
On 2 May 2017 at 12:36, mbluj ***@***.***> wrote:
> I'm not sure what prevents the plugins to use fillDescriptions
Maybe it is my ignorance, but tau reco has a nested structure with one
plugin calling other ones. Depending on configuration the set of nested
plugins can be different, so I do not think that there is a way of sensible
configuration of them with fillDescriptions.
The required functionality is in my wish list of CMSSW features since few
years...
.A
…--
Strategy is a system of expedients.
Generalfeldmarschall Helmuth Karl Bernhard Graf von Moltke
|
any idea what functionality is actually missing? Some "CMSSW" (eg, framework) feature or just that developers need to do something?
I would have thought that any plugin could define a static function that gets called by the module level fillDescriptions to hierarchically define a pset. I've not thought about issues such as dependencies however. Has anyone tried an implementation that didn't work out?
… On May 2, 2017, at 1:07 PM, Andrea Bocci ***@***.***> wrote:
On 2 May 2017 at 12:36, mbluj ***@***.***> wrote:
> > I'm not sure what prevents the plugins to use fillDescriptions
>
> Maybe it is my ignorance, but tau reco has a nested structure with one
> plugin calling other ones. Depending on configuration the set of nested
> plugins can be different, so I do not think that there is a way of sensible
> configuration of them with fillDescriptions.
>
The required functionality is in my wish list of CMSSW features since few
years...
.A
--
Strategy is a system of expedients.
Generalfeldmarschall Helmuth Karl Bernhard Graf von Moltke
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
@davidlange6 See e.g. #12517 (comment), and especially https://hypernews.cern.ch/HyperNews/CMS/get/edmFramework/3446/1.html. (personally I've given up the hope in favour of moving helper plugins to ED/ESProducts, depending if they need |
thanks.
… On May 2, 2017, at 2:10 PM, Matti Kortelainen ***@***.***> wrote:
@davidlange6 See e.g. #12517 (comment), and especially https://hypernews.cern.ch/HyperNews/CMS/get/edmFramework/3446/1.html.
(personally I've given up the hope in favour of moving helper plugins to ED/ESProducts, depending if they need edm::Event or not, even if this approach is rather laborious)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
to be clear I said the opposite - we removed an ugly, but fast/simple construct (existsas) in favor of an ugly and slow construct (for modules in hlt loop....). |
On 4 May 2017 at 10:50, David Lange ***@***.***> wrote:
to be clear I said the opposite - we removed an ugly, but fast/simple
construct (existsas) in favor of an ugly and slow construct (for modules in
hlt loop....).
The "ugly, but fast/simple construct (existsas)" happened at runtime, and
was not tracked in the provenance.
The "ugly and slow construct (for modules in hlt loop....)" can be made to
happen only once by dumping the configuration (which I think crab and other
tools do), and not at all once the new configuration is parsed and made
available. In addition the provenance sees the expanded configuration with
all the parameters.
.A
…--
Strategy is a system of expedients.
Generalfeldmarschall Helmuth Karl Bernhard Graf von Moltke
|
Since this PR has become a 92X PR, please make an explicit 91X PR as well! |
+1 |
Since this PR has become a 92X PR, please make an explicit 91X PR as well!
Thanks!
Done: #18581
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
|
Dear colleagues,
this is a pull request by @mbluj that contains modifications of the cone based tau reconstruction algorithm as used for the HLT to make it fit for upcoming data taking periods, as fallback in case that the planned HPS-port to the HLT won't be ready in time. I'm citing Michal's comments (*) and refer to him for further questions.
Cheers,
Roger
(*)
This PR is to modify the Cone-based tau builder (used at HLT) to fill some additional data members of produced PFTau not filled so far:
The changes do not modify current HLT work-flow (the builder is used only at HLT), but provides new features (cf. 2) allowing better jet->tau fake rejection during 2017 data-taking.
This is PR to 91X on top of changes proposed for tau vertex association (cf. #18243), a separate PR for 90X will follow shortly.