The G4HepEmData library documentation

Documentation of the global data structures defined in the G4HepEmData library. These data structures are filled at initialisation time by using the functionalities provided by the G4HepEmInit library and used (read-only) at run-time with the corresponding functionalities arranged into the G4HepEmRun library.

Global data structures

Global data structures are those used and shared by all particles and all workers. These includes

• G4HepEmParameters : a collection of configuration parameters

• G4HepEmMatCutData : a collection of material - (secondary production cuts) couple related data for all material - cuts couples used in the geometry

• G4HepEmMaterialData : a collection of material related data for all materials used in the geometry

• G4HepEmElementData : a collection of element related data for all elements used in the geometry

These data structures are built by the master G4HepEmRunManager in its G4HepEmRunManager::InitializeGlobal() method that is invoked at the first call to its G4HepEmRunManager::Initialize() method. These objects are owned by the master G4HepEmRunManager that stores a pointer to the them

• a pointer member to the G4HepEmParameters

• the pointers to the G4HepEmMatCutData, G4HepEmMaterialData, G4HepEmElementData objects are stored in the top level data structure, G4HepEmData member

The master shares these two data members with all the worker G4HepEmRunManagers by setting their own members pointing to the data stored in the master.

Further data structures, that are still global over the worker G4HepEmRunManager -s but specific for a given particle type, are also built and owned by the master G4HepEmRunManager, when its G4HepEmRunManager::Initialize() method is called with the given particle type as input argument. Pointers to these data structures are also stored in the G4HepEmData collection of the master and shared with the workers.

These are the G4HepEmElectronData structures for \(e^-/e^+\), that stores all integrated quantities (e.g. restricted dE/dx, range, inverse range, macroscopic cross section, target element selector data) for the two energy loss (i.e. continuous-discrete) interactions, ionisation and bremsstrahlung. Additional data structures, used by a give interaction description such as the G4HepEmSBTableData and shared by all workers, might also be stored in this top level G4HepEmData structure.

These global data structures are constructed and populated at the initialization phase and used (read-only) during the run of the simulation.

Note

There is an additional data structure, the G4HepEmTLData that is used only during the run of the simulation. Each worker has their own, individual object from this data and it’s used to store all worker-local data such as the pointer to the worker-local random number generator or the worker-local primary and secondary track buffers. This G4HepEmTLData is not global and used only at run-time so it’s defined in the G4HepEmRun library.

Host v.s. Device side memory layouts

Warning

At the moment, the same memory layout is used on the hots and device sides in order to (drastically > 95 %) increase the run-time G4HepEm codes that are reusable on the device side without any changes!

Investigation of possible performance gains, due to optimised device data memory, have been postponed for alter time when the GPU related simulations will be available.

These global data structures, especially the integrated cross section related quantities such as the restricted energy loss or macroscopic cross section related data stored in the G4HepEmElectronData structure, are used heavily in each simulation steps (some even more than once). By choosing the memory layout of these data, such that it resonate maximally to the run-time access pattern, ensures maximal performance benefits form data locality.

While the primary target platforms of the G4HepEm R&D project are those based on CPU (host), the project also supports GPU (device) based simulations. Since the optimal memory layout of the data is determined by the access pattern, and this is different on the host and device sides, the same data are stored in different formats on the host and device memory.

Host side memory layout of global data

A single track is propagated during the host side simulation and the above data are interpolated for the given primary particle energy. It means, that all the data, needed for a single kinetic energy interpolation, are accessed “at once”. Therefore, all these different type of data, for a single kinetic energy value, need to be as close to the CPU as possible i.e. in the L1 data cache. This can be facilitated by storing these different type of data, related to a single kinetic energy, next to or as close as possible to each other in the memory. This memory layout, together with the appropriate interpolation functions (implemented in the G4HepEmRun library) that exploit this memory pattern, ensures optimal data cache usage during the host side simulation leading to maximal (related) performance benefits.

As an example, the host side memory layout of the restricted macroscopic cross section related data (stored in the G4HepEmElectronData data structure for ionisation and bremsstrahlung for all material cuts - couples) is shown in Fig. 2. Since the macroscopic cross sections for ionisation and bremsstrahlung for a given material - cuts are accessed, i.e. interpolated for the given particle energy \(E\) after each other during the step limit computation, these data are stored one after the other for a given material - cuts couple. During the related part of the step limit, the first two auxiliary data is accessed in order to account the energy loss during the step, then the remaining two auxiliary data are used to compute the kinetic energy bin index \(i\) such that \(E_i \leq E < E_{i+1}\). Then the spline interpolation of these macroscopic cross sections is performed for the given primary energy of \(E\) that requires 6 data in case case: \(E_i, \Sigma(E_i), \Sigma(E_i)^{''},E_{i+1}, \Sigma(E_{i+1}), \Sigma(E_{i+1})^{''}\). As it can be seen in Fig. 2, similarly to the four auxiliary data, all these 6 data are located next to each other in the host side memory.

Fig. 2 Memory alignment of the restricted macroscopic cross section data stored in the G4HepEmElectronData structure for all G4HepEmMCCData, material-cuts couple data.

Device side memory layout of global data

When multiple tracks (arranged according to some common properties e.g. particle type and/or current volume i.e. material - cuts couple etc.) are propagated simultaneously, the above data are interpolated to the different primary particle kinetic energies of the tracks. It means, that the different type of data, needed during the step limitation (spline interpolation), are accessed one after the other by all tracks simultaneously. Therefore, the same type of the data, for all the discrete kinetic energies, should be located next to or as close as possible to each other in order to facilitate coalesced memory access.

As an example, the memory layout of the device side version of the host side restricted macroscopic cross section related data shown in Fig 2, is shown in Fig 3. As it can be seen, the macroscopic cross section related data, stored continuously in a single array on the host side, is split into 6 different arrays according to the type of the data in order to facilitate coalesced memory access.

Fig. 3 Device side memory alignment of the restricted macroscopic cross section data stored in the G4HepEmElectronDataOnDevice structure for all G4HepEmMCCData, material-cuts couple data.

An additional example, the energy loss related data, is shown in Fig 4 and Fig 5.

Fig. 4 Memory alignment of the energy loss data stored in the G4HepEmElectronData structure for all G4HepEmMCCData, material-cuts couple data.

Fig. 5 Device side memory alignment of the energy loss data stored in the G4HepEmElectronDataOnDevice structure for all G4HepEmMCCData, material-cuts couple data.

The G4HepEmParameters data structure

struct G4HepEmParameters

Physics configuration related parameters.

Collection of physics modelling related configuration parameters used in G4HepEm at initialization- and run-time.

Author

M. Novak

Date

2020

A single instance of this structure is created and stored in the master G4HepEmRunManager when its InitializeGlobal() method is invoked by calling the InitHepEmParameters() function declared in the G4HepEmParamatersInit header file. This method extracts information (mainly) from the G4EmParameters singletone object.

Public Members

double fElectronTrackingCut

\(e^-/e^+\) tracking (kinetic) energy cut in Geant4 internal energy units: \(e^-/e^+\) tracks are stopped when their energy drops below this threshold, their kinetic energy is deposited and annihilation to two \(\gamma\)-s interaction is invoked for in case of \(e^+\).

double fMinLossTableEnergy

Minimum of the kinetic energy grid used to build the sub-(secondary-production)threshold related energy loss quantity tables such as the restricted stopping power, range and inverse range tables.

double fMaxLossTableEnergy

Maximum of the kinetic energy grid for loss tables.

int fNumLossTableBins

Number of bins (equally spaced on log scale) of the loss table kinetic energy grid.

double fFinalRange

The final range parameter of the sub-threshold energy loss related step limit function.

double fDRoverRange

The rover range parameter of the sub-threshold energy loss related step limit function.

double fLinELossLimit

Maximum allowed linear energy loss along step due to sub-threshold (continuous) energy losses given as fraction of the intial kinetic energy.

Proper integral is used to compute the mean energy loss when the energy loss, according to linear approximation, is over this threshold.

double fElectronBremModelLim

Kinetic energy limit between the two (Seltzer-Berger and Relativistic) models for bremsstrahlung photon emission in case of \(e^-/e^+\) primary particles.

---

The G4HepEmMatCutData, G4HepEmMaterialData and G4HepEmElementData data structures

Describe this in a nutshell

Code documentation

struct G4HepEmMatCutData

All material - cuts couple related data used by G4HepEm.

All material - cuts (secondary production threshold) couple related data, used by G4HepEm, is stored in this simple data structure. The G4HepEmMatCutData structure contains a collection of G4HepEmMCCData for each G4MaterialCutsCouple object that is used in the geometry. Such a G4HepEmMCCData stores a single material-cuts couple realted data required during the simulation.

Author

M. Novak

Date

2020

A single instance of this structure is created and stored in the master G4HepEmRunManager when its InitializeGlobal() method is invoked by calling the InitMaterialAndCoupleData() function declared in the G4HepEmMaterialInit header file. This method extracts information form the already initialised part of the Geant4 application (i.e. G4MaterialCutsCoupleTable) by reading all G4MaterialCutsCouple objects used in the current geometry, translating them into G4HepEmMCCData strcutrues and store in this single G4HepEmMatCutData sturcture.

In case of CUDA build, the data can be easily copied to the device by either using the CopyMatCutDataToGPU() function or the more general CopyG4HepEmDataToGPU() function: the first will copy only the specified G4HepEmMatCutData structure while the second will (deep copy) all the members (including the G4HepEmMatCutData one) of the G4HepEmData, top level data structure member of the (master) G4HepEmRunManager.

Note

only the data members that are needed on the device side are copied to the device memory. This means, that only the G4HepEmMatCutData::fMatCutData collection of the G4HepEmMCCData structures is copied to the device memory together with the G4HepEmMatCutData::fNumMatCutData length of this collection.

Public Members

int fNumG4MatCuts = 0

Number of G4MaterialCutsCouple objects in Geant4 (irrespectively if used or not).

int fNumMatCutData = 0

Number of G4HepEmMCCData structure in G4HepEm (only the used G4MaterialCutsCouple objects are translated).

int *fG4MCIndexToHepEmMCIndex = nullptr

Array that translates a Geant4 G4MaterialCutsCouple object index to the correspondig G4HepEmMCCData index in the collection below.

struct G4HepEmMCCData *fMatCutData = nullptr

Collection of G4HepEmMCCData structures for all material-cuts couples used in the current geometry.

struct G4HepEmMCCData

Data that describes a single matrial-cuts couple in G4HepEm.

Public Members

double fSecElProdCutE = 0.0

Secondary \(e^-\) production threshold energy [MeV].

double fSecGamProdCutE = 0.0

Secondary \(\gamma\) production threshold energy [MeV].

double fLogSecGamCutE = 0.0

Logarithm of the above secondary \(\gamma\) production threshold.

int fHepEmMatIndex = -1

Index of its material realted data: index of its G4HepEmMatData in the G4HepEmMaterialData.

int fG4MatCutIndex = -1

Index of the corresponding G4MaterialCutsCouple object.

void AllocateMatCutData(struct G4HepEmMatCutData **theMatCutData, int numG4MatCuts, int numUsedG4MatCuts)

Allocates and pre-initialises the G4HepEmMatCutData structure.

This method is invoked from the InitMaterialAndCoupleData() function declared in the G4HepEmMaterialInit header file. The input argument address of the G4HepEmMatCutData structure pointer is the one stored in the G4HepEmData member of the master G4HepEmRunManager and the initialisation should be done by the master G4HepEmRunManager.

Parameters:

• theMatCutData – address of a G4HepEmMatCutData structure pointer. At termination, the correspondig pointer will be set to a memory location with a freshly allocated G4HepEmMatCutData structure. If the pointer is not null at input, the pointed memory is freed before the new allocation.

• numG4MatCuts – [in] number of Geant4 material-cuts couple objects (irrespectively if used or not). It determines the maximum value of the G4MaterialCutsCouple object index.

• numUsedG4MatCuts – [in] number of Geant4 material-cuts couple objects used in the current geometry. It determines the number of the G4HepEmMCCData structures.

void FreeMatCutData(struct G4HepEmMatCutData **theMatCutData)

Frees a G4HepEmMatCutData structure.

This function deallocates all dynamically allocated memory stored in the input argument related G4HepEmMatCutData structure, deallocates the structure itself and sets the input address to store a pointer to null. This makes the corresponding input stucture cleared, freed and ready to be re-initialised. The input argument is supposed to be the address of the corresponding pointer member of the G4HepEmData member of the master G4HepEmRunManager.

Parameters:

theMatCutData – memory address that stores pointer to a G4HepEmMatCutData structure. The memory is freed and the input address will store a null pointer at termination.

void CopyMatCutDataToGPU(struct G4HepEmMatCutData *onHost, struct G4HepEmMatCutData **onDevice)

Allocates memory for and copies the G4HepEmMatCutData structure from the host to the device.

Only the G4HepEmMatCutData::fMatCutData collection of the G4HepEmMCCData structures is copied to the device together with the G4HepEmMatCutData::fNumMatCutData length of this collection.

The input arguments are supposed to be the corresponding members of the G4HepEmData, top level data structure, stored in the master G4HepEmRunManager.

Parameters:

• onHost – pointer to the host side, already initialised G4HepEmMatCutData structure.

• onDevice – host side address of a G4HepEmMatCutData structure memory pointer. The pointed memory is cleaned (if not null at input) and points to the device side memory at termination that stores the copied G4HepEmMatCutData structure.

void FreeMatCutDataOnGPU(struct G4HepEmMatCutData **onDevice)

Frees all memory related to the device side G4HepEmMatCutData structure referred by the pointer stored on the host side input argument address.

Parameters:

onDevice – host side address of a G4HepEmMatCutData structure located on the device side memory. The correspondig device memory will be freed and the input argument address will be set to null.

---

struct G4HepEmMaterialData

All material related data used by G4HepEm.

All material related data, used by G4HepEm, is stored in this simple data structure. The G4HepEmMaterialData structure contains a collection of G4HepEmMatData for each G4Material object that is used in the geometry. Such a G4HepEmMatData stores a single material realted data required during the simulation.

Author

M. Novak

Date

2020

A single instance of this structure is created and stored in the master G4HepEmRunManager when its InitializeGlobal() method is invoked by calling the InitMaterialAndCoupleData() function declared in the G4HepEmMaterialInit header file. This method extracts information form the already initialised part of the Geant4 application (i.e. G4MaterialCutsCoupleTable) by reading all G4MaterialCutsCouple objects used in the current geometry, translating their G4Material objects into G4HepEmMatData strcutrues and store in this single G4HepEmMaterialData sturcture.

In case of CUDA build, the data can be easily copied to the device by either using the CopyMaterialDataToGPU() function or the more general CopyG4HepEmDataToGPU() function: the first will copy only the specified G4HepEmMaterialData structure while the second will (deep copy) all the members (including the G4HepEmMaterialData one) of the G4HepEmData, top level data structure member of the (master) G4HepEmRunManager.

Note

only the data members that are needed on the device side are copied to the device memory. This means, that only the G4HepEmMaterialData::fMaterialData collection of the G4HepEmMatData structures is copied to the device memory together with the G4HepEmMaterialData::fNumMaterialData length of this collection.

Public Members

int fNumG4Material = 0

Number of Geant4 material objects (irrespectively if used or not).

int fNumMaterialData = 0

Number of G4HepEmMatData structures in G4HepEm (only the used G4Material objects are translated).

int *fG4MatIndexToHepEmMatIndex = nullptr

Array that translates a Geant4 G4Material object index to the correspondig G4HepEmMatData index in the collection below.

struct G4HepEmMatData *fMaterialData = nullptr

Collection of G4HepEmMatData structures for all materials used in the current geometry.

struct G4HepEmMatData

Data that describes a single matrial in G4HepEm.

Public Members

int fG4MatIndex = -1

The corresponding G4Material object index.

int fNumOfElement = 0

Number of elements this matrial is composed of (size of the arrays below).

int *fElementVect = nullptr

The list of element indices in G4HepEmElemData (their atomic number Z), this material is composed of.

double *fNumOfAtomsPerVolumeVect = nullptr

The list of number-of-atoms-per-unit-volume for each element this material is composed of.

double fDensity = 0.0

The mass density ( \(\rho\)) of the material in Geant4 internal units.

double fDensityCorFactor = 0.0

Density correction factor ( \(C_{Mg}\rho_{e^-}\)) used in the dielectric suppression of bremsstrahlung photon emission ( \(C_{Mg}=4\pi r_0 \hbar c/(mc^2)\) is the Migdal constant and \(\rho_{e^-}\) is the electron density of the material).

double fElectronDensity = 0.0

Electron density ( \(\rho_{e^-}\)) of the material in Geant4 internal units.

double fRadiationLength = 0.0

Radiation length.

double fMeanExEnergy = 0.0

Mean excition energy.

int fNumOfSandiaIntervals = 0

Number of intervals in the Sandia table.

double *fSandiaEnergies = nullptr

Starting energy of the intervals.

double *fSandiaCoefficients = nullptr

Coefficients for the interval (four per energy range)

void AllocateMaterialData(struct G4HepEmMaterialData **theMatData, int numG4Mat, int numUsedG4Mat)

Allocates and pre-initialises the G4HepEmMaterialData structure.

This method is invoked from the InitMaterialAndCoupleData() function declared in the G4HepEmMaterialInit header file. The input argument address of the G4HepEmMaterialData structure pointer is the one stored in the G4HepEmData member of the master G4HepEmRunManager and the initialisation should be done by the master G4HepEmRunManager.

Parameters:

• theMatData – address of a G4HepEmMaterialData structure pointer. At termination, the correspondig pointer will be set to a memory location with a freshly allocated G4HepEmMaterialData structure. If the pointer was not null at input, the pointed memory is freed before the new allocation.

• numG4Mat – number of Geant4 material objects (irrespectively if used or not). It determines the maximum value of the G4Material object index.

• numUsedG4Mat – number of Geant4 material objects used in the current geometry. It determines the number of the G4HepEmMatData structures.

void FreeMaterialData(struct G4HepEmMaterialData **theMatData)

Frees a G4HepEmMaterialData structure.

This function deallocates all dynamically allocated memory stored in the input argument related G4HepEmMaterialData structure, deallocates the structure itself and sets the input address to store a pointer to null. This makes the corresponding input stucture cleared, freed and ready to be re-initialised. The input argument is supposed to be the address of the corresponding pointer member of the G4HepEmData member of the master G4HepEmRunManager.

Parameters:

theMatData – memory address that stores pointer to a G4HepEmMaterialData structure. The memory is freed and the input address will store a null pointer at termination.

void CopyMaterialDataToGPU(struct G4HepEmMaterialData *onHost, struct G4HepEmMaterialData **onDevice)

Allocates memory for and copies the G4HepEmMaterialData structure from the host to the device.

Only the G4HepEmMaterialData::fMaterialData collection of the G4HepEmMatData structures is copied to the device together with the G4HepEmMaterialData::fNumMaterialData length of this collection.

The input arguments are supposed to be the corresponding members of the G4HepEmData, top level data structure, stored in the master G4HepEmRunManager.

Parameters:

• onHost – pointer to the host side, already initialised G4HepEmMaterialData structure.

• onDevice – host side address of a G4HepEmMaterialData structure memory pointer. The pointed memory is cleaned (if not null at input) and points to the device side memory at termination that stores the copied G4HepEmMaterialData structure.

void FreeMaterialDataOnGPU(struct G4HepEmMaterialData **onDevice)

Frees all memory related to the device side G4HepEmMaterialData structure referred by the pointer stored on the host side input argument address.

Parameters:

onDevice – host side address of a G4HepEmMaterialData structure located on the device side memory. The correspondig device memory will be freed and the input argument address will be set to null.

---

struct G4HepEmElementData

All element related data used by G4HepEm.

All element related data, used by G4HepEm, is stored in this simple data structure. The G4HepEmElementData structure contains a collection of G4HepEmElemData for each G4Element object that is used in the geometry. Such a G4HepEmElemData stores a single element realted data required during the simulation.

Author

M. Novak

Date

2020

A single instance of this structure is created and stored in the master G4HepEmRunManager when its InitializeGlobal() method is invoked by calling the InitMaterialAndCoupleData() function declared in the G4HepEmMaterialInit header file. This method extracts information form the already initialised part of the Geant4 application (i.e. G4MaterialCutsCoupleTable) by reading all G4MaterialCutsCouple objects used in the current geometry, translating their G4Element objects into G4HepEmElemData strcutrues and stores in this single G4HepEmElementData sturcture.

In case of CUDA build, the data can be easily copied to the device by either using the CopyElementDataToGPU() function or the more general CopyG4HepEmDataToGPU() function: the first will copy only the specified G4HepEmElementData structure while the second will (deep copy) all the members (including the G4HepEmElementData one) of the G4HepEmData, top level data structure member of the (master) G4HepEmRunManager.

Public Members

int fMaxZet = 0

Maximum capacity of the below G4HepEmElemData structure container (max Z that can be stored).

struct G4HepEmElemData *fElementData = nullptr

Collection of G4HepEmElemData structures indexed by the atomic number Z.

struct G4HepEmElemData

Data that describes a single element in G4HepEm.

Public Members

double fZet = -1.0

The atomic number (Z) of the element.

double fZet13 = 0.0

\(Z^{1/3}\)

double fZet23 = 0.0

\(Z^{2/3}\)

double fCoulomb = 0.0

Coulomb correction \( f_C \).

double fLogZ = 0.0

\( \ln(Z) \)

double fZFactor1 = 0.0

\( F_{\text{el}}-f_c+F_{\text{inel}}/Z \)

double fDeltaMaxLow = 0.0

\( \exp \left[ \frac{42.038-F_{\text{low}}}{8.29} \right] -0.958 \) with \( Z_{\text{low}} = \frac{8}{3}\log(Z) \)

double fDeltaMaxHigh = 0.0

\( \exp \left[ \frac{42.038-F_{\text{high}}}{8.29} \right] -0.958 \) with \( F_{\text{high}} = 8[\log(Z)/3 + f_C] \)

double fILVarS1 = 0.0

LPM variable \( 1/ln [ \sqrt{2}s1 ] \).

double fILVarS1Cond = 0.0

LPM variable \( 1/ln[s1] \).

int fNumOfSandiaIntervals = 0

Number of intervals in the Sandia table.

double *fSandiaEnergies = nullptr

Starting energy of the intervals.

double *fSandiaCoefficients = nullptr

Coefficients for the interval (four per energy range)

double fKShellBindingEnergy = 0

Binding energy of the k-shell.

void AllocateElementData(struct G4HepEmElementData **theElementData)

Allocates and pre-initialises an existing G4HepEmMaterialData structure.

This method is invoked from the InitMaterialAndCoupleData() function declared in the G4HepEmMaterialInit header file. The input argument address of the G4HepEmElementData structure pointer is the one stored in the G4HepEmData member of the master G4HepEmRunManager and the initialisation should be done by the master G4HepEmRunManager.

Param :

void FreeElementData(struct G4HepEmElementData **theElementData)

Frees a G4HepEmElementData structure.

This function deallocates all dynamically allocated memory stored in the input argument related G4HepEmElementData structure, deallocates the structure itself and sets the input address to store a pointer to null. This makes the corresponding input stucture cleared, freed and ready to be re-initialised. The input argument is supposed to be the address of the corresponding pointer member of the G4HepEmData member of the master G4HepEmRunManager.

Param :

void CopyElementDataToGPU(struct G4HepEmElementData *onHost, struct G4HepEmElementData **onDevice)

Allocates memory for and copies the G4HepEmElementData structure from the host to the device.

The input arguments are supposed to be the corresponding members of the G4HepEmData, top level data structure, stored in the master G4HepEmRunManager.

Parameters:

• onHost – pointer to the host side, already initialised G4HepEmElementData structure.

• onDevice – host side address of a G4HepEmElementData structure memory pointer. The pointed memory is cleaned (if not null at input) and points to the device side memory at termination that stores the copied G4HepEmElementData structure.

void FreeElementDataOnGPU(struct G4HepEmElementData **onDevice)

Frees all memory related to the device side G4HepEmElementData structure referred by the pointer stored on the host side input argument address.

Parameters:

onDevice – host side address of a G4HepEmElementData structure located on the device side memory. The correspondig device memory will be freed and the input argument address will be set to null.

---

struct G4HepEmElectronData

All energy loss process related data used for \(e^-/e+\) simulations by G4HepEm.

Energy loss processes are the Ionisation and Bremsstrahlung interactions described by using the condensed history approach. It means, that sub-threshold interactions are modelled as continous energy losses along the particle steps while super-threshold interactions, i.e. generation of secondary \(e^-/\gamma\) particles in case of ionisation/bremsstrahlung with intitial energy above the secondary production threshold, are modelled explicitly as point like, discrete interactions. This data structure contains all the data required to account these interactions at run-time.

Author

M. Novak

Date

2020

The continous energy loss is characterised by the restricted stopping power, which is the mean value of the energy losses due to the sub-threshold interactions along a unit step lenght, and other related quantities such as the corresponding restricted range or restricted inverse range values. The restricted (ionisation - electronic)/(bremsstrahlung - radiative) stopping power depend on the primary particle type, kinetic energy, target material and secondary \(e^-\)(electronic)/ \(\gamma\)(radiative) production threshold values. Therefore, such tables are built separately \(e^-\) and \(e^+\), over a wide enough range of primary particle kinetic energy (100 [eV] - 100 [TeV] by default) for all material and secondary prodcution threshold pairs, or according to the Geant4 terminology, for all material - cuts couples. The tables contain the sum of the electronic and radiative contributions. These tables, stored in this data structure, are used to determine the continous part of the step limit and to compute the sub-threshold realted, continous energy losses at each step done by \(e^-/e^+\).

The rate of the dicrete super-threshold ionisation and bremsstrahlung interactions are characterised by the corresponding restricted macroscopic cross sections. These also depend on the primary particle type, kinetic energy, target material -cuts couple. Moreover, the minimum value of the kinetic energy grid is determined by the secondary \(e^-\)(ionisation) \(/\gamma\)(bremsstrahlung) production energy thresholds that (since Geant4 rquires the user to specify these in lenght) is diffrent in case of each material-cuts couple whenever wither the material or the cut value (in length) is different. Therefore, these restricted macroscopic cross sction tables are built separately for \(e^-/e^+\) primary particles, separately for ionisation and bremsstrahlung for all different material - cuts couples with individual kinetic energy grids. These tables are used to determine the discrete part of the step limit, i.e. the length that the primary \(e^-/e^+\) travels till the next ionisation/bremsstrahlung interaction in the given material - cuts couple, resulting in secondary \(e^-/\gamma\) particle production with initial energy above the secondary \(e^-/\gamma\) production cut in the given material - cuts couple.

The macroscopic cross section determines the (mean) path length, the primary particles travels, till the next discrete interaction in the given material (actually material - cuts couple in case of ioni. and brem. since we use the condensed history approach). The discrete bremsstrahlung interaction takes place in the vicinity of one of the elements of the material. A so-called target atom selector is constructed for each model (also for ionisation though its not used), based on the partial contribution of the individual elements of a given material - cuts to the corresponding macroscopic cross section. These data are used to select the target atom for discrete interaction at run-time.

Note

Other interactions, beyond ionisation and bremsstrahlung, are also active in case of \(e^-/e^+\) like Coulomb scattering or annihilation into two \(\gamma\)-s in case of \(e^+\). However, their descriptions are rather different compared to these two energy loss processes:

• Coulomb scattering is described by a so-called multiple scattering model

• while \(e^+\) annihilation is a discrete process, so similar to the discrete ionisation and bremsstrahlung interactions, the corresponding cross section doesn’t depend neither the secondary production thresholds nor the element composition (directly). Unlike ionisation or even more bremsstrahlung, the cross section for annihilation can be easily computed on-the-fly so there is no need to pre-compute and store values in tables.

Energy loss related data members:

These members are used to store all continuous energy loss related data (there is a single primary kinetic energy grid for all material - cuts equally spaced in log-scale).

int fELossEnergyGridSize = 0

Number of discrete kinetic energy values in the grid ( \(N\)).

double fELossLogMinEkin = 0.0

Logarithm of the minimum kinetic energy value of the grid ( \(\ln(E_0)\))

double fELossEILDelta = 0.0

Inverse of the log-scale delta value ( \( 1/[log(E_{N-1}/E_0)/(N-1)]\)).

double *fELossEnergyGrid = nullptr

The grid of the discrete kinetic energy values ( \(E_0, E_1,\ldots, E_{N-1}\)).

double *fELossData = nullptr

The energy loss data: restricted dE/dx, range and inverse range data.

The restricted dE/dx, range (and corresponding inverse range) data values, over the above kinetic energy grid for all material - cuts couples, are stored continuously in this G4HepEmElectronData::fELossData single array. The second derivative values, required for the run-time spline interpolation, are also stored together with the data.

The data are stored in the following format for each of the G4HepEmMCCData material - cuts couples, stored in the G4HepEmMatCutData::fMatCutData array:

• for each material - cuts couple, there are \(N := \) G4HepEmElectronData::fELossEnergyGridSize range values associated to the primary \(e^-/e^+\) kinetic energy values stored in G4HepEmElectronData::fELossEnergyGrid. These \(R_i, i=0,\ldots,N-1\) range values are stored with the corresponding \(R_i^{''}, i=0,\ldots,N-1\) second derivatives in the form of \(R_0,R_0^{''},R_{1},R_{1}^{''},\ldots,R_{N-1},R_{N-1}^{''}\) in order to resonate the best with the run-time access pattern.

• then the corresponding \(N\), \(dE/dx\) values are stored in a similar way \(dE/dx_0,dE/dx_0^{''},dE/dx_{1},dE/dx_{1}^{''},\ldots,dE/dx_{N-1},dE/dx_{N-1}^{''}\)

• since both the range, and the kinetic energy values are already stored (see above), only the corresponding \(N\) second derivative values associated to the inverse range are stored then as \(S_0,S_1,\ldots,S_{N-1}\)

• it means, that there are \(5\times N\) energy loss realted data values stored continuously in the G4HepEmElectronData::fELossData array for each material - cuts couples. Therefore, in the case of a G4HepEmMCCData material - cuts couple data with the index of \(\texttt{imc}\) (i.e. in the case of the G4HepEmMCCData, stored at G4HepEmMatCutData::fMatCutData[ \(\texttt{imc}\)]), the start indices of the corresponding energy loss related data in the G4HepEmElectronData::fELossData array:

  • range data starts at the index of \(\texttt{imc}\times(5\times N\))

  • dE/dx data starts at the index of \(\texttt{imc}\times(5\times N\)) + \(2\times N\)

  • inverse range data starts at the index of \(\texttt{imc}\times(5\times N\)) + \(4\times N\)

The total number of data stored in the G4HepEmElectronData::fELossData array is G4HepEmElectronData::fNumMatCuts \(\times5\times\)G4HepEmElectronData::fELossEnergyGridSize

At run-time, for a given \(E\) primary kinetic energy G4HepEmElectronData::fELossLogMinEkin and G4HepEmElectronData::fELossEILDelta are used to compute the energy bin index \(i\) such that \( E_i \leq E < E_{i+1}, i=0,\ldots,N-1\). Then for the given material - cuts couple index, the above starts indices can be used to access the corresponding energy loss data and second derivatives associated to the primary kinetic energies of \( E_i, E_{i+1}\) needed to perform the spline interpolation.

Note

There is a spline interpolation function in G4HepEmRunUtils, specialised for the above pattern used to store the dE/dx and range data. Using this function ensures optimal data cache utilisation at run-time. A separate, more traditional spline interpolation function is used for run-time inverse range data interpolation. These are utilised in the G4HepEmElectronManager to ensure the optimal run-time performance (both in terms of memory consumption and speed) when accessing the restricted energy loss related, i.e. stopping power, range and inverse range data in the \(e^-/e^+\) stepping.

Restricted macroscopic cross section related data members:

These members are used to store all restricted macroscopic cross section related data both for ionisation and bremsstrahlung for all material - cuts couples.

int fResMacXSecNumData = 0

Total number of restricted macroscopic cross sections realted data stored in the single G4HepEmElectronData::fResMacXSecData array.

int *fResMacXSecStartIndexPerMatCut = nullptr

Start index of the macroscopic cross section data, for the material - cuts couple with the given index, in the G4HepEmElectronData::fResMacXSecData array.

double *fResMacXSecData = nullptr

The restricted macroscopic cross section data for ionisation and bremsstrahlung for all material - cuts couples.

All the restricted macroscopic cross section data are stored continuously in this G4HepEmElectronData::fResMacXSecData single array. The restricted macroscopic cross sections go to zero at primary kinetic energies lower than or equal to the secondary production threshold: at the secondary \(e^-\) production threshold in the case of \(e^+\) and \(2\times\) of it in the case of \(e^-\) ionisation, while the secondary \(\gamma\) production threshold energy in case of bremsstrahlung. It means that, the minimum value of the primary kinetic energy grid depends on the type of the interaction (ioni. or brem.) as well as the production cut values. Therefore, an individual primary kinetic energy grid is generated, and stored together with the corresponding restricted macroscopic cross section values, for each individual material - cuts couples, separately for ionisation and for bremsstrahlung in each cases.

The data are stored in the following format for each of the G4HepEmMCCData material - cuts couples (stored in the G4HepEmMatCutData::fMatCutData array):

• for a G4HepEmMCCData material - cuts couple data with the index of \(\texttt{imc}\) (i.e. stored at G4HepEmMatCutData::fMatCutData[ \(\texttt{imc}\)]), the macroscopic scross section realted data starts at G4HepEmElectronData::fResMacXSecData[ \(\texttt{ioniStarts}\)], where \(\texttt{ioniStarts}=\)G4HepEmElectronData::fResMacXSecStartIndexPerMatCut [ \(\texttt{imc}\)]

• then relative to this \(\texttt{ioniStarts}\) start index, first the restricted macroscopic cross section data for ionisation:

  • [0]: \(M:=M^{\text{(ioni)}\texttt{-imc}}\): number of \(E_i, i=0,\ldots,M-1\) primary kinetic energy points over which the \(\Sigma:=\Sigma^{\text{(ioni)}\texttt{-imc}}(E_i)\) restricted macroscopic cross section for ionisation is computed and stored for this material - cuts couple with the index of \(\texttt{imc}\).

  • [1]: \(\texttt{argmax}\{\Sigma(E_i)\}, i=0,\ldots,M-1\)

  • [2]: \(\texttt{max}\{\Sigma(E_i)\}, i=0,\ldots,M-1\)

  • [3]: \(\log(E_0)\)

  • [4]: \(1/[log(E_{M-1}/E_0)/(M-1)]\)

  • [5 : 5 + 3xM-1]: \(E_0,\Sigma(E_0),\Sigma(E_0)^{''},E_1,\Sigma(E_1),\Sigma(E_1)^{''},\ldots,E_{M-1},\Sigma(E_{M-1}), \Sigma(E_{M-1})^{''}\) where \(^{''}\) denotes the second derivatives.

• then continuously from the \(\texttt{bremStarts} = \texttt{ioniStarts} + 3\times M+5 \) index, the restricted macroscopic cross section data for bremsstrahlung:

  • [0]: \(N:=N^{\text{(brem)}\texttt{-imc}}\): number of \(E_i, i=0,\ldots,N-1\) primary kinetic energy points over which the \(\Sigma:=\Sigma^{\text{(brem)}\texttt{-imc}}(E_i)\) restricted macroscopic cross section for bremsstrahlung is computed and stored for this material - cuts couple with the index of \(\texttt{imc}\).

  • [1]: \(\texttt{argmax}\{\Sigma(E_i)\}, i=0,\ldots,N-1\)

  • [2]: \(\texttt{max}\{\Sigma(E_i)\}, i=0,\ldots,N-1\)

  • [3]: \(\log(E_0)\)

  • [4]: \(1/[log(E_{N-1}/E_0)/(N-1)]\)

  • [5 : 5 + 3xN-1]: \(E_0,\Sigma(E_0),\Sigma(E_0)^{''},E_1,\Sigma(E_1),\Sigma(E_1)^{''},\ldots,E_{N-1},\Sigma(E_{N-1}), \Sigma(E_{N-1})^{''}\) where \(^{''}\) denotes again the second derivatives.

The total number of data, i.e. the length of the G4HepEmElectronData::fResMacXSecData array, is stored in G4HepEmElectronData::fResMacXSecData.

At run-time, for a given \(E\) primary kinetic energy and material - cuts couple with the index of \(\texttt{imc}\),

• the start index of the macroscopic cross section data for ionisation is given by \(\texttt{ioniStarts}\)=G4HepEmElectronData::fResMacXSecStartIndexPerMatCut[ \(\texttt{imc}\)]

• then G4HepEmElectronData::fResMacXSecData[ \(\texttt{ioniStarts}\)+3] and G4HepEmElectronData::fResMacXSecData[ \(\texttt{ioniStarts}\)+4] can be used to compute the kinetic energy bin index \(i\) such that \( E_i \leq E < E_{i+1}, i=0,\ldots,\)G4HepEmElectronData::fResMacXSecData[ \(\texttt{ioniStarts}\)] \(-1\).

• then the kinetic energies, macroscopic cross sections and their second derivatives, associated to the primary kinetic energies of \( E_i, E_{i+1}\) are used to perform the spline interpolation

• the start index of the corresponding macroscopic cross section data for bremsstrahlung is given by \(\texttt{bremStarts} = \texttt{ioniStarts} + 5 + 3\times\)G4HepEmElectronData::fResMacXSecData[ \(\texttt{ioniStarts}\)]

• then the same procedure can be applied as above to compute the kinetic energy bin index and perform the interpolation, but now relative to \(\texttt{bremStarts}\) instead of the above \(\texttt{ioniStarts}\)

Note

Note, that all the 6 data, that are needed for the run-time interpolation of the restricted macroscopic scross sections are stored next to each other in the memory for both interactions (ionisation and bremsstrahlung). Moreover, for a given material - cuts couple, the data for the two interactions are stored one after the other. Together with the corresponding special spline interpolation function of G4HepEmRunUtils, that ensures a maximal profit of this memory layout, it makes optimal utilisation of the data cache at run-time. This special spline interpolation is utilised in the G4HepEmElectronManager to ensure the optimal run-time performance (both in terms of memory consumption and speed) when accessing the restricted macroscopic cross section data in the \(e^-/e^+\) stepping.

Macroscopic first transport corss section related data members:

These members are used to store all macroscopic first transport cross section related data for all materials.

The discrete energy grid, above which that disceret cross section values are computed and stored, is the same as used for the energy loss data.

double *fTr1MacXSecData = nullptr

The macroscopic first transport cross section.

The data are stored in the following format for each of the G4HepEmMatData material (stored in the G4HepEmMaterialData::fMaterialData array):

• there are \(N := \) G4HepEmElectronData::fELossEnergyGridSize **(macroscopic) first transport cross section values** associated to the primary \(e^-/e^+\) kinetic energy values stored in G4HepEmElectronData::fELossEnergyGrid. These \(TR1_i, i=0,\ldots,N-1\) values are stored with the corresponding \(TR1_i^{''}, i=0,\ldots,N-1\) second derivatives in the form of \(TR1_0,TR1_0^{''},TR1_{1},TR1_{1}^{''},\ldots,TR1_{N-1},TR1_{N-1}^{''}\) in order to resonate the best with the run-time access pattern.

• for a G4HepEmMatData material data with the index of \(\texttt{im}\) (i.e. stored at G4HepEmMaterialData::fMaterialData[ \(\texttt{im}\)]), the macroscopic first transport cross section realted data starts at \(\texttt{iStart} = 2\times\)G4HepEmElectronData::fELossEnergyGridSize \(\times\texttt{im}\) in the G4HepEmElectronData::fTr1MacXSecData array

• the total number of data in the array is \(2\times\)G4HepEmElectronData::fELossEnergyGridSize \(\times\)G4HepEmElectronData::fNumMaterials

Note

There is a spline interpolation function in G4HepEmRunUtils, specialised for the above pattern used to store the dE/dx and range data. Using this function ensures optimal data cache utilisation at run-time.

Target element selector related data members:

These members store data utilised at run-time for the selection of the target elements (in case of multi element atoms) on which the interaction takes palce.

Data are stored for all the interaction models used to describe both ionisation and bremsstrahlung and for all material - cuts couples.

These data are the normalised, element-wise contributions to the corresonding macroscopic cross sections in case of multi element materials. Therefore, similarly to the above restricted macroscopic cross sections, different energy grids are generated for the the different material - cuts couples. The data are also stored in a separate, single continuous array per interaction model. The total number of data, i.e. the size of this single array as well as the start indices of the data, related to the different material - cuts couples, are stored for each of the three interaction models.

The data are stored in the following format for each of the individual interaction models, for each the G4HepEmMCCData material - cuts couples (stored in the G4HepEmMatCutData::fMatCutData array):

• for a G4HepEmMCCData material - cuts couple data with the index of \(\texttt{imc}\) (i.e. stored at G4HepEmMatCutData::fMatCutData[ \(\texttt{imc}\)]), the element selector data starts at the index \(\texttt{iStarts}=\texttt{fElemSelectorXYStartIndexPerMatCut[imc]}\) where \(XY\) is one of the three models, i.e. \(\{\texttt{Ioni, BremSB, BremRB}\}\) for the Moller-Bhabha ionisation, Seltzer-Berger or the relativistic bremsstrahlung models.

• if the material, associated to this material - cuts couple, is composed of a single element, \(\texttt{iStarts}=-1\)

• the following data are stored otherwise continuously in the appropriate \(\texttt{fElemSelectorXYData}\) array relative to this \(\texttt{iStarts}\) index

  • [0]: \(K:=\) number of discrte \(E_i, i=0,\ldots,K-1\) primary particle kinetic energy values used to compute and store the \(P(Z_j,E_i):=\Sigma^{Z_j}(E_i)/\Sigma(E_i)\) normalised, element-wise contributions to the macroscopic cross section of the material.

  • [1]: \(Q:=\) number of elements the given material is composed of. So above, \(Z_j, j=0,\ldots,Q-1\) at each individual \(E_i\) kinetic energy values. However, since \(P(Z_{j=Q-1},E_i)=\Sigma^{Z_{Q-1}}(E_i)/\Sigma(E_i) = 1\) for all \(i=0,\ldots,K-1\) due to the normalisation, data are computed and stored only for element indices of \(j=0,\ldots,Q-2\).

  • [2]: \(\log(E_0)\)

  • [3]: \(1/[log(E_{K-1}/E_0)/(K-1)]\)

  • [4 : 4 + QxK-1]: \(E_0,P(j=0,E_0),P(j=1,E_0),\ldots,P(j=Q-2,E_0), \ldots,\) \(E_{K-1},P(j=0,E_{K-1}),P(j=1,E_{K-1}),\ldots,P(j=Q-2,E_{K-1})\)

At run-time, when performing an interaction described by model \(XY \in \{\texttt{Ioni, BremSB, BremRB}\}\), with primary particle kinetic energy of \(E\) in the material, related to the material - cuts couple with the index of \(\texttt{imc}\),

• the start index of the corresponding element selector data is \(\texttt{iStarts}=\texttt{fElemSelectorXYStartIndexPerMatCut[imc]}\)

• the the corresonding \(\texttt{fElemSelectorXYData[iStart+2]}\) and \(\texttt{fElemSelectorXYData[iStart+3]}\) values can be used to compute the kinetic energy bin index \(i\) such that \( E_i \leq E < E_{i+1}, i=0,\ldots,\texttt{fElemSelectorXYData[iStart]}-1\).

• then the kinetic energies and normalised element-wise partial macroscopic cross sections, associated to the primary kinetic energies of \( E_i, E_{i+1}\) are used to perform the linear interpolation (smooth function) and and to sample the target element index from this discrete distribution.

Note

Note, that all the data, that are needed for the run-time interpolation and for the target element index sampling are stored next to each other in the memory. The implementations of the individual interaction models, that utilise these data for the run-time target atom selection (if needed), make sure that this memory layout is maximally exploited. These ensure the optimal performance, both in terms of memory consumption and speed, when accessing these data performing the correspondign \(e^-/e^+\) interactions.

int fElemSelectorIoniNumData = 0

Total number of element selector data for the Moller-Bhabha model for e-/e+ ionisation.

int *fElemSelectorIoniStartIndexPerMatCut = nullptr

Indices, at which data starts for a given material - cuts couple.

double *fElemSelectorIoniData = nullptr

Element selector data for all material - cuts couples with multiple element material.

int fElemSelectorBremSBNumData = 0

Total number of element selector data for the Seltzer-Berger model for e-/e+ bremsstrahlung.

int *fElemSelectorBremSBStartIndexPerMatCut = nullptr

Indices, at which data starts for a given material - cuts couple.

double *fElemSelectorBremSBData = nullptr

Element selector data for all material - cuts couples with multiple element material.

int fElemSelectorBremRBNumData = 0

Total number of element selector data for the relativistic (improved Bethe-Heitler) model for e-/e+ bremsstrahlung.

int *fElemSelectorBremRBStartIndexPerMatCut = nullptr

Indices, at which data starts for a given material - cuts couple.

double *fElemSelectorBremRBData = nullptr

Element selector data for all material - cuts couples with multiple element material.

Public Members

int fNumMatCuts = 0

Number of G4HepEm material - cuts: number of G4HepEmMCCData structures stored in the G4HepEmMatCutData::fMatCutData array.

int fNumMaterials = 0

Number of G4HepEm material : number of G4HepEmMatData structures stored in the G4HepEmMaterialData::fMaterialData array.

void AllocateElectronData(struct G4HepEmElectronData **theElectronData)

Allocates and pre-initialises the G4HepEmElectronData structure.

This method is invoked from the InitElectronData() function declared in the G4HepEmElectronInit header file. The input argument address of the G4HepEmElectronData structure pointer is the one stored in the G4HepEmData member of the master G4HepEmRunManager and the initialisation should be done by the master G4HepEmRunManager by invoking the InitElectronData() function for \(e^-/e^+\) particles.

Parameters:

theElectronData – address of a G4HepEmElectronData structure pointer. At termination, the correspondig pointer will be set to a memory location with a freshly allocated G4HepEmElectronData structure with all its pointer members set to nullprt. If the input pointer was not null at input, the pointed memory, including all dynamic memory members, is freed before the new allocation.

void FreeElectronData(struct G4HepEmElectronData **theElectronData)

Frees a G4HepEmElectronData structure.

This function deallocates all dynamically allocated memory stored in the input argument related G4HepEmElectronData structure, deallocates the structure itself and sets the input address to store a pointer to null. This makes the corresponding input stucture cleared, freed and ready to be re-initialised. The input argument is supposed to be the address of the corresponding pointer member of the G4HepEmData member of the master G4HepEmRunManager.

Parameters:

theElectronData – memory address that stores pointer to a G4HepEmElectronData structure. The memory is freed and the input address will store a null pointer at termination.

Warning

doxygenstruct: Cannot find class “G4HepEmElectronDataOnDevice” in doxygen xml output for project “The G4HepEm R&D project” from directory: ../doxygen/xml

void CopyElectronDataToDevice(struct G4HepEmElectronData *onHOST, struct G4HepEmElectronData **onDEVICE)

Allocates memory for and copies the G4HepEmElectronData structure from the host to the device.

The input arguments are supposed to be the corresponding members of the G4HepEmData, top level data structure, stored in the master G4HepEmRunManager.

Parameters:

• onHOST – pointer to the host side, already initialised G4HepEmElectronData structure.

• onDEVICE – host side address of a pointer to a device side G4HepEmElectronData structure. The pointed device side memory is cleaned (if not null at input) and points to the device side memory at termination containing all the copied G4HepEmElectronData structure members.

void FreeElectronDataOnDevice(struct G4HepEmElectronData **onDEVICE)

Frees all memory related to the device side G4HepEmElectronData structure referred by the pointer stored on the host side input argument address.

Parameters:

onDEVICE – host side address of a G4HepEmElectronDataOnDevice structure located on the device side memory. The correspondig device memory will be freed and the input argument address will be set to null.

…

The G4HepEmData data structure

Describe this in a nutshell

Code documentation

struct G4HepEmData

The top level, global data structure i.e. collection of global data structures used by all physics interactions covered by G4HepEm.

Author

M. Novak

Date

2020

There supposed to be a single instance of this data structure constructed and stored by the master G4HepEmRunManager. That single instance is constructed when calling the G4HepEmRunManager::InitializeGlobal() method wehn invoking the master G4HepEmRunManager::Initialize() method. Worker G4HepEmRunManager-s will have their pointer set to this master run-manager G4HepEmData member object.

Members of this data structure, represented by their pointers, are created individualy by invoking the dedicated intialisation methods one-by-one.

In case of CUDA build, the members, suffixed by _gpu, points do device memory locations where the corresponding data structures are located (after copying them). All the corresponding members can be (deep) copied from the host to device by calling the CopyG4HepEmDataToGPU() function. This will invoke the dedicated copy methods provided by the individual data structures.

The dynamically allocated memory, represented by all the members of this collection (including device side memeory as well in case of CUDA build), can be cleaned by calling the FreeG4HepEmData() function. This is done, in the G4HepEmRunManager::Clear() method.

Public Members

struct G4HepEmMatCutData *fTheMatCutData = nullptr

Global G4HepEmMatCutData i.e.

material and scondary production threshold related data.

struct G4HepEmMaterialData *fTheMaterialData = nullptr

Global material and scondary production threshold related data.

void InitG4HepEmData(struct G4HepEmData *theHepEmData)

Function that …

void FreeG4HepEmData(struct G4HepEmData *theHepEmData)

Function that …

void CopyG4HepEmDataToGPU(struct G4HepEmData *onCPU)

Function that …

void FreeG4HepEmDataOnGPU(struct G4HepEmData *onCPU)

Function that …