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
E/gamma T&P Offline DQM : 92X + VID + GenericTrigEventFlag Changes #19046
Conversation
A new Pull Request was created by @Sam-Harper for master. It involves the following packages: CommonTools/TriggerUtils @perrotta, @monttj, @dmitrijus, @cmsbuild, @slava77, @vanbesien, @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 @slava77 comparisons for the following workflows were not done due to missing matrix map:
Comparison Summary:
|
if(!physicsObjectsHandle.isValid()){ | ||
edm::LogWarning("InvalidCollection")<< | ||
"physics objects collection is invalid, no VID info will be written"; | ||
return; |
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 this producer can not run, why is it in the configuration?
I think that this "graceful fail" should be removed and the issue resolved at configuration level.
Also, simple return is bad: the producer should still put the products in the event.
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.
Yes, I was wondering about how to do this.
It all come from the fact I dont know how to have this included in the pp DQM sequence and not HI sequence (it failed in HI tests). Also speaking as somebody who occasionally has to hack things around to get to run in unusual work flows, having modules which fail gracefully when their inputs are not present is kinda nice. However I admit thats a very weak reason.
So how can I detect that gedGsfElectrons are not present (either in the input file or a producer to make it) or disable them from HI DQM?
Pull request #19046 was updated. @perrotta, @monttj, @dmitrijus, @cmsbuild, @slava77, @vanbesien, @davidlange6 can you please check and sign again. |
Okay VID is back to exactly how it was. Now its properly removed from HI DQM sequences instead. Yes this way is the correct way to do it thanks Slava (and sorry Mia, I didnt understand you before, I think this is what you were telling me). Not entirely sure why I didnt do this in the first place, I blame the lack of sleep recently! Btw I'm traveling shortly for the weekend so its unlikely I'll be able to respond to any further changes till monday. However I think we're good though, the changes here are just for the new E/g DQM, even if they are not perfect, they produce acceptable results and we can fine tune for the next train. And the only changes to existing code is the GenericTriggerEvent flag which actually fixes an issue (bare -> smart pointer) and adds a backwards compatible change. |
thanks !!!!
(yes, this is what I was suggesting :P )
can we start the integration test, please ?
ps: enjoy your weekend !
…On Fri, Jun 2, 2017 at 7:37 AM, Sam-Harper ***@***.***> wrote:
Okay VID is back to exactly how it was. Now its properly removed from HI
DQM sequences instead. Yes this way is the correct way to do it thanks
Slava (and sorry Mia, I didnt understand you before, I think this is what
you were telling me). Not entirely sure why I didnt do this in the first
place, I blame the lack of sleep recently!
Btw I'm traveling shortly for the weekend so its unlikely I'll be able to
respond to any further changes till monday. However I think we're good
though, the changes here are just for the new E/g DQM, even if they are not
perfect, they produce acceptable results and we can fine tune for the next
train. And the only changes to existing code is the GenericTriggerEvent
flag which actually fixes an issue (bare -> smart pointer) and adds a
backwards compatible change.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#19046 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AEt5877fgxNcwo0CjD4cxQU12nhyUFrkks5r_5-igaJpZM4Nr9kY>
.
|
please test |
The tests are being triggered in jenkins. |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
+1 |
we have "pending signature", could we move on, please ? |
GenericTriggerEventFlag::GenericTriggerEventFlag( const edm::ParameterSet & config, edm::ConsumesCollector & iC): | ||
GenericTriggerEventFlag(config,iC,false) | ||
{ | ||
if ( config.exists( "andOrL1" ) ) { |
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.
Hi @Sam-Harper - given the GenericTriggerEventFlag(config,iC,false) call, is this needed?
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.
Hi David,
Many thanks for the review. So I think this not strictly needed but it does simplify things for me.
I wanted to leave the original public constructor:
https://github.com/Sam-Harper/cmssw/blob/9636bcf9626f001993f6d941c1b598a8b7eb3a13/CommonTools/TriggerUtils/interface/GenericTriggerEventFlag.h#L157-L169
exactly as is. Which means all the l1 setup gets done outside the private constructor (which is now tagged with an extra argument of a bool). A dirty little secret, that bool is only there to identify the private contructor,
could easily just be at the location you mention and inside the config.exists("andOrL1") statement. But I put it in the private constructor simply because I didnt like having an unused variable.
As written, it is simpler to have all the L1 construction happening in the public constructors and a shared private constructor which does the rest of the setup. Note, the false only means it is an error that stage-1 is selected, stage-2 can be setup.
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.
ok, it seemed like it was just repeating things to me. Thanks to for the explanation.
tracked by #19142 |
This PR includes a backport of the following PRs: - cms-sw#18172 - cms-sw#18950 - cms-sw#18959 - cms-sw#18968 - cms-sw#18971 - cms-sw#19023 - cms-sw#19046 - cms-sw#19078 - cms-sw#19119 - cms-sw#19178 - cms-sw#19290 - cms-sw#19293 - cms-sw#19294 - cms-sw#19490 - cms-sw#19499 - cms-sw#19577 - cms-sw#19585 - cms-sw#19596 - cms-sw#19599 - cms-sw#19627 - cms-sw#19689 - cms-sw#19694 - cms-sw#19703 - cms-sw#19781 - cms-sw#19794 plus the older ones, contained in DQMOffline/Trigger and HLTriggerOffline. It synchronises with CMSSW_9_3_X - DQMServices/ClientConfig - DQMOffline/Configuration - DQMOffline/Trigger - HLTriggerOffline/Btag - HLTriggerOffline/Higgs - HLTriggerOffline/SUSYBSM - HLTriggerOffline/Tau - HLTriggerOffline/Top
This PR includes a backport of the following PRs: - cms-sw#18172 - cms-sw#18950 - cms-sw#18959 - cms-sw#18968 - cms-sw#18971 - cms-sw#19023 - cms-sw#19046 - cms-sw#19078 - cms-sw#19119 - cms-sw#19178 - cms-sw#19290 - cms-sw#19293 - cms-sw#19294 - cms-sw#19490 - cms-sw#19499 - cms-sw#19577 - cms-sw#19585 - cms-sw#19596 - cms-sw#19599 - cms-sw#19627 - cms-sw#19689 - cms-sw#19694 - cms-sw#19703 - cms-sw#19781 - cms-sw#19794 plus the older ones, contained in DQMOffline/Trigger and HLTriggerOffline. It synchronises with CMSSW_9_3_X - DQMServices/ClientConfig - DQMOffline/Configuration - DQMOffline/Trigger - HLTriggerOffline/Btag - HLTriggerOffline/Higgs - HLTriggerOffline/SUSYBSM - HLTriggerOffline/Tau - HLTriggerOffline/Top
This PR includes a backport of the following PRs: - cms-sw#18172 - cms-sw#18950 - cms-sw#18959 - cms-sw#18968 - cms-sw#18971 - cms-sw#19023 - cms-sw#19046 - cms-sw#19078 - cms-sw#19119 - cms-sw#19178 - cms-sw#19290 - cms-sw#19293 - cms-sw#19294 - cms-sw#19490 - cms-sw#19499 - cms-sw#19577 - cms-sw#19585 - cms-sw#19596 - cms-sw#19599 - cms-sw#19627 - cms-sw#19689 - cms-sw#19694 - cms-sw#19703 - cms-sw#19781 - cms-sw#19794 plus the older ones, contained in DQMOffline/Trigger and HLTriggerOffline. It synchronises with CMSSW_9_3_X - DQMServices/ClientConfig - DQMOffline/Configuration - DQMOffline/Trigger - HLTriggerOffline/Btag - HLTriggerOffline/Higgs - HLTriggerOffline/SUSYBSM - HLTriggerOffline/Tau - HLTriggerOffline/Top
This a re-submission of #18969 which went all bit wrong and I have zero time to fix. I have copied over the PR text below.
This also modifies VID producers not to crash on missing object input collections. This was necessary and the reason why is discussed in the comments of the change. Finally it makes backwards compatible changes to GenericTriggerEventFlag so I dont need to pass in the EDProducer address and at the same time makes it movable by turning the last pointer to a std::unique_ptr
Original PR text:
This is an initial version of the E/gamma T&P offline DQM. This code is near feature complete and produces correct output (as far as I can tell) . However there are some layout and naming issues which I would like to solicit suggestions for before this PR is considered for integration.
The goal of this class is to be object agnostic, hence the templating.
The idea is very simple.
Select the event with a trigger. Require the tag to pass an HLT requirement & selection requirement. Require the probes to pass other selection requirements to entire the sample. Mass and opposite sign requirements are then applied.
There are then a series of histograms associated with each filter we wish to measure, one for all probe passing sample cuts and probes then passing the filter.
There are various levels of tag, probe kinematic and trigger selection: all t&p pairs (ie tag in barrel, passing tag trigger), all histograms of a filter (ie requiring Et to be > threshold, tag to pass an additional trigger, ie the single leg of a double legged trigger), and a specific histogram (ie requiring the probe to be in the endcap to measure the turn on in the endcap region only).
All the magic is in https://github.com/Sam-Harper/cmssw/blob/32a8b63ed2afd1a80771776d7c441b40cd3367bb/DQMOffline/Trigger/interface/HLTTagAndProbeEff.h
There are 3 main classes
HLTTagAndProbeEff : creates tag and probe pairs and then passes the pairs to the histograms.
HLTDQMHistColl : corresponds to a single filter for which we wish to measure the efficiency. Can apply additional selection to the tag & probe (ie restricting them to certain Et, eta ranges, requiring the tag to pass additional HLT requirements). Contains all the individual histograms which are of type HLTDQM1DHist and HLTDQM2DHist and automically fill themselves with the specified vs variable
RangeCutColl: ID selection is handled by edm::ValueMap this class is intended to cut on kinematic variables such as et, eta, phi. It allows us to restrict to a certain eta region (tags in the barrel, probes in HEP17, probes > Et threshold etc)
For the ID selection of tag & probe it was intended to use VID but I didnt get it working so made a temporary ID module to do that for the time being.
Suggestions on names and how to split them up are welcome. RangeCutColl and HLTDQMHist share the same mechanism to store the variable in question which is the sticking point.
Also suggestion on alternative ways to achieve the this are also welcome although performance/clarity gains would have to balanced against work required to make them.