Complete Geant4 MT integration #4505
Conversation
|
Argh, just noticed that I forgot to squash a couple of commit, I'll reopen when done. |
Suggested by @Dr15Jones, makes the stopG4()+join() time more deterministic.
Feels dirty, but by far the easiest solution given everything was static already.
…e() to take const SensitiveDetectorCatalog Percolate the change through SensitiveDetector class hierarchy. Needed to integrate Geant4MT to our framework.
The interface of G4UIsession has been changed slightly (or this has never worked...), now ReceiveG4cout/cerr are properly overridden.
RunManagerMTInit::readES() has checks if geometry or magnetic field change, and the checks make little sense if RunManagerMTInit's lifetime is Run and not the whole program.
Helgrind reports got me read Geant4 code more carefully, and I noticed that from worker threads one should set the geometry WorkerDefineWorldVolume(). However, since we don't employ G4(MT)RunManager, we have to call G4TransportationManager::SetWorldForTracking() by ourselves. WorkerDefineWorldVolume() seems to avoid writing to the (global) world volume object, something that DefineWorldVolume() does. Fixes some Helgrind warnings
Towards supporting multiple runs in a job.
Needed to support multiple runs in a job
… and stopThread() Needed to support multiple runs in a job
…ng transitions from globalBeginRun/globalEndRun/globalEndJob
Mimicking the behaviour of RunManager::initG4().
|
A new Pull Request was created by @makortel (Matti Kortelainen) for CMSSW_7_2_X. Complete Geant4 MT integration It involves the following packages: Alignment/LaserAlignmentSimulation @civanch, @diguida, @mdhildreth, @cmsbuild, @nclopezo, @rcastello, @Degano can you please review it and eventually sign? Thanks. |
|
Pull request #4505 was updated. @civanch, @diguida, @mdhildreth, @cmsbuild, @nclopezo, @rcastello, @Degano can you please check and sign again. |
|
+1 |
|
+1 |
|
This pull request is fully signed and it will be integrated in one of the next CMSSW_7_2_X IBs unless changes (tests are also fine). |
This PR completes (almost, see below for a known issue) the integration of Geant4 MT into multithreaded CMSSW. Most modifications are again in MT-specific classes, but some classes used by the serial OscarProducer were also modified.
Changes affecting OscarProducer (results should stay the same)
#define G4Random CLHEP::HepRandom, so should be okChanges in OscarMTProducer
I have tested with 100 MinBias events (wf 1.0) (in CMSSW_7_2_GEANT10_X_2014-07-01-0200+#4457+#4476)
In addition I've tested with 200 TTBar events (wf 1302.0) that OscarMTProducer works technically at least up to 20 threads.
To ease testing with cmsDriver.py/runTheMatrix.py, I've included a customise-script to change all OscarProducers in a Process to OscarMTProducers.
Following the Geant4 threading model, there are quite a lot of new thread_local statics (especially in RunManagerMTWorker, but also elsewhere). At least the RunManagerMTWorker ones could probably be cleaned up with the "usual tricks" in the future.