Cannot access conditions in simulations
@gcorti @adavis @kreps @clemenci @sponce @bcouturi @graven @tlatham
Enabling conditions in Gaussino
The purpose of this issue is to find a solution for the new simulation framework (Gaussino & Gauss-on-Gaussino) such that it would be possible to access the dd4hep/detdesc conditions in a uniform way.
TL;DR
I will now quickly point out what are the main problems and then you can find the detailed description below.
Problem 1
Problem 1 description: Detector geometry must be known at the initialize time
Question 1: Is it possible to set up a special algorithm for simulations that would enable access to conditions at the initialize time? Or some kind of workaround?
Problem 2
Problem 2 description: Conditions should be accessible in all tools and services in the main simulation algorithm context
Question 2: How do I make sure that the right functional context is accessible via tools?
Problem 3
Problem 3 description: Fake ODIN and ReserveIOV algorithms missing
Question 3: Does the IOV reservation in simulations even make sense and what ODIN should be set as default?
Detailed description of the problems
Detector geometry must be known at the initialize time
In Gaussino, all the detector simulation is called during the execution of only ONE functional algorithm: GiGaAlg
. When executed it calls a simulate
method from GiGaMT
service. This service constructs the Geant4 world, and initializes the main and worker threads of Geant4 at initialize()
. At finalize()
, the cleanup of the Geant4 objects is performed (including run managers, G4events, etc.). The objects in Geant4 world are constructed with Gaudi tools that act as factories for these objects. Each factory must implement a construct()
method, with which we are able to control when and where the G4 objects should be instantiated and put on the stack.
It is important that we construct and delete G4 objects at the initialize()
and finalize()
time because they have to be called from the same thread (becoming the master thread for Geant4). Geant4 has its own internal checks to verify if a function is called from a worker thread or a master thread. Moreover, some G4 objects have to survive beyond the context of GiGaAlg
, for example, G4Event
s as G4EventProxy
s are used as input in all the algorithms that convert G4Hits to MCHits.
With this interface, we are unable to acquire a condition via get()
as this must be done at the execution time. We cannot move the construction to the execution time because of the problem mentioned above, and we do not want have multiple G4 geometries constructed on each Gaudi thread.
My 1st question is then: Is it possible to set up a special algorithm for simulations that would enable access to conditions at the initialize time? Or some kind of workaround?
Conditions should be accessible in all tools and services in the main simulation algorithm context
Since we use tools and services to construct G4 objects and perform the simulation, we have to make sure that the right context is visible when using ConditionAccessorHolder
. I will use DeMagnet
as an example. The proposed interface is presented in lhcb/Gauss!879 (closed). The factory for G4MagnticField
would look like this:
class MagFieldFromMagnetFAC
: public extends<LHCb::DetDesc::ConditionAccessorHolder<GiGaTool>, GiGaFactoryBase<G4MagneticField>> {
LHCb::DetDesc::ConditionAccessor<DeMagnet> m_magnet{this, "DeMagnet", LHCb::Det::Magnet::det_path};
public:
using extends::extends;
MagFieldFromMagnet* construct() const override {
auto g4mag = new MagFieldFromMagnet{};
auto magnet = m_magnet.get();
// some code
return g4mag;
}
};
In this case, we have the following interplay between Gaudi objects:
GiGaAlg
(algorithm) -> GiGaMT
(service) -> GiGaMTDetectorConstructionFAC
(tool)-> GaussGeo
/DD4hepCnvSvc
(DetDesc/DD4hep service) -> ToolFieldMgr
(tool) -> MagFieldFromMagnet
(tool, accesses DeMagnet)
My 2nd question is then: How do I make sure that the right functional context is accessible via tools in a dependency like this above?
Fake ODIN and ReserveIOV algorithms missing
Some conditions (like DeMagnet
) require ReserveIOV
algorithms (different one for detdesc and dd4hep). This can be easily added, but should it really be a requirement for the simulation software? If yes, then the ReserveIOV
has to have an ODIN provided. I guess via FakeEventTime
algorithm. What would be the default ODIN that the simulation software should use?
Thanks for getting through all that text. I hope my investigation is enough to open a discussion on this topic.