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
This issue is for summarising the next couple of steps in the development for providing all fine-grained functionalities required by a complete integration into the ATLASand CMSdetector simulation environment that maximise the corresponding performance gain.
Required
Required for providing the same functionalities, configuration options given by the native part of the Geant4 toolkit and used today by ATLASand CMSin their detector simulation:
configuration per detector region: provide the possibility of applying different simulation parameters/algorithms/settings etc. in different detector region. Most importantly, different MSC stepping algorithm, MSC stepping algorithm parameters, energy loss fluctuation settings, etc.
refactor some of the data structures: most importantly the cross section data structures, that currently stores data in plane arrays. The idea is to simply introduce more structured data that makes easier the further manipulations and extensions of these cross section data. (note: this is not strictly required but makes the following developments as well as the maintenance significantly easier)
add the missing gamma- and lepto-nuclear interactions: according to the original plan, these interactions will be included only by their cross sections, i.e. G4HepEm will only determine if nuclear interaction needs to be performed but won't include the interaction description (final state generation). This can be done easily by the corresponding native Geant4 processes in the connection layer. The motivation is that, since these nuclear interaction cross sections are significantly smaller compared to the electromagnetic (and relevant at all only at higher energies), the frequency of these kind of interactions is very low (while the complete final state production would require complex hadronic components)
Further (performance) improvements:
Further items, that are not strictly required for the simulation, but provides significant performance benefits for ATLAS and CMS in their detector simulations. Therefore, these are necessary for making available all known related computing performance improvements for ATLASand CMSdetector simulations through G4HepEm:
"Woodcock-tracking" of $\gamma$ photons in a given detector region (see more details here or here)
Some functionalities, that might be necessary to provide if one of the HEP experiments requires to use them:
implement an $e^-/e^+$ MSC stepping algorithm that corresponds to the most accurate "error-free" stepping provided by Goudsmit-Saunderson MSC model of Geant4 (and currently utilised by CMS in the HGCAL)
The text was updated successfully, but these errors were encountered:
I know that, but I wanted to have all these functionalities summarized. Especially that they will need to be validated individually in the different experimental frameworks as some (like transportation with MSC) will definitely cause differences (at the level of hits for sure) that need to be seen (unless it will be already fully validated in the frameworks by that time which very likely won't be the case at least for one).
But actually we can add the link to the related PR so we can track them.
Upcoming development items
This issue is for summarising the next couple of steps in the development for providing all fine-grained functionalities required by a complete integration into the
ATLAS
andCMS
detector simulation environment that maximise the corresponding performance gain.Required
Required for providing the same functionalities, configuration options given by the native part of the
Geant4
toolkit and used today byATLAS
andCMS
in their detector simulation:configuration per detector region: provide the possibility of applying different simulation parameters/algorithms/settings etc. in different detector region. Most importantly, different MSC stepping algorithm, MSC stepping algorithm parameters, energy loss fluctuation settings, etc.
refactor some of the data structures: most importantly the cross section data structures, that currently stores data in plane arrays. The idea is to simply introduce more structured data that makes easier the further manipulations and extensions of these cross section data. (note: this is not strictly required but makes the following developments as well as the maintenance significantly easier)
add the missing gamma- and lepto-nuclear interactions: according to the original plan, these interactions will be included only by their cross sections, i.e.
G4HepEm
will only determine if nuclear interaction needs to be performed but won't include the interaction description (final state generation). This can be done easily by the corresponding nativeGeant4
processes in the connection layer. The motivation is that, since these nuclear interaction cross sections are significantly smaller compared to the electromagnetic (and relevant at all only at higher energies), the frequency of these kind of interactions is very low (while the complete final state production would require complex hadronic components)Further (performance) improvements:
Further items, that are not strictly required for the simulation, but provides significant performance benefits for
ATLAS
andCMS
in their detector simulations. Therefore, these are necessary for making available all known related computing performance improvements forATLAS
andCMS
detector simulations throughG4HepEm
:"Woodcock-tracking" of$\gamma$ photons in a given detector region (see more details here or here)
combined MSC with transportation for$e^-/e^+$ (see more details here or here)
(done: Add possibility of MSC stepping to HepEmTrackingManager #79)
Additional items:
Some functionalities, that might be necessary to provide if one of the HEP experiments requires to use them:
Goudsmit-Saunderson
MSC model ofGeant4
(and currently utilised byCMS
in theHGCAL
)The text was updated successfully, but these errors were encountered: