Physics definition

Celeritas contains several high-level “parameter” classes that allow setup-time access to problem data. These classes all correspond directly to “TrackView” classes (see the developer documentation for details).

Celeritas parameters

class MaterialParams : public celeritas::ParamsDataInterface<MaterialParamsData>

Manage material, element, and nuclide properties.

Materials in Celeritas currently correspond to “material cut couples” in Geant4, i.e. the outer product of geometry model-defined materials and user-defined physics regions.

Todo:

Replace id_to_label etc. with direct access to LabelIdMultiMap

Split into nuclide/element/geo material

class ParticleParams : public celeritas::ParamsDataInterface<ParticleParamsData>

Data management for Standard Model particle classifications.

This class represents “per-problem” shared data about standard model particles being used.

The ParticleParams is constructed on the host with a vector that combines metadata (used for debugging output and interfacing with physics setup) and data (used for on-device transport). Each entry in the construction is assigned a unique ParticleId used for runtime access. See celeritas::PDGNumber for details on the PDG code used during construction.

class PhysicsParams : public celeritas::ParamsDataInterface<PhysicsParamsData>

Manage physics processes and models.

The physics params takes a vector of processes and sets up the processes and models. It constructs data and mappings of data:

• particle type and process to tabulated values of cross sections etc,

• particle type to applicable processes

During construction it constructs models and their corresponding list of ActionId values, as well as the tables of cross section data. Besides the individual interaction kernels, the physics parameters manage additional actions:

• ”pre-step”: calculate physics step limits

• ”along-step”: propagate, apply energy loss, multiple scatter

• ”range”: limit step by energy loss

• ”discrete-select”: sample a process for a discrete interaction, or reject due to integral cross sectionl

• ”integral-rejected”: do not apply a discrete interaction

• ”failure”: interactor failed to allocate secondaries

class CutoffParams : public celeritas::ParamsDataInterface<CutoffParamsData>

Management particle and material cutoffs.

Geant4 provides accessors to its production cuts from its G4MaterialCutsCouple class, which couples cutoff and material data. During import, for simplicity, G4’s production cuts are stored alongside the material information, in ImportPhysMaterial . Since this is a direct import, the cutoff map in ImportPhysMaterial stores only the cuts available in Geant4, i.e. only values for gammas, electrons, positrons, and protons.

In Celeritas, particle cutoff is stored contiguously in a single vector of size num_particles * num_materials, which stores all particle cutoffs for all materials. During import, any particle that is not in Geant4’s list receives a zero cutoff value. This opens the possibility to expand cutoffs in the future, when data is not imported anymore.

The Input structure provides a failsafe mechanism to construct the host/device data.

Some processes (e.g. photoelectric effect, decay) can produce secondaries below the production threshold, while others (e.g. bremsstrahlung, ionization) use the production cut as their intrinsic limit. By default all of these secondaries are transported, even if their energy is below the threshold. If the apply_post_interaction option is enabled, any secondary photon, electron, or positron with energy below the cutoff will be killed (the flag will be ignored for other particle types).

Geant4 integration

The “physics” material ID in Celeritas is specified as a combination of the actual model-specified material, which is the “geometry” material ID (see Geometry), and the region.

Table 7 Celeritas physics IDs their analogous Geant4 classes.

Celeritas	Geant4
ParticleId	G4ParticleDefinition
PhysMatId	G4MaterialCutsCouple
OptMatId	G4MaterialPropertiesTable
PhysSurfId	G4OpticalSurface
ProcessId	G4VProcess

Setting up problems

Problem data is specified from applications and the Geant4 user interface using the Input API and loaded through “importers”. Currently, Celeritas relies on Geant4 and external Geant4 data files for its setup.

namespace setup

Configure a Celeritas problem from input data.

This implementation detail is how celeritas::inp data is used to construct all the main Celeritas objects.

Todo:

This will change to load data into a Problem, not ImportData. Currently we need to fill tables and base what gets loaded on the existing processes.

Functions

std::vector<std::vector<Primary>> events(inp::Events const &e, std::shared_ptr<ParticleParams const> const &particles)

Load events from a file.

FrameworkLoaded framework_input(inp::FrameworkInput &fi)

Completely set up a Celeritas problem from a framework input.

void physics_from(inp::PhysicsFromFile const &pff, ImportData &imported)

Load all physics data from a ROOT file.

void physics_from(inp::PhysicsFromGeant const &pfg, ImportData &imported)

Load from Geant4 in memory.

void physics_from(inp::PhysicsFromGeantFiles const &pfgf, ImportData &imported)

Load from Geant4 data files.

Based on what elements and processes are in the import data, this will load data from the input physics files.

ModelLoaded model(inp::Model const &m)

Load a core geometry model.

This is for unit tests and as an implementation detail of problem.

ProblemLoaded problem(inp::Problem const &p, ImportData const &imported)

Create “core params” from a problem definition and import data.

Conceivably we could rename “core params” someday.

Todo:

Consolidate import data into the problem definition.

Migrate the class “Input”/”Option” code into the class itself, using the inp namespace definition.

StandaloneLoaded standalone_input(inp::StandaloneInput &si)

Completely set up a Celeritas problem from a standalone input.

void system(inp::System const &sys)

Set up low level system properties.

For Celeritas runs, this should be set up before anything else.

struct FrameworkLoaded

Result from loaded standalone input to be used in front-end apps.

struct ModelLoaded

Result from loaded model input to be used in unit tests.

struct ProblemLoaded

Result from loaded standalone input to be used in front-end apps.

Temporary: to be used downstream

Todo:

These should be refactored: should be built in Problem

struct StandaloneLoaded

Result from loaded standalone input to be used in front-end apps.