Simple digitizer for fast timing

[lgray]

This PR implements a simple digitizer for fast timing, including accumulation for pileup.

Right now the digitizer is very simple:

• no electronics noise or shaping (yet)
• Digitizes in values of MIPs
• applies a time-of-arrival stamp based on interpolating sim-hit energies

To leave some flexibility for the future I am using some template classes to house the functionality of the sensor and electronics simulations. This will evolve over time.

@slava77 I have updated the limited matrix to run D5 instead of D3Timing to exercise the timing code. The additions are the LYSO and silicon layers, and this digitizer, otherwise the same code is run.

Here are some occupancy plots of the timing digis in 200PU:
barrel occupancy with no energy cut:

barrel occupancy with 0.5 MIP energy cut:

endcap occupancy with no energy cut:

endcap occupancy with 0.5 MIP energy cut:

(since the endcap is silicon it is blind to low energy photons that the LYSO layer is sensitive to in the barrel)

barrel energy distribution in MIPs:

barrel energy distribution in MIPs ( < 10 MIPs to focus on low the low energy peak ):

endcap energy distribution in MIPs:

endcap energy distribution in MIPs ( < 10 MIPs, MIP peak clearly visible ):

[lgray]

@cmsbuild please test

[cmsbuild]

The tests are being triggered in jenkins.
https://cmssdt.cern.ch/jenkins/job/ib-any-integration/16058/console

[cmsbuild]

A new Pull Request was created by @lgray (Lindsey Gray) for CMSSW_8_1_X.

It involves the following packages:

Configuration/PyReleaseValidation
DataFormats/FTLDigi
SimFastTiming/Configuration
SimFastTiming/CrystalSiPMFastTimingDigitizer
SimFastTiming/FastTimingCommon
SimFastTiming/SiliconFastTimingDigitizer
SimGeneral/Configuration
SimGeneral/MixingModule

The following packages do not have a category, yet:

DataFormats/FTLDigi
SimFastTiming/Configuration
SimFastTiming/CrystalSiPMFastTimingDigitizer
SimFastTiming/FastTimingCommon
SimFastTiming/SiliconFastTimingDigitizer
Please create a PR for https://github.com/cms-sw/cms-bot/blob/master/categories.py to assign category

@civanch, @mdhildreth, @fabozzi, @cmsbuild, @srimanob, @hengne, @davidlange6 can you please review it and eventually sign? Thanks.
@makortel, @Martin-Grunewald, @ghellwig, @wmtan this is something you requested to watch as well.
@slava77, @smuzaffar you are the release manager for this.

cms-bot commands are listed here #13028

[lgray]

@davidlange6 Are these package names OK? Would you prefer something else? I think it is well justified to make a new package given that the readout mechanisms and sensors themselves are a bit different from either calorimetry or tracking. Despite the simplistic nature of the digitizer right now I think it would be premature to gobble this up in another package.

[lgray]

Also, @slava77, it might be interesting for you to check this one as well since the workflow for ttbar + Timing is being changed to include an updated material budget in front of ECAL and HGCal. It may be useful to see if there are an leading order effects on ECAL or HGCal cluster variable distributions.

[cmsbuild]

Pull request #16387 was updated. @civanch, @mdhildreth, @fabozzi, @cmsbuild, @srimanob, @hengne, @davidlange6 can you please check and sign again.

[cmsbuild]

Pull request #16387 was updated. @civanch, @mdhildreth, @fabozzi, @cmsbuild, @srimanob, @hengne, @davidlange6 can you please check and sign again.

[lgray]

@cmsbuild please test

[cmsbuild]

The tests are being triggered in jenkins.
https://cmssdt.cern.ch/jenkins/job/ib-any-integration/16113/console

[cmsbuild]

+1
Tested at: 7516459
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-16387/16113/summary.html

[cmsbuild]

Comparison job queued.

[cmsbuild]

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

[lgray]

@civanch @hengne @srimanob @fabozzi Could you please review and sign? Thanks!

[civanch]

@lgray , for me names of the packages are confusing because "Fast" inside may indicate that it is FastSim, however, changing names now at the border of 8_1 seems not optimal.

Addition to Biglib probably should be done separately, when this PR is merged.

[civanch]

+1

[lgray]

@hengne @fabozzi please sign

[slava77]

looking at pre16, I see that D3Timing is not working anymore.
Is it this PR that broke it or was it something else?

   [1] Running path 'digitisation_step'
   [2] Calling beginRun for module MixingModule/'mix'
Exception Message:
No data of type "FastTimeDDDConstants" with label "" in record "IdealGeometryRecord"

[lgray]

Ah, crap, I forgot about that event setup product. And tested D5...

I'll submit a fix. But tomorrow.

-L

On Nov 4, 2016 6:59 PM, "Slava Krutelyov" notifications@github.com wrote:

looking at pre16, I see that D3Timing is not working anymore.
Is it this PR that broke it or was it something else?

[1] Running path 'digitisation_step'
[2] Calling beginRun for module MixingModule/'mix'
Exception Message:
No data of type "FastTimeDDDConstants" with label "" in record "IdealGeometryRecord"

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#16387 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABBMOcigCPKN-07lq_ig0_XwCwhlDVxYks5q6-MMgaJpZM4KkJ6m
.

[slava77]

for now, in D3Timing del process.mix.digitizers.fastTimingLayer apparently does the job

[lgray]

yeah - I need to split the timing era into timing and fast_time_layer to
make it so that D*Timing and D5 all run happily together.

-L

On Fri, Nov 4, 2016 at 7:40 PM, Slava Krutelyov notifications@github.com
wrote:

for now, in D3Timing del process.mix.digitizers.fastTimingLayer
apparently does the job

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#16387 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABBMOfx5cpQcKwtLwu9BGT6rbTO2pTyFks5q6-yrgaJpZM4KkJ6m
.