Parallel BDSIM

[Jochem Snuverink]

look into options to parallelise BDSIM.

Event-level parallelism has been achieved already in Geant4: http://geant4.web.cern.ch/geant4/G4UsersDocuments/UsersGuides/ForApplicationDeveloper/html/Examples/parallel.html

[Laurie Nevay]

There is a porting guide here:

https://twiki.cern.ch/twiki/bin/view/Geant4/QuickMigrationGuideForGeant4V10

The main change has to be implementing the ConstructSDAndField virtual function implementation in our detector construction class.

Sensitive detectors and fields must be thread local. For us, we must therefore keep a registry or exactly which sd is attached to which volume so the attachment can be performed in ConstructSDAndField. Also, the SDManager would have to not be a singleton and constructed per event. This overall, isn't too bad.

Much, much worse is the requirement that any field objects are thread local. This means we must construct fresh copies of all field related objects at the start of the event and attach them. Normally for a detector there are one or two field maps or maybe a much simpler field (not sure how they propose to access large field map in memory in each thread), but for us, we have as many fields as we have accelerator components and the complexity of fields rivals that of the geometry. Upcoming changes in fieldmaps branch will allow factories to construct the field object according to a field info class instance so this will now be possible with a small amount of extra registration like the sensitive detectors.

I'm not sure if this will be memory or time efficient though in the simulation given the complexity of our models. Perhaps for small models this will win out.

We currently don't support multithreading and the build system prevents compilation against multithreaded Geant4.

With hyperthreading, one can have more events running than physical cores available, so memory becomes the limiting factor.

On hold for now until fields maps is finished and the possibility exists.

[Laurie Nevay]

Another note:

Apparently, read out geometry is being deprecated in favour or parallel worlds and in fact as of v4.10.0 multithreaded mode is incompatable with the read out geometry method. The same outcome can be achieved with another parallel world.

We use a read out geometry for curvilinear coordinates just now so this would have to be revised if we were to move to multithreaded compatibility.

[Laurie Nevay]

Issue #93 was marked as a duplicate of this issue.

[Laurie Nevay]

Comment from other issue that belongs here:

"when Geant4 is compiled with multithreading, the GUI viewer does not come up."

[Laurie Nevay]

A simple way to achieve some degree of parallelisation would be to write a simple wrapper for BDSIM that would spawn complete instances of BDSIM as threads.

Required: * BDSIM as a class (already planned) * wrapper program * evaluate use of singletons (information passing / threadsafety)

Issues: * This wouldn't save memory, but we currently don't use excessive memory on a single model * Possibly merging output at the end

[Laurie Nevay]

Dusting this off. Default in Geant4 v11 is now to build with multithreading on. Macs now do really well with multithreading with 10 core (so 15-20 threads) being more common. Even the M1 mac has 8 cores (4 low performance).