CPU integration of G4HepEM using the tracking manager

[JuanGonzalezCaminero]

This PR shows how to use G4HepEM through the TrackingManager instead of the G4 process. However, it can be used only to run on CPU, and will not work with AdePT since one TrackingManager will replace the other.

In order to be able to run G4HepEM with tracking manager on full CPU and CPU + AdePT modes we would need:

• Two separate physics constructors, one registering the G4HepEM tracking manager for full CPU mode, and one registering the G4HepEM process and the AdePT tracking manager
  • However there seems to be a discrepancy in the results from the G4HepEM tracking manager and G4 process
• To implement a hybrid AdePT/G4HepEM tracking manager, removing the need to register the G4HepEM process
  • The current AdePT tracking manager would remain in case the user wants to use something other than G4HepEM on CPU

[phsft-bot]

Can one of the admins verify this patch?

[hahnjo]

However there seems to be a discrepancy in the results from the G4HepEM tracking manager and G4 process

Yes, the tracking manager does not produce bit-identical results. That's because of some optimizations (internal MSC stepping, which can be turned off) and also because we do the navigation directly, with potentially different rounding than G4Transportation.

[JuanGonzalezCaminero]

I see, that's good to know. I have done a run of 32 ttbar events in CMS, the average difference in total edep is around 3%, though the highest was 7%. The speedup from using the tracking manager was 1.09.
Are these numbers what we expect?

[hahnjo]

I see, that's good to know. I have done a run of 32 ttbar events in CMS, the average difference in total edep is around 3%, though the highest was 7%. The speedup from using the tracking manager was 1.09. Are these numbers what we expect?

In principle we don't expect a difference in energy deposit... Are 32 ttbar events enough to get stable numbers for validation? 10% speedup from the tracking manager sounds in line with expectations.