Migrate Sim Code to New Random Service Interface

[wddgit]

Migrate most simulation code to use the new interface
of the random number generator service designed to work
with the multithreaded Framework. The main interface
change is to require a StreamID or LuminosityBlockIndex
argument to the getEngine function. In most cases,
this required moving code from the constructor to
the event or beginLuminosityBlock method. Then a pointer
to the engine was percolated or passed in some way
to the point where it was used.

Note OscarProducer was migrated earlier and there are a
few pieces of code I skipped over that will be migrated
in the near future. This pull request takes care of most
of the digitizers and the mixing modules.

[cmsbuild]

A new Pull Request was created by @wddgit (W. David Dagenhart) for CMSSW_7_1_X.

Migrate Sim Code to New Random Service Interface

It involves the following packages:

FWCore/Sources
FastSimulation/Tracking
IOPool/Input
IOPool/SecondaryInput
Mixing/Base
SimCalorimetry/CaloSimAlgos
SimCalorimetry/CastorSim
SimCalorimetry/EcalSimAlgos
SimCalorimetry/EcalSimProducers
SimCalorimetry/HcalSimAlgos
SimCalorimetry/HcalSimProducers
SimCalorimetry/HcalTestBeam
SimG4CMS/EcalTestBeam
SimGeneral/DataMixingModule
SimGeneral/MixingModule
SimGeneral/NoiseGenerators
SimGeneral/TrackingAnalysis
SimMuon/CSCDigitizer
SimMuon/DTDigitizer
SimMuon/GEMDigitizer
SimMuon/Neutron
SimMuon/RPCDigitizer
SimTracker/Common
SimTracker/SiPixelDigitizer
SimTracker/SiStripDigitizer
Validation/EcalDigis

@civanch, @ojeda, @deguio, @lveldere, @danduggan, @mdhildreth, @cmsbuild, @Dr15Jones, @rovere, @giamman, @Degano, @ktf, @nclopezo can you please review it and eventually sign? Thanks.
@cerati, @GiacomoSguazzoni, @rovere, @wmtan 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.
@nclopezo, @ktf you are the release manager for this.
You can merge this pull request by typing 'merge' in the first line of your comment.

[cmsbuild]

+1
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-2392/112/summary.html

[Dr15Jones]

+1

[lveldere]

+1

[civanch]

+1

[ktf]

@deguio @ojeda can you please look into this?

[davidlange6]

nothing to do with the changes in this pull request - but why redo(or do differently? the ecal digitization in the validation module? I would have expected that we should validate what is done in the digi part as to be validating what is then stored for reco/analysis

[wddgit]

The only reason I included Validation/EcalDigis/src/EcalMixingModuleValidation changes in this pull request was that it uses the CaloHitResponse class that is also used by the digitization code. I had to modify the CaloHitResponse interface. That one class is the only DQM code changed in this pull request. That does not answer David Lange's valid question, but I do not think that question should delay signature of this pull request.

[deguio]

+1

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next CMSSW_7_1_X IBs unless changes (tests are also fine). @nclopezo, @ktf can you please take care of it?

[davidlange6]

except we won't get an answer to the question if we accept and forget…

On Feb 12, 2014, at 5:33 PM, W. David Dagenhart notifications@github.com wrote:

The only reason I included Validation/EcalDigis/src/EcalMixingModuleValidation changes in this pull request was that it uses the CaloHitResponse class that is also used by the digitization code. I had to modify the CaloHitResponse interface. That one class is the only DQM code changed in this pull request. That does not answer David Lange's valid question, but I do not think that question should delay signature of this pull request.

—
Reply to this email directly or view it on GitHub.

[Dr15Jones]

@davidlange6 How about we open a Jira ticket?

[ktf]

Is anyone tracking the issue?

[civanch]

I would say that keeping this PR not merged is also a problem - too many sub-packages are affected. I believe it is possible open new unscheduled PR with the issue described - for me it would be equivalent to a Jira ticket.