You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Refactoring the new Async mode additions (apt-sim#321)
The goal of this PR is to adapt the new Asynchronous AdePT components to
the way the library is structured. This involves keeping a clear
separation between AdePT and the integration layer.
Main changes:
- Remove `AdePTConfiguration` from the integration layer.
This is an utility class which holds the AdePT configuration for a run,
it is part of AdePT and independent from the integration layer. However
the new `AdePTConfiguration::CreateAdePTInstance` is compiled as part of
`AdePTG4Integration`. In practice, this isn't a change from the previous
implementation, where the integration layer has the responsability of
initializing `AdePTConfiguration`, and also of passing the values in
`AdePTConfiguration` to `AdePTTransport`.
This will be changed in this PR, by introducing a new `AdePTTransport`
constructor which takes an `AdePTConfiguration` instance as an argument.
Now the integration layer is only responsible of initializing
`AdePTConfiguration`.
- `AdePTConfiguration` will now also store the number of threads, which
is used to compute the number of tracks and step slots allocated to each
thread in synchronous mode. By doing this, we will also remove the need
to store the number of slots per thread as `static inline` variables in
`AdePTTransport`. This was done because in Geant4 we can only get the
correct number of threads from the master, as the workers will report 1,
thus we can only compute the space per thread from the master. However
this is a G4-specific requirement that is not related to AdePT, so now,
instead of doing that, we store the number of threads as a `static
inline` variable in `AdePTTrackingManager`, on the integration side,
which each thread then passes on to `AdePTConfiguration`.
- Remove the `AdePTTransportFactory` method in favour of using the
`AdePTTransport` constructor.
This method is currently implemented as a free function that is part of
the integration layer. It is called from
`AdePTConfiguration::CreateAdePTInstance`.
In principle, it wouldn't be an issue to keep one factory per transport
backed, per integration layer, however at least for the synchronous
backend there seems to be little reason to use a factory method instead
the `AdePTTransport` constructor.
In order to
- Implement a constructor in `AdePTTransport` which takes an
`AdePTConfiguration` instance as an argument.
In the current implementation, the integration layer is supposed to
initialize `AdePTConfiguration` and also to pass those values on to
`AdePTTransport`. With this change, the integration layer only needs to
initialize the configuration.
- Move the instantiation of `ShowerGPU` back to to
`AdePTTrackingManager.cu`.
We need to instantiate `ShowerGPU` in a `.cu` file so that this function
is compiled by `nvcc`. This is a necessary evil, and needs to be done in
the integration layer since AdePT is a header-only library. This
function has currently been moved to `AdePTTransport.cu`, which lives on
the integration layer. As with the `AdePTConfiguration` change, in
practice the integration layer is still responsible of doing this
instantiation, it just lives on a different file. Since
`AdePTTransport.cu` is not actually related to `AdePTTransport`, and it
is `AdePTTrackingManager` that calls this function, I believe it is less
misleading to keep this in `AdePTTrackingManager.cu`.
- Remove the functionality to keep tracks returned by AdePT on host.
There are two main reasons for this:
- This functionality is meant to keep loopers returned from AdePT on
host, however it doesn't distinguish between loopers and particles that
simply stepped outside of the GPU region. This may be implemented in the
future in a similar manner, by having a special ID for loopers if
needed.
- However in the future we may need to keep unique IDs for GPU tracks,
in order to be able to identify them on host, so we can't use the ID
field for this.
- Remove the call to the user stepping action from the tracking manager.
- `G4SteppingManager::Stepping` already calls the stepping action
0 commit comments