Allow to invoke random seed propagations to Geant4

[sawenzel]

So far, we can only propagate or pick up the seed from gRandom to Geant4 (CLHEP) during initialization.

This commit makes minimal changes that allows an expert user to call TG4RunManager::SetRandomSeed() at any moment, thereby gaining better control over the random state of the Geant4 engine.

Motivation:

In the multi-process + sub-event parallel framework of ALICE, we are in the need of an interface that allows us to set the random state during simulation runs, in order to ensure total reproducibility of our simulations with Geant4 when starting from the same initial seed. For Geant3, this was already working but reproducibility was so far lacking for Geant4.

The present change (or similar) is also need for the even higher goal of "track seeding", which gives reproducible simulations on the track level even when cuts or geometry change in some parts of the detector.

[sawenzel]

Additional comment: This works for me but we can also evolve this in a more official way. Maybe it makes sense to promote this directly to the VMC level and offer a new API virtual void TVirtualMC::setSeed(...).

[ihrivnac]

Hi @sawenzel ,

Have you try to compile with your changes? On my side, compilation fails, as you add in dictionaries a class with dependencies on Geant4.

If I remove changes in Cmake and LinkDef file, to code compiles fine, but this means that the setting would not be available from Root session.

Better slotution would be what you propose in you comment above and interface this setting via TVirtualMC.

Best regards,

[sawenzel]

It compiles totally fine for me (alibuild) and the PR achieves my goal together with https://github.com/AliceO2Group/AliceO2/pull/11500. I am not sure why it does not compile for you.

[ihrivnac]

It compiles totally fine for me (alibuild) and the PR achieves my goal together with AliceO2Group/AliceO2#11500. I am not sure why it does not compile for you.

I am building directly via cmake && make, without aliBuild. I attach the log produced with VERBOSE=1. below. As we do not pass G4 includes to ROOT dictionary generation I found this failure normal. I will try it out with aliBuild to see what gets different here.

  5%] Generating geant4vmc_dict.cxx, libgeant4vmc_rdict.pcm, libgeant4vmc.rootmap
cd /Users/ivana/work/projects/vmc/dev/geant4_vmc_build/source && /opt/homebrew/Cellar/cmake/3.25.2/bin/cmake -E env DYLD_LIBRARY_PATH=/Users/ivana/work/packages/root/root_v6.28.04/lib: /Users/ivana/work/projects/vmc/dev/root/bin/rootcling -v2 -f geant4vmc_dict.cxx -s /Users/ivana/work/projects/vmc/dev/geant4_vmc_build/source/libgeant4vmc.dylib -rml libgeant4vmc.dylib -rmf /Users/ivana/work/projects/vmc/dev/geant4_vmc_build/source/libgeant4vmc.rootmap -I/Users/ivana/work/projects/vmc/dev/geant4_vmc_install/include/geant4vmc -excludePath /Users/ivana/work/projects/vmc/dev/geant4_vmc_build/source -excludePath /Users/ivana/work/projects/vmc/dev/geant4_vmc/source -DUSE_G3TOG4 -DUSE_G4ROOT -DUSE_VGM -compilerI/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1 -compilerI/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/14.0.0/include -compilerI/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include -compilerI/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include -compilerI/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/14.0.0/include -compilerI/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include -compilerI/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include -I/Users/ivana/work/packages/root/root_v6.28.04/include -I/Users/ivana/work/projects/vmc/dev/vmc_install/include/vmc -I/Users/ivana/work/projects/vmc/dev/geant4_vmc/source/../g4root/include -I/Users/ivana/work/projects/vmc/dev/vgm_install/include -I/Users/ivana/work/projects/vmc/dev/geant4_vmc/source/biasing/include -I/Users/ivana/work/projects/vmc/dev/geant4_vmc/source/global/include -I/Users/ivana/work/projects/vmc/dev/geant4_vmc/source/geometry/include -I/Users/ivana/work/projects/vmc/dev/geant4_vmc/source/digits+hits/include -I/Users/ivana/work/projects/vmc/dev/geant4_vmc/source/physics/include -I/Users/ivana/work/projects/vmc/dev/geant4_vmc/source/physics_list/include -I/Users/ivana/work/projects/vmc/dev/geant4_vmc/source/physics_monopole/include -I/Users/ivana/work/projects/vmc/dev/geant4_vmc/source/event/include -I/Users/ivana/work/projects/vmc/dev/geant4_vmc/source/run/include -I/Users/ivana/work/projects/vmc/dev/geant4_vmc/source/visualization/include -I/Users/ivana/work/projects/vmc/dev/geant4_vmc_build/source -I/Users/ivana/work/projects/vmc/dev/geant4_vmc/source TG4RunConfiguration.h TGeant4.h TG4RunManager.h /Users/ivana/work/projects/vmc/dev/geant4_vmc/source/geant4vmcLinkDef.h
In file included from input_line_9:14:
In file included from /Users/ivana/work/projects/vmc/dev/geant4_vmc/source/run/include/TG4RunManager.h:18:
/Users/ivana/work/projects/vmc/dev/geant4_vmc/source/run/include/TG4RunMessenger.h:18:10: fatal error: 'G4UImessenger.hh' file not found
#include <G4UImessenger.hh>
         ^~~~~~~~~~~~~~~~~~
Error: /Users/ivana/work/projects/vmc/dev/root/bin/rootcling: compilation failure (/Users/ivana/work/projects/vmc/dev/geant4_vmc_build/source/libgeant4vmce0f793b294_dictUmbrella.h)
make[2]: *** [source/geant4vmc_dict.cxx] Error 1
make[1]: *** [source/CMakeFiles/geant4vmc.dir/all] Error 2
make: *** [all] Error 2

[ihrivnac]

The PR compiles ok with geant4_vmc v6-1-patches & Geant4 11.0.px, which is used in O2, both in my standalone build and in O2 framework, but fails with geant4_vmc master & Geant4 11.1.p1. Both versions compiled with the last ROOT (6.28/04).

In the older version, Geant4 includes are somehow passed to the Root dictionary generation, not by us, while in new version they are not, what is however wanted, as we generate dictionaries only for two classes, and both these classes do not have any includes from Geant4 in their headers.

I will need more time to investigate why we get different behaviour in the v6-1-patches version.

[sawenzel]

I have reworked the PR, now not needing TG4RunManager in dictionary creation anymore (at the cost of an additional interface SetRandomSeed() in TGeant4.) I think this should work ok ... until we have a more proper way with real VMC interfaces.

[ihrivnac]

I have reworked the PR, now not needing TG4RunManager in dictionary creation anymore (at the cost of an additional interface SetRandomSeed() in TGeant4.) I think this should work ok ... until we have a more proper way with real VMC interfaces.

This is what I was just going to propose as for TGeant4 we already create a dictionary.

Could you also remove static function declaration and change the implementation in TGeant4.cxx to:

fRunManager->SetRandomSeed();

As with this change the function will be now callable during event processing (which was not the case before), we need also to protect the setTheSeeds() call with a lock for MT mode. But I will check this.

[sawenzel]

Ok. I did all the changes (apart from the locking ... but for us this is not relevant).

[ihrivnac]

Thank you; I checked in meantime that the lock is not needed. I suppose that we need to propagate this update in the v6-1-x version (based on Geant4 11.0.x), right?

[sawenzel]

Thank you! Yes, a new tag in the v6-1 series would be perfect.

[ihrivnac]

The tag v6-1-p6 is now available.