Simplify caching of CLHEP::HepRandomEngine in digitizers #22874
Conversation
|
The code-checks are being triggered in jenkins. |
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-22874/4258 |
|
A new Pull Request was created by @makortel (Matti Kortelainen) for master. It involves the following packages: SimCalorimetry/CastorSim @cmsbuild, @civanch, @kpedro88, @mdhildreth can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
|
@cmsbuild, please test |
|
The tests are being triggered in jenkins. |
|
@makortel , @Dr15Jones ,as I understand the logic of random numbers, in SIM step both for FullSim and FastSim the RandomNumberService is caled once per event to define random number generator for given event (Inside current thread). In FastSim this generator is distributed a a parameter of all methods to all called sub-classes. In the case of FullSim/Geant4 the random engine is set per event to as a CLHEP engine in the given thread. These both variants are transparent and seems to be correct from the design point of view : method of definition of the generator is fully disconnected with FullSim and FastSim. The ovehead of access to the service per event is minimal. At the DIGI/Mixing steps there is a sequence of producers, in each we need to access the service. There may be more overhead, however, to me having engine definded per event is indeed more safe than keeping one engine stored after the first call. I afread that the method proposed by Matti may provide completely non-reproducible code, because event sequence in a thread is not reproducible. |
|
@civanch Technically the current "StreamID-indexed vector" caching, and the caching done in this PR, are safe, and produce exactly the same results. (motivation for this PR being clearer code so that one does not have to wonder why there is a vector) Would your preference be then to set the cache in each call to |
|
@makortel , I would think a good idea about initializeEvent() and I would do nothing in finelizeEvent(). |
|
please test |
|
The tests are being triggered in jenkins. |
|
Comparison job queued. |
|
Pull request #22874 was updated. @cmsbuild, @civanch, @kpedro88, @mdhildreth can you please check and sign again. |
|
Rebased on top of CMSSW_10_2_X_2018-04-10-2300 and simplified the caching further along #22874 (comment). @civanch I dediced in the end to set the cache variable back to |
|
@cmsbuild, please test with workflow 250202.0,250202.17,250202.18,250402.0 Let's include premixing workflows as well to demonstrate that they continue to work (as some parts of digitizer code is called from premixing) |
makortel
changed the title
|
@cmsbuild, please test workflow 250202.0,250202.17,250202.18,250402.0 Maybe some day I'll remember the syntax on the top of my head... |
|
The tests are being triggered in jenkins. |
|
Comparison job queued. |
|
Comparison is ready @slava77 comparisons for the following workflows were not done due to missing matrix map:
Comparison Summary:
|
|
+1 |
|
+1 |
cmsbuild
added
fully-signed
upgrade-approved
and removed
pending-signatures
upgrade-pending
labels
|
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 now be reviewed by the release team before it's merged. @davidlange6, @slava77, @smuzaffar, @fabiocos (and backports should be raised in the release meeting by the corresponding L2) |
|
+1 |
The explicit stream-based caching was introduced in #2392 at the time the the MixingModule was still a "one" module. Now that the MixingModule is a stream producer, there is no need to do the caching explicitly (=vectors indexed by the stream ID). A simple member variable is enough, and it is safe because framework runs always the same instance of a stream module in a given stream.
The caching is further simplified to always set the cache variable in
initializeEvent()and set it back tonullptrinfinalizeEvent()(to prevent the use of the engine outside event, e.g. begin/end lumi/run).Resolves #22712.
Tested in CMSSW_10_1_0 (rebased on top of CMSSW_10_2_X_2018-04-10-2300), no changes expected.
@wddgit @Dr15Jones