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
Modifications of the Pixel Charge Reweighting for RunDependent MC #37823
Modifications of the Pixel Charge Reweighting for RunDependent MC #37823
Conversation
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-37823/29738
|
A new Pull Request was created by @carolinecollard for master. It involves the following packages:
@cmsbuild, @civanch, @mdhildreth can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
test parameters:
|
please test |
urgent
|
may I ask again for the record, why the urge? |
If this goes into the main release we can do tests with it, my understanding is that McM system doesnt like pre-releases, but maybe I'm wrong there. Alternatively we can let this slip into the next cycle and have a backport but then isnt it just better to set it to |
type trk |
can't the test be done via relvals? Or is PPD directly targeting a MC events production on large scale? |
My understanding that at this point we also need input from O&C about DBS related question. I'm not sure if that can be done with the RelVals or we need McM. Let me tag @rappoccio |
The last time we did this, we used relvals. However, full production will require a bit more coordination and complication. If we go with 12.5 (or even later) we could still test this particular functionality with the relvals while we work with O+C on the full set of production tools. |
@@ -1,6 +1,8 @@ | |||
<use name="DataFormats/Common"/> | |||
<use name="SimDataFormats/EncodedEventId"/> | |||
<use name="boost"/> | |||
<use name="DataFormats/GeometryVector"/> | |||
<use name="root"/> |
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.
Why is the dependence on full ROOT needed?
@@ -35,4 +35,17 @@ | |||
--> | |||
<class name="edm::Wrapper< StripCompactDigiSimLinks >" /> | |||
|
|||
<class name="PixelSimHitExtraInfo" ClassVersion="3"> | |||
<field name="chan" mapping="blob" /> |
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.
What is the intent of this line? (the class does not seem to have chan
member variable)
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.
@makortel Yes, chan
is a member variable of the class. See here.
The history behing these lines : I had a lot of troubles to write the class in the EDM file. The problem was that I saw the new collection within a TBrowser but I was not able to see the content of the chan vector. So at some point in the past, I added the dependence to root in the BuildFile, and also this line in the classes_def.xml. Then later, I realized that I can have accessed to this vector with CMSSW code, but not within an interactive root session. I have never tried to remove these two lines...
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.
"chan" or "chan_"?
-1 Failed Tests: RelVals RelVals-INPUT RelVals
RelVals-INPUT
|
so, the issue with 250202.172 and 250202.182 is that in those workflows the late-reweighting is (rightfully) active, but the needed extra collection (
Not sure how to solve this, as one would need this PR to create a new one. |
so, a possible way forward is:
What do people think? |
70900d5
to
388d825
Compare
unassign reconstruction as far as I can tell, there are no modifications in reco (feel free to correct me if I missed smth). |
This PR was not reconstruction pending to start with. |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-e25ca9/25076/summary.html Comparison Summary@slava77 comparisons for the following workflows were not done due to missing matrix map:
Summary:
|
@cms-sw/simulation-l2 @cms-sw/pdmv-l2 @cms-sw/upgrade-l2 |
+pdmv |
+Upgrade |
+1 |
@cms-sw/orp-l2 this is essentially fully signed |
|
||
array_2d pixrewgt(boost::extents[TXSIZE][TYSIZE]); | ||
|
||
/* |
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.
I don't want to retrigger another set of corrections and signatures, but this commented out code should be removed, even in a follow up PR
+1 |
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 be automatically merged. |
Thx so 60kB per event. Not tiny but not so big
On May 6, 2022 3:32 PM, carolinecollard ***@***.***> wrote:
Thx- seeing tracking particles I suspect the file you used had lots of debug information in it. How many events was that test for?
50 events, with the standart output format.
—
Reply to this email directly, view it on GitHub<#37823 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABGPFQYFQ3VSDLBEDYS2F73VIUNL3ANCNFSM5VFRLTXA>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
PR description:
Modifications of the code to allow the Pixel Charge Reweighting at the mixing step in view of future runDependent MC production. The idea is first to produce a premix Library in which no Charge Reweighting is applied, but with stored extra SimHit Information. Then in a second step, during the mixing part, a "Late" Charge Reweighting is applied on the digis from PU, using the extra information. See Last presentation during the AlcaDB meeting for more details.
By default, the standard Charge Reweighting is applied.
To use the new functionality, the
runDependent
processModifier can be used (but for the moment there is a problem with running this processModifier with the 2018 or 2021 configurations -- AlcaDB people are aware of that).Some review has already been done within the tracker DPG group.
PR validation:
The standard runTheMatrix workflows should give no differences, because by default we stay with the standard Charge Reweighting approach.
A lot of tests have been performed within the Pixel Offline group to understand the impact of using the Late Charge Reweighthing approach. Comparisons between the two approaches (Standard and Late CR) have been done and differences are understood and expected.