Control¶
These options manage trade-offs between performance and memory usage, and other parameters that affect the simulation results without changing the physics.
-
struct Control
Set up control/tuning parameters that do not affect physics.
Defaults:
device_debug:
absent unless device is enabledoptical_capacity:
absent unless optical physics is enabledtrack_order:
init_charge
on GPU,none
on CPU
Public Members
-
CoreStateCapacity capacity
Per-process state sizes.
-
std::optional<OpticalStateCapacity> optical_capacity
Per-process state sizes for optical tracking loop.
-
size_type num_streams = {}
Number of streams.
-
std::optional<TrackOrder> track_order
Track sorting and initialization.
-
std::optional<DeviceDebug> device_debug
Debug options for device.
-
bool warm_up = {false}
Perform a no-op step at the beginning to improve timing measurements.
-
unsigned int seed = {}
Random number generator seed.
-
struct DeviceDebug
When using GPU, change execution options that make it easier to debug.
Defaults:
sync_stream:
false
unlesstimers.diagnostics.action
istrue
.
Public Members
-
std::optional<bool> sync_stream
Synchronize the stream after every kernel launch.
-
struct StateCapacity
Set up per-process state/buffer capacities.
Increasing these values increases resource requirements with the trade-off of (usually!) improving performance. A larger number of
tracks
in flight means improved performance on GPU because the standard kernel size increases, but it also means higher memory usage because of the larger number of full states. Moreinitializers
are necessary for more (and higher-energy) tracks when lots of particles are in flight and producing new child particles. Moresecondaries
may be necessary if physical processes that produce many daughters (e.g., atomic relaxation or Bertini cascade) are active. The number ofevents
in flight primarily increases the number of active tracks, possible initializers, and produced secondaries (NOTE: see #1233 ). Finally, the number ofprimaries
is the maximum number of pending tracks from an external application before running a kernel to constructinitializers
and execute the stpeping loop.Capacities are defined as the number per application process (task): this means that in a multithreaded context it implies “strong scaling” (i.e., the allocations are divided among threads), and in a multiprocess context it implies “weak scaling” (the problem size grows with the number of processes). In other words, if used in a multithread “event-parallel” context, each state gets the specified
tracks
divided by the number of threads. When used in MPI parallel (e.g., one process per GPU), each process rank hastracks
total threads.- Todo:
Some of these parameters will be more automated in the future.
Note
The
primaries
was previously namedauto_flush
.Note
Previously,
SetupOptions
andceler-g4
treated these quantities as “per stream” whereasceler-sim
used “per process”.Subclassed by celeritas::inp::CoreStateCapacity, celeritas::inp::OpticalStateCapacity
-
struct CoreStateCapacity : public celeritas::inp::StateCapacity
Set up per-process state/buffer capacities for the main tracking loop.
Defaults:
secondaries:
twice the number of track slotsevents:
single event runs at a time
Note
The
primaries
was previously namedauto_flush
.Note
Previously,
SetupOptions
andceler-g4
treated these quantities as “per stream” whereasceler-sim
used “per process”.
-
struct OpticalStateCapacity : public celeritas::inp::StateCapacity
Set up per-process state/buffer capacities for the optical tracking loop.
Note
generators
was previously namedbuffer_capacity
.Public Members
-
size_type generators = {}
Maximum number of queued photon-generating steps.
-
size_type generators = {}