search

OpenGATE / opengate

Gate 10 (beta)
http://www.opengatecollaboration.org
GNU Lesser General Public License v3.0
42 stars 38 forks source link

Refactor actors #363

Closed nkrah closed 3 months ago

nkrah commented 5 months ago

This PR completely refactors the actors and its handling. It switches them from the current mechanism of using the UserInfo class and the builder mechnism to inheriting from GateObject, as volumes and physics classes already do.

The PR also implements a unified way of handling actor output.

Important: This is work in progress and intermediate stages of this PR will NOT work.

dsarrut commented 5 months ago

great ! I just cancel the workflow to save comp time (and allow other PR to be tested)

nkrah commented 5 months ago

Thanks. Forgot to cancel that.

​

​I decided to also refactor the actor output mechanism within this PR, contrary to what I told you the other day. Doing that in a separate PR would double the work. I'll post some explanation as I move on.

On Mar 1 2024, at 11:49 am, David Sarrut @.***> wrote:

great ! I just cancel the workflow to save comp time (and allow other PR to be tested)

—

Reply to this email directly, view it on GitHub (https://github.com/OpenGATE/opengate/pull/363#issuecomment-1972961429), or unsubscribe (https://github.com/notifications/unsubscribe-auth/AIFQFYLITYBYRS3PCYV5KSTYWBMKNAVCNFSM6AAAAABEBOF4ZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZSHE3DCNBSHE).

You are receiving this because you authored the thread.

nkrah commented 5 months ago

Some thoughts concerning the dose actor:

​I think I would like to split the functionality into a more generic VoxelDepositActor and specfic Scorers. (not necessarily as part of the refactoring). The point is that the different variants of the DoseActor (LET, Fluence, etc.) actually share a lot of code and really only differ in the quantities they compute in StepppingAction. Roughly speaking: The VoxelDepositActor would handle the general stuff and hold a list of Scorers which all implement common methods to be called in SteppingAction. In this way, the code becomes more modular and avoids redundance. We can discuss that in more detail if you want.

On Mar 1 2024, at 12:58 pm, Nils Krah @.***> wrote:

Thanks. Forgot to cancel that.

​

​I decided to also refactor the actor output mechanism within this PR, contrary to what I told you the other day. Doing that in a separate PR would double the work. I'll post some explanation as I move on.

On Mar 1 2024, at 11:49 am, David Sarrut @.***> wrote:

great ! I just cancel the workflow to save comp time (and allow other PR to be tested)

—

Reply to this email directly, view it on GitHub (https://github.com/OpenGATE/opengate/pull/363#issuecomment-1972961429), or unsubscribe (https://github.com/notifications/unsubscribe-auth/AIFQFYLITYBYRS3PCYV5KSTYWBMKNAVCNFSM6AAAAABEBOF4ZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZSHE3DCNBSHE).

You are receiving this because you authored the thread.

nkrah commented 4 months ago

Main change up to this point: I started implementing the post processor sub package to replace most of the digitizers.

Idea in short: 1) Most digitizers take per-event data as input, i.e. the output if an Adder. With per-event data, there is no imminent need to let the digitizers run as part of the Geant4 event loop, e.g. let them iterate via EventAction. It is actually much more flexible to do the post-processing after the simulation, potentially multiple times. 2) Many digitizers do not perform conplicated operations, but the codebase is complex due to the way root files are handled. 3) There are better file formats than root to store (big) structured data. HDF5 is a good option because it is intrinsically compatible with numpy and easy to use with other libraries, including AI libs. 4) Digitizer/post processor output should be stored in a reproducible structured way, ideally containing all relevant meta info. 5) The postprocessing sub package provides a relatively easy internal interface so developers can contribute their own post processing units.

A post processor works like a chain of filters in ITK: it consists of a hierarchically organized set of processing units which yield their output to the subsequent one. Each processor stores its output in a single HDF5 file where each unit has its own group. Units can store their output in that file/group or in an external file and place a link into the group.

All paths are set-up automatically.

Goal: Keep only those digitizers which implement a SteppingAction method and are thus deeply linked to the Geant4 event loop. Replace all other with post processors.

I'll write up a more detailed documentation soon.