EMTF configures from Global Tag conditions in MC as well as data #29260
Conversation
Due to previous issues with CondDB / O2O payloads, the EMTF emulator had configured via firmware version only in data. Many of the settings in MC emulation defaulted to their 2018 versions, which would cause problems for 2016 and 2017 MC processing. This fixes the EMTF emulation so it properly uses all 2016 or 2017 conditions for MC emulation.
|
The code-checks are being triggered in jenkins. |
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-29260/14302
|
|
A new Pull Request was created by @abrinke1 for master. It involves the following packages: L1Trigger/L1TMuonEndCap @cmsbuild, @rekovic, @benkrikler can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
|
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:
You can see more details here: |
|
Comparison job queued. |
|
Comparison is ready Comparison Summary:
|
|
urgent |
|
merge |
|
@abrinke1 are the changes in |
|
Hi @silviodonato , @rekovic , From what I can see, all these changes are to the L1T muon plots, and the distributions change only slightly. This is expected, as the EMTF algorithm has changed, but it is not a dramatic change. |
"master" version of #29252
Intended for all future versions of EMTF emulator.
We have unfortunately uncovered another error in the EMTF emulation for 2016, which had been masked by the previous one. [1] As it turns out the emulator was not accessing the 2016 or 2017 Global Tag conditions for most of the algorithm settings, creating a mix of 2016 or 2017 and 2018 logic which is internally inconsistent. Efe measured the efficiency in the latest 2016 RelVal samples (see attached slides), and due to this bug it is 10% lower in the negative endcap than in the positive.
Thankfully the fix is quite simple, as you can see in this pull request. Efe's plots confirm that the efficiency looks good when re-running the newest RelVals with this patch applied, and is consistent with the efficiency in 2016 data. [2]
For historical background on the likely cause for this bug, between 2016 and 2017 we completely overhauled the EMTF emulator, in part to handle the new RPC inputs. Unfortunately both the CondDB code and payloads for EMTF at that point were in disarray (very long story), and accessing the conditions payload was crashing the MC RelVals. At that point (if my hazy memory serves) we decided to configure by firmware version only for data, and by "fake conditions" for MC, with 3 different "fake conditions" python config files. Sometime subsequently the "fake conditions" for each year went away, so the MC emulation (again, for some but not all of the algorithm settings) used the default settings, instead of the time-dependent firmware version settings. This worked fine when the "default" settings were also the "current" settings (which was true when the 2017 and 2018 MC were produced), but fails for 2016. re-emulation. Long story short, our workflows had never been fully validated for legacy MC, and now we're finding the bugs - for which we apologize.
[1] #29080
[2] https://twiki.cern.ch/twiki/bin/view/CMSPublic/L1TMuonPerformanceICHEP16
EMTF_UL16MC_validation_19.03.2020.pdf