Enable HLT tau filtering based on jet-tags (ParticleNet) #43100
Conversation
|
FYI, @kandrosov |
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-43100/37342
|
|
A new Pull Request was created by @mbluj for master. It involves the following packages:
@cmsbuild, @jfernan2, @mmusich, @Martin-Grunewald, @mandrenguyen, @missirol can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
mbluj
changed the title
|
@cmsbuild, please test |
|
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-fc6b04/35399/summary.html Comparison SummarySummary:
|
There was a problem hiding this comment.
I have only few very minor comments.
In general please squash the last 3 commits (see discussion at cms-sw/cms-bot#2080 for a rationale)
In any case I'll wait for the talk at the TSG meeting before signoff.
mbluj
force-pushed
the
CMSSW_13_3_X_tau-pog_pnetTauAtHLT
branch
from
053a33a
to
8cd6342
Compare
cmsbuild
added
l1-pending
generators-pending
tests-pending
code-checks-pending
and removed
tests-approved
code-checks-approved
labels
…ype of objs to match, address case of matching dR<0 and code-formatting
|
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-fc6b04/35412/summary.html Comparison SummarySummary:
|
|
+hlt Concerning the test results:
|
|
@mbluj, as discussed yesterday during the TSG meeting of Oct 25th please prepare a corresponding backport to 13.2.X, so that integration of the relevant paths using this new filter can proceed. Thank you. |
Sure, it will be done. |
|
type tau |
|
+1 |
cmsbuild
added
reconstruction-approved
fully-signed
and removed
reconstruction-pending
pending-signatures
labels
|
This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @antoniovilela, @sextonkennedy, @rappoccio (and backports should be raised in the release meeting by the corresponding L2) |
|
+1 |
| try { | ||
| size_t pos = 0; | ||
| value_ = std::stod(cut_str, &pos); | ||
| simple_value = (pos == cut_str.size()); | ||
| } catch (std::invalid_argument&) { | ||
| } catch (std::out_of_range&) { | ||
| } |
There was a problem hiding this comment.
This violates the CMSSW coding rules:
7.11 In general, do not catch exceptions – leave them to the Framework (see Exception Guidelines).
These changes should not have been accepted in the current state. Please fix this misuse ASAP.
There was a problem hiding this comment.
@mbluj can you have a look? This is in the way of further development of the HLT menu for 2024.
There was a problem hiding this comment.
Do I understand correctly that try-catch can be simply removed as exceptions will be cached by framework?
@fwyzard for my curiosity: those exception catches was found because the exceptions have been thrown or it was done with other means?
There was a problem hiding this comment.
Do I understand correctly that try-catch can be simply removed as exceptions will be cached by framework?
Exceptions caught by the framework will usually cause the jobs to terminate.
@fwyzard for my curiosity: those exception catches was found because the exceptions have been thrown or it was done with other means?
These exceptions have been noticed running cmsRun hlt.py under gdb and telling it to catch exceptions, in order to investigate were some failures are happening.
These try/catch blocks add a lot of noise to the debugging sessions, making it harder to figure out were the real problems are happening.
In general, in CMSSW it is discouraged to use try/catch as a way to check if a condition is valid or not; it's better to do an explicit check.
This approach is idiomatic in python, where checking for an exception is almost as fast as checking for a return value. In C++, the regular return values are faster, and the exceptions are slower.
There was a problem hiding this comment.
@mbluj having a parsing error at this stage is ok; it just means that WP is not a "simple value". So I think your code should be modified like this:
const char* cut_cstr = cut_str.c_str(); char* end_cstr; value_ = std::strtod(cut_cstr, &end_cstr); simple_value = end_cstr != cut_cstr && std::isfinite(value_);(without any
throw)
Yes, indeed.
There was a problem hiding this comment.
Okay, the code I proposed above is also wrong. For example, for cut_str="1 + 1", it will return simple_value=true and _value=1, which is not intended. So should be something like this:
const char* cut_cstr = cut_str.c_str();
char* end_cstr;
value_ = std::strtod(cut_cstr, &end_cstr);
const bool simple_value = end_cstr != cut_cstr && static_cast<std::size_t>(end_cstr - cut_cstr) == cut_str.size() && value_ != HUGE_VALF;There was a problem hiding this comment.
it is enough to check if end_cstr is empty !*end_cstr, so the piece of code can be like this:
const char* cut_cstr = cut_str.c_str();
char* end_cstr{};
value_ = std::strtod(cut_cstr, &end_cstr);
simple_value = (!*end_cstr && cut_cstr != end_cstr && std::isfinite(value_));
if (!simple_value) {
I think std::isfinite(value_) is better than value_ != HUGE_VAL as it does not accept nan. BTW, current code accepts both nan and inf as a valid "simple_value".
There was a problem hiding this comment.
Okay. Perhaps, as in your original proposal, an exception should be thrown for inf and especially nan - I don't see any use cases where one would want to use them in valid configs...
Is std::isfinite(HUGE_VALF) == false guaranteed, or could it be compiler-dependent? To make sure that we account for all possible return scenarios.
There was a problem hiding this comment.
Quote from cppreference:
On implementations that support floating-point infinities, these macros (HUGE_VALF, HUGE_VAL, HUGE_VALL) always expand to the positive infinities of float, double, and long double, respectively."
So, I think it is OK to check if value_ is finite.
In the current implementation not-finite numbers are treated as not being a "simple_value" and as they are not correct threshold expressions an exception is thrown.
BTW, for double one should use HUGE_VAL rather than HUGE_VALF that is for float.
PR description:
This PR adds an HLT filter of tau candidates based on jet-tagger scores. This filter, in particular, enables tau filtering based on particle-net.
The PR introduces the following changes:
TauTagFilter: an event filter based on the number of tau candidates that pass a selection which combines kinematic requirements (pt, eta) and requirements on jet-tagging. Optionally it also requires a matching with seeds and applies a pt correction;TauWPThresholdutility class fromDeepTauIdcode to a separate file to be used by bothDeepTauIdandTauTagFilter(and possibly others in future);L2TauTagFilter.ccto set correct id to output object.No changes are expected in existing workflows (except correct id of objects returned by
L2TauTagFilter).Detailed performance of new HLT paths using newly introduced TauTagFilter and based on particle-net taggers presented at the TSG meeting on 2023-10-25: link to indico.
PR validation:
Code tested using CMSSW_13_3_0_pre3 with a custom HLT python configuration (with MC): hltMC_PNet_tau.py
The matrix tests
runTheMatrix.py -l limited -i all --ibeossuccessful.