-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(sim): Allow branch registration in FairGenerator
#1575
feat(sim): Allow branch registration in FairGenerator
#1575
Conversation
WalkthroughWalkthroughThe changes enhance the initialization workflow of the Changes
Possibly related PRs
Recent review detailsConfiguration used: CodeRabbit UI Files selected for processing (7)
Files not reviewed due to no reviewable changes (1)
Files skipped from review as they are similar to previous changes (6)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
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 |
It is too hot to work;). I wish it was that easy. Lets consider three
What do you think about such a state order: |
What do you mean by that? Implement what? |
If you wanted to rerun the CI due to the errors:
|
Can we document exactly this somewhere, please? Maybe on FairRunSim and/or FairMCApplication? |
Now I see the confusion, sry, I was not referring to the 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. |
24e4c0b
to
3174050
Compare
Done. |
07d4b38
to
8023a59
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally, I like the way this is going!
So maybe we should merge it as a "step in the right direction"?
That said, I don't know, whether some things should be squashed?
8023a59
to
b4a2bfc
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, you're right! There's no need for squashing! Things look good from that point of view.
While looking again at the individual commits, I noticed another small thing.
b4a2bfc
to
3fb53f0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please improve naming. :-)
134646f
to
d84e17f
Compare
Hi @karabowi, FairRoot/fairroot/base/sink/FairRootFileSink.cxx Lines 249 to 250 in 6decd1e
do you want to remove this? Or keep it for backward compatibility? |
Introduced new function `FairMCApplication::InitFinalizer()` which initializes event generator, tasks, and triggers `FairRootManager::WriteFolder()` function. This new function is called from `InitMC()` and from `InitOnWorker()` for TGeant4 MT mode. Previously the funcionality of `InitFinalizer` was split between `InitGeometry()` and `AddIons()`, which caused problems because TGeant3 calls `AddIons()` first, `InitGeometry()` second, TGeant4 calls `InitGeometry()` first, `AddIons()` second. Current implementation assures that initialization of event generators and tasks come before `WriteFolder`. Fixes issues FairRootGroup#1183 and FairRootGroup#1567.
Rutherford example does not need to run in MT mode, since we have dedicated MT test anyways. Changed the test not to run in MT mode.
Comments explain `SetMCConfig()` functionality.
Added few states as well as few checks. Previous state order: `kUnknownState` -> `kConstructGeometry` -> `kUnknownState` -> `kInitGeometry` -> `kUnknownState` Currently: `kPreInit` -> `kConstructGeometry` -> `kInit` -> `kInitGeometry` -> `kInit` -> `kPostInit` -> `kRun`.
The function `WriteFolder` (since the introduction of the `MTMode`) was misused to remove the `TFolder` from `gROOT` after it was used to create the output tree. Purely for that reason `WriteFolder` was called in the `InitGeometry()`. This folder is no longer removed in the sink's `WriteFolder()`. Introduced a new `FairRootManager::RemoveOutputFolderForMtMode()` function which removes the `TFolder` from `gROOT`, which is needed in the MT mode in TGeant4 transport. Used this function in `FairMCApplicaiton::InitGeometry()` and in `FairMCApplication::InitFinalizer()`.
d84e17f
to
63b6d7f
Compare
I have removed this line, or rather moved it to |
Introduced new function
FairMCApplication::InitFinalizer()
which initializes event generator, tasks, and triggersFairRootManager::WriteFolder()
function.This new function is called from the latter of
InitGeometry()
andAddIons()
.Previously the funcionality of
InitFinalizer
was split betweenInitGeometry()
andAddIons()
, which caused problems becauseTGeant3 calls
AddIons()
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: