Celeritas is a new Monte Carlo transport code designed to accelerate scientific discovery in high energy physics by improving detector simulation throughput and energy efficiency using GPUs.
Added ImportedMaterials to act as a common storage for material data used by optical models (Rayleigh and WLS). Like with ImportedModels it helps prevent unnecessary copies of std::vector<ImportOpticalRayleigh> and std::vector<ImportWavelengthShift>.
RayleighModel was also updated to use an Input struct to concisely manage material dependencies for building MFP tables.
Model Importer
Similar to phys/ProcessBuilder, I added the ModelImporter to create models from imported data, as well as provide user build functionality like warn-and-ignore. The ModelBuilder concrete base class is meant to serve a similar purpose to phys/Process, and is just meant to build optical models with an action ID.
I'm trying to maintain the behavior of phys/PhysicsParams where importing processes/models is separate from being built and registered in the action registry, so a layer between ModelImporter and optical/PhysicsParams is necessary. The input for optical::PhysicsParams will look something like:
Simple builders are added to the model .cpp files and made accessible through static factory methods. There's some freedom in
determining where the builders live (or even using some type-erased lambdas if we want to be fancy).
N.B.: This loosely depends on #1519 so I'm leaving this as a draft PR, but can be more or less independently reviewed.
Refactoring imported optical materials
Added
ImportedMaterials
to act as a common storage for material data used by optical models (Rayleigh and WLS). Like withImportedModels
it helps prevent unnecessary copies ofstd::vector<ImportOpticalRayleigh>
andstd::vector<ImportWavelengthShift>
.RayleighModel
was also updated to use anInput
struct to concisely manage material dependencies for building MFP tables.Model Importer
Similar to
phys/ProcessBuilder
, I added theModelImporter
to create models from imported data, as well as provide user build functionality like warn-and-ignore. TheModelBuilder
concrete base class is meant to serve a similar purpose tophys/Process
, and is just meant to build optical models with an action ID.I'm trying to maintain the behavior of
phys/PhysicsParams
where importing processes/models is separate from being built and registered in the action registry, so a layer betweenModelImporter
andoptical/PhysicsParams
is necessary. The input foroptical::PhysicsParams
will look something like:Simple builders are added to the model .cpp files and made accessible through static factory methods. There's some freedom in determining where the builders live (or even using some type-erased lambdas if we want to be fancy).
N.B.: This loosely depends on #1519 so I'm leaving this as a draft PR, but can be more or less independently reviewed.