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
Adding HBHE rechits to miniAOD #23540
Adding HBHE rechits to miniAOD #23540
Conversation
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-23540/5123 |
A new Pull Request was created by @Sam-Harper (Sam Harper) for master. It involves the following packages: PhysicsTools/PatAlgos @perrotta, @monttj, @cmsbuild, @slava77, @gpetruc, @arizzi can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
please test |
The tests are being triggered in jenkins. |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
{ | ||
DetId seedId = superClus.seed()->seed(); | ||
if(seedId.det() != DetId::Ecal && seedId.det() != DetId::Forward) { | ||
edm::LogError("EgammaIsoHcalDetIdCollectionProducerError") << "Somehow the supercluster has a seed which is not ECAL, something is badly wrong"; |
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.
Maybe we should better return here
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.
done
Pending items:
|
@perrotta So currently there are data/MC HCAL issues which is blocking 10_2. I think any study I do right now on the thresholds is likely rubbish. When this issue is resolved I think I can make a more meaningful study |
@Sam-Harper : do you plan to have this integrated in 10_2? If so, the deadline for pre6 is ~tomorrow: to go on we need that you take #23540 (review) into account and that you tell us if you are fine with the current hcal thresholds or if you plan to tune them further now @arizzi @gpetruc: we are still waiting for your evaluation of the miniAOD size increase Of course, if you don't want to have it right now in 10_2 there is no hurry for all what above |
opps, pushed to the wrong branch only just noticed. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-23540/5286 |
please test |
The tests are being triggered in jenkins. |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
Looking at the real events, as processed automatically by jenkins with wf 136.85 (RunEGamma2018A): The reco event size increase can be perhaps considered in line with what reported for TTbar MC in #23540 (comment) (taking also into account that this is a EGamma stream and the peak at zero recHits as in the plot attached to the PR description is basically missing):
What puzzles me is what I get when I compare the miniAOD size:
Weren't Can you please comment, Sam? |
Reduced HBHE its is new for the reminiAOD this time around to facilitate studies on the new HCAL. Its nice but not mandatory, it will just make things a bit more difficult as we will have to AOD. Again a judgement call to whether it is worth it. For the AOD, its completely mandatory. In EGamma, we'll always get an electron so we'll almost always get reduced rechits, the ttbar peak at zero was for non electron events. Its not clear these results are incompatible. What I do know is that there is a data/MC missmodelling of low energy HCAL deposits (aka this) in the endcap and we as yet do not know which is "right". |
Hi,
@perrotta: the 1661.9 is the compressed or uncompressed size?
in any case, I agree with sam that the increase on the Egamma PD compared
to TTbar MC is not unexpected, as we save these things only for e/gamma
objects.
(for NanoAOD we compute data size estimates on a mix of Egamma + SingleMu +
JetHT to have a more balanced view of the sizes, but I don't have that
setup in place for miniAOD)
Giovanni
…On Fri, Jun 22, 2018 at 11:29 AM, Sam Harper ***@***.***> wrote:
Reduced HBHE its is new for the reminiAOD this time around to facilitate
studies on the new HCAL. Its nice but not mandatory, it will just make
things a bit more difficult as we will have to AOD. Again a judgement call
to whether it is worth it. For the AOD, its completely mandatory.
In EGamma, we'll always get an electron so we'll almost always get reduced
rechits, the ttbar peak at zero was for non electron events. Its not clear
these results are incompatible.
What I do know is that there is a data/MC missmodelling of low energy HCAL
deposits (aka this) in the endcap and we as yet do not know which is
"right".
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#23540 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AEbbR85uvNgZdPhLvm6zNTIZjEzhZD-xks5t_LkUgaJpZM4Ugm6L>
.
|
1661.9 is the the compressed size The larger reduced RecHit multiplicity in EGamma events is obvious. What I wanted to know is whether the lack of reducedHBHEHits in baseline 10_2_X miniAOD is normal (answering myself: yes, as from https://github.com/cms-sw/cmssw/pull/23540/files#diff-969d6af05ee3397ef11cb0575b31a3abR35). If so, the number given by Sam for miniAOD TTbar in #23540 (comment) should read, instead:
(where the "which was" pointed out in that comment referred to the hypothetical situation in which the reducedHBHEHits would be allowed in the baseline miniAOD eventContent) Did I understand correctly? If so: @arizzi @gpetruc do you confirm that the 950 bytes increase in the TTbar miniAOD event size is still acceptable to you?) |
Ah now I understand the problem, "which was" meant the value we with the old thresholds on this PR. The increase was always said to 950bytes. Sorry for not being clear |
@perrotta: yes, I reconfirm that 950 bytes is ok
…On Fri, Jun 22, 2018 at 2:08 PM, Sam Harper ***@***.***> wrote:
Ah now I understand the problem, "which was" meant the value we with the
old thresholds on this PR. The increase was always said to 950bytes. Sorry
for not being clear
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#23540 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AEbbR5cjBBWrju8IDwizkwTBGmsavMLoks5t_N4kgaJpZM4Ugm6L>
.
|
+1
|
+1 |
merge |
In order to facilitate studies exploiting the updated HE depth segmentation, we would like to store a selection of interesting rec-hits around electron/photons in the miniAOD. This will make it easier to study how to use it and is a better option than randomly guessing and putting likely variables in the electron/photon.
This is done in the same way for ECAL rec hits.
Benchmark sample:
/RelValTTbar_13/CMSSW_10_2_0_pre4-PU25ns_102X_upgrade2018_realistic_v1-v1/GEN-SIM-RECO
cmsDriver command:
cmsDriver.py PAT -s PAT --datatier MINIAOD --runUnscheduled --nThreads 8 --mc --era Run2_2018 --scenario pp --conditions 102X_upgrade2018_realistic_v1 --eventcontent MINIAOD --filein file:/opt/ppd/month/harper/mcFiles/RelValTTbar_13__CMSSW_10_2_0_pre4__PU25ns_102X_upgrade2018_realistic_v1-v1__GEN-SIM-RECO__6E01D9DC-9861-E811-9D9B-0CC47A4D76A2.root --no_exec
using 1000 events.
from edmEventSize:
from "ls" a 0.8% increase
average number of HCAL hits stored : 20.9
I cleaned up the code a little in the interesting rec hit selector to avoid any copy pasting. Also we might have to reduce the HCAL thresholds (currently E>0.8 GeV), need to talk to HCAL to find what is sensible here.