Closed karabowi closed 2 months ago
Could you please add some documentation of the FairMCApplication state machine? At least on the initialization part? After the FairMCApplication is constructed, e.g. which of the various Init*
member functions are supposed to be called in which order to complete a successful initialization? Just for internal code documentation. Thx!
Could you please add some documentation of the FairMCApplication state machine? At least on the initialization part? After the FairMCApplication is constructed, e.g. which of the various
Init*
member functions are supposed to be called in which order to complete a successful initialization? Just for internal code documentation. Thx!
It is too hot to work;).
I wish it was that easy. Lets consider three FairMCApplication
's functions: ConstructGeometry
, InitGeometry
and AddIons
. They are all called internally from TGeant3
or TGeant4
.
FairRunSim
runs the simulation initialization in SetMCConfig()
function, which:
TGeant4
calls ConstructGeometry
in the constructor.FairMCApplication->InitMC()
, which:
fMC->Init()
, TGeant4
calls InitGeometry
here, while TGeant3
calls AddIons
, ConstructGeometry
and InitGeometry
here.fMC->BuildPhysics()
, TGeant4
calls AddIons
hereWhat do you think about such a state order: kPreInit
-> kConstructGeometry
-> kInit
-> kInitGeometry
-> kPostInit
-> kRun
?
I will implement that and lets see.
What do you think about such a state order:
kPreInit
->kConstructGeometry
->kInit
->kInitGeometry
->kPostInit
->kRun
? I will implement that and lets see.
What do you mean by that? Implement what?
@karabowi reopned this
If you wanted to rerun the CI due to the errors:
FairRunSim runs the simulation initialization in SetMCConfig() function, which: …
Can we document exactly this somewhere, please?
Maybe on FairRunSim and/or FairMCApplication?
What do you think about such a state order:
kPreInit
->kConstructGeometry
->kInit
->kInitGeometry
->kPostInit
->kRun
? I will implement that and lets see.What do you mean by that? Implement what?
Now I see the confusion, sry, I was not referring to the fState
member variable. I was just using the term "state machine" loosely to refer to the multi-phase initialization design of the FairMCApplication
class. What I am looking for is some documentation on each of then Init*
-type functions. Basically, what are their pre- and post-conditions.
I now also see that this design is partly coming from VMC and FairRoot attached all kinds of additional state to this class. I give up, nevermind my request for documentation.
FairRunSim runs the simulation initialization in SetMCConfig() function, which: …
Can we document exactly this somewhere, please?
Maybe on FairRunSim and/or FairMCApplication?
Done.
Hi @karabowi,
do you want to remove this? Or keep it for backward compatibility?
Hi @karabowi,
do you want to remove this? Or keep it for backward compatibility?
I have removed this line, or rather moved it to FairMCApplication::InitFinalizer()
.
Introduced new function
FairMCApplication::InitFinalizer()
which initializes event generator, tasks, and triggersFairRootManager::WriteFolder()
function. This new function is called from the latter ofInitGeometry()
andAddIons()
.Previously the funcionality of
InitFinalizer
was split betweenInitGeometry()
andAddIons()
, which caused problems because TGeant3 callsAddIons()
first,InitGeometry()
second, TGeant4 callsInitGeometry()
first,AddIons()
second.Current implementation assures that initialization of event generators and tasks come before
WriteFolder
.Fixes issues #1183 and #1567.
Checklist: