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
New cluster shape filter for phase2 + adding PixelPair #17891
Conversation
A new Pull Request was created by @VinInn (Vincenzo Innocente) for master. It involves the following packages: RecoPixelVertexing/PixelLowPtUtilities @perrotta, @cmsbuild, @slava77, @davidlange6 can you please review it and eventually sign? Thanks. cms-bot commands are listed here #13028 |
@cmsbuild please test |
The tests are being triggered in jenkins. |
assign upgrade |
Comparison job queued. |
@@ -150,10 +158,12 @@ | |||
) | |||
trackingPhase1PU70.toModify(highPtTripletStepTrajectoryBuilder, | |||
MeasurementTrackerName = '', | |||
maxCand = 4, |
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 do you want to change this? I thought that this era was frozen.
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.
Doesn't matter, trackingPhase1PU70
is not used in any workflow, and I'll clean it up sometime soon.
Thanks @VinInn . Can you please describe the legend in the files you have posted? |
assign upgrade |
New categories assigned: upgrade @kpedro88 you have been requested to review this Pull request/Issue and eventually sign? Thanks |
@VinInn Is it "for upcoming developments"? |
I added the files to allow people to easily test different options changing just the config... |
Indeed, a nice improvement both for physics and resource usage |
+1
|
+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 requires discussion in the ORP meeting before it's merged. @Muzaffar, @davidlange6, @smuzaffar |
+1 |
On 3/17/17 2:58 AM, ebrondol wrote:
@slava77 <https://github.com/slava77> did you also performed the check
on D11? Or just a rough idea if my report in PR #17919
<#17919> is compatible with your report?
No, I did not check D11.
Remind me please the significance of it.
From README:
D4 = T3+C2+M1+I1
D11 = T5+C2+M1+I1
and
T3: Phase2 tilted tracker (v3.6.5) w/ phase 2 pixel (v4.0.2.6)
T5: Phase2 tilted tracker (v3.6.5) w/ phase 2 pixel (v4.0.2.5)
{the pixel (v4.0.2.5) has one more FPIX disk}
Is this 8+4 pixel going to become the new default or is it a side-test?
…
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#17891 (comment)>, or
mute the thread
<https://github.com/notifications/unsubscribe-auth/AEdcbp-ga4OwKFqSaK53XikbFt946Jkeks5rmllCgaJpZM4MaNHE>.
|
As far as I understood, the nomenclature T3 and T5 will remain the same with the idea of having a "validated tracker" (T3) and a "testing tracker" (T5). If T5 will succeed the tests and the validation we are going to do with the next RelVal production, it will become the new default (T3). |
On 3/17/17 4:54 AM, ebrondol wrote:
As far as I understood, the nomenclature T3 and T5 will remain the same
with the idea of having a "validated tracker" (T3) and a "testing
tracker" (T5). If T5 will succeed the tests and the validation we are
going to do with the next RelVal production, it will become the new
default (T3).
@boudoul <https://github.com/boudoul> @kpedro88
<https://github.com/kpedro88> please confirm if I am correct.
One more disk is probably an increment in cost,
but if that's becoming a default, OK, I will move to it once it's clear.
No intention so far to check two workflows in parallel from my side ...
at least not until we stop writing more than 100MB/event in step3 workflows.
…
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#17891 (comment)>, or
mute the thread
<https://github.com/notifications/unsubscribe-auth/AEdcbpvJ_Px6ND0Xyt87BnE8SWTF5B6Zks5rmnSBgaJpZM4MaNHE>.
|
@ebrondol that wasn't really my understanding... if there's going to be another new tracker, I assumed it would get its own number. What you propose could be done, but since we are preparing for more TDR productions, we need to be very careful about changing the baseline geometry. |
Dear all , we are keeping T3 , mostly because all production which has been done so far (and presumably more to come) are all based on T3 - Physics results for the tracker TDR are and will be based on T3 - However T3 is not a version that eventually will be in the real detector, and we are devloping T5 with with respect- T5 will be used to derive tracker-tracking performance (eventually to be also added within the TDR) , but indeed we should keep T3 (not merging or at least not in a short time scale defined by TDRs) |
This Pr includes three main changes (all connected )
1a) I explicitly added two files for two efficiency WP 99.5 and 99.9 the default (at the moment a copy) is 99.5
(so PixelPair cover only the regions not covered by quadruplets)
MTV
1000 single muon (blue pre5, red WP99p5, orange Wp99p9, black this PR)
http://innocent.home.cern.ch/innocent/RelVal/Muon10csf99/plots_ootb/effandfake1.pdf
250 ttbar PU200 (blue pre5, red WP99p9, black Wp99p5, orange this PR)
http://innocent.home.cern.ch/innocent/RelVal/ttbar200PUcsf/plots_ootb/effandfake1.pdf
timing ttbar PU200 tracking only +DQM
900_pre5
this PR
obsoletes #17810