Pdigitizer dynamic ineff fpix

[ahazi137]

This is an extension of pixel digitizer's dynamic inefficiency feature for endcap disks in current detector as part of Run2 preparation.
New configurable variables: theInstlumiScaleFactor, bunchScale (which depends on bunchpace value).
Currently all config variables are under discussion with the tracker experts, the final factors will be in a different PR with config file changes only.

[cmsbuild]

A new Pull Request was created by @ahazi137 for CMSSW_7_3_X.

Pdigitizer dynamic ineff fpix

It involves the following packages:

SimGeneral/MixingModule
SimTracker/SiPixelDigitizer

@cmsbuild, @civanch, @nclopezo, @mdhildreth can you please review it and eventually sign? Thanks.
@wmtan, @makortel, @GiacomoSguazzoni, @rovere, @VinInn, @appeltel, @dkotlins, @cerati, @threus, @dgulhan, @venturia this is something you requested to watch as well.
You can sign-off by replying to this message having '+1' in the first line of your reply.
You can reject by replying to this message having '-1' in the first line of your reply.

[veszpv]

Please, change this line into something easier to interpret:

if ((tTopo->pxfPanel(detID)+tTopo->pxfModule(detID))<4)

[cmsbuild]

+1
Tested at: 8c5937d
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-6007/389/summary.html

[cmsbuild]

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-6007/389/summary.html

[rovere]

Hey, dummy question: I see this parameter has been introduced and the old, hard-coded value of 221.95 has been dismissed. Does this affect also the Barrel part of the inefficiency? At what level?

[veszpv]

We need this change in order to re-scale the meaning of 1 PU when going from 8 TeV to 13 TeV. The track multiplicity per PU increases by 18% with the higher collision energy. The title of the PR is misleading in the sense that there are two changes additional to introducing inefficiency in FPix: correcting for higher energy and introducing a new variable to specialize for the 25 ns bunch spacing.

[civanch]

@ahazi137 , extra dummy question: does code applicable to 8 TeV re-digitization? Until now, our default set of parameters was always for run-1. For run-2 some parameters are changed via customization.

[cmsbuild]

+1
Tested at: b18b520
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-6007/421/summary.html

[cmsbuild]

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-6007/421/summary.html

[veszpv]

By introducing the new variable theInstLumiScaleFactor, the digitizer
can be adjusted back to the 8 TeV mode by changing its value in the
config file. Obviously, this is suboptimal, but our immediate goal is to
be ready for the 2015 MC production. If the collision energy were known
to the digitizer, the digitizer could select the right PU cross section
already in this version. More sophisticated solutions require more
elaborate and time consuming code development.

On 2014-10-28 12:27, Vladimir Ivantchenko wrote:

@ahazi137 [1] , extra dummy question: does code applicable to 8 TeV
re-digitization? Until now, our default set of parameters was always
for run-1. For run-2 some parameters are changed via customization.

Reply to this email directly or view it on GitHub [2].

Links:

[1] https://github.com/ahazi137
[2] #6007 (comment)

[civanch]

+1

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next CMSSW_7_3_X IBs unless changes (tests are also fine). This pull request will be automatically merged.

[davidlange6]

Hi Victor
To be consistent with everyone else, make the Run 1 (8 TeV) the default and provide a mechanism to switch to 13 TeV
(eg, add a line in SLHCUpgradeSimulations/Configuration/python/postLS1Customs.py with the needed change(s))

David

On Oct 29, 2014, at 12:19 PM, Viktor Veszpremi notifications@github.com
wrote:

By introducing the new variable theInstLumiScaleFactor, the digitizer
can be adjusted back to the 8 TeV mode by changing its value in the
config file. Obviously, this is suboptimal, but our immediate goal is to
be ready for the 2015 MC production. If the collision energy were known
to the digitizer, the digitizer could select the right PU cross section
already in this version. More sophisticated solutions require more
elaborate and time consuming code development.

On 2014-10-28 12:27, Vladimir Ivantchenko wrote:

@ahazi137 [1] , extra dummy question: does code applicable to 8 TeV
re-digitization? Until now, our default set of parameters was always
for run-1. For run-2 some parameters are changed via customization.

Reply to this email directly or view it on GitHub [2].

Links:

[1] https://github.com/ahazi137
[2] #6007 (comment)
—
Reply to this email directly or view it on GitHub.

[civanch]

Hi Victor,
let us do this in the next PR, because this is is closed already automatically. Introduction of extra lines inside SLHCUpgradeSimulations/Configuration/python/postLS1Customs.py and applying this custom fragment should give identical results with this PR.
Vladimir

[veszpv]

David, Vladimir,

yes, got it. We did not know about this mechanism until now. We will switch back to the Run 1 mode and adjust the custom settings in your py.