Update OscarMTProducer initialisation

[civanch]

PR description:

Initialisation of Geant4 in OscarMTProducer is moved to the beginRun(....) method.
Header files of producers are moved to plugins directory.

PR validation:

private

if this PR is a backport please specify the original PR and why you need to backport that PR:

no backport

[cmsbuild]

The code-checks are being triggered in jenkins.

[civanch]

+core

[cmsbuild]

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-31022/17503

• This PR adds an extra 24KB to repository

[cmsbuild]

A new Pull Request was created by @civanch (Vladimir Ivantchenko) for master.

It involves the following packages:

SimG4Core/Application

@cmsbuild, @civanch, @mdhildreth can you please review it and eventually sign? Thanks.
@makortel, @rovere, @fabiocos, @slomeo this is something you requested to watch as well.
@silviodonato, @dpiparo, @qliphy you are the release manager for this.

cms-bot commands are listed here

[civanch]

please test

[civanch]

+Core

[cmsbuild]

The tests are being triggered in jenkins.

• CMSSW_11_2_X_2020-08-02-0000/slc7_amd64_gcc820: https://cmssdt.cern.ch/jenkins/job/ib-run-pr-tests/8498/console Started: 2020/08/02 19:49

[civanch]

@makortel or @Dr15Jones , please, check that the move of Geant4 initialisation from produce(...) to beginRun(...) is done in an optimal way.

[cmsbuild]

+1
Tested at: 644623d
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-6e32d8/8498/summary.html
CMSSW: CMSSW_11_2_X_2020-08-02-0000
SCRAM_ARCH: slc7_amd64_gcc820

[cmsbuild]

Comparison job queued.

[cmsbuild]

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

Comparison Summary:

• No significant changes to the logs found
• Reco comparison results: 0 differences found in the comparisons
• DQMHistoTests: Total files compared: 34
• DQMHistoTests: Total histograms compared: 2525448
• DQMHistoTests: Total failures: 1
• DQMHistoTests: Total nulls: 0
• DQMHistoTests: Total successes: 2525400
• DQMHistoTests: Total skipped: 47
• DQMHistoTests: Total Missing objects: 0
• DQMHistoSizes: Histogram memory added: 0.0 KiB( 33 files compared)
• Checked 144 log files, 17 edm output root files, 34 DQM output files

[civanch]

+1

[cmsbuild]

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. @silviodonato, @dpiparo, @qliphy (and backports should be raised in the release meeting by the corresponding L2)

[silviodonato]

+1

[makortel]

Call to initializeG4() in produce() should not be an indication of a problem. The framework does not guarantee that all TBB worker threads would call the beginRun(). Therefore it is expected that for some threads the produce() is the first function in OscarMTProducer they call (which is why the code was crafted that way).

[civanch]

@makortel , thanks for explanation. In the next PR I will substitute Warning by Verbatim. One of the reason to move initialisation at beginRun(..) is to take out initialisation from the event loop, so this will not affect CPU measurements. For the case, when streams do not coincide with threads we will still have initialisation at the 1st event.

[makortel]

Technically this PR should not cause problems, but the behavior is now a little bit more confusing to understand, because some threads initializeG4() through beginRun() and some through produce().