celeritas-project
Implement framework for optical physics models
This is an initial implementation of optical models and their associated data structures.
General overview:
OpticalModel: acts like both a process (building cross sections / mean free paths) and as a model (action to run the interactor).ImportedOpticalMaterials: physics data for optical models is really just optical material properties. This serves as a list of imported optical material data that models will access directly to get their physics data.OpticalModelBuilder: constructs theImportedOpticalMaterialsand is responsible for building the appropriate models based on the user's selection.OpticalPhysicsParams: responsible for building each optical model, adding them to the action registry, and building their MFP grids inOpticalPhysicsParamsData.OpticalMfpBuilder: A helper class to have optical models build MFP grids on a per optical material basis.AbsorptionModel: An almost trivial optical model. Has no data and just kills the track when called.RayleighModel: A more complex optical model. Included to make sure API for building model-specific data is sensible.
This PR isn't merge ready yet, and is meant to be a discussion point for how we want to organize optical models. Some functions and classes are empty, and I'm in the middle of adding tests.
Thoughts / discussion questions:
- May be better to have something like this in
ImportData:
std::unordered_map<GeoMatIdx, ImportOpticalMaterialId> geo_optical_map;
std::vector<ImportOpticalMaterial> optical_materials;
- Will we want an
OpticalMaterialParams? Is there ever a point where we need to processImportOpticalMaterials and store the data outside of optical model specific data collections? - How much flexibility do we want to give to user defined optical models? Should we have an
ImportOpticalModelstructure? A lambda table inImportOpticalModelwould duplicate the mean free paths inImportOpticalMaterial... OpticalMfpBuilderis a bit awkward. There should be a better way to do this that is also portable to Cerenkov and scintillation parameter building.
Does this supersede #1162 ?
Yes, I'll close that one. I reused any relevant code but had to make enough major changes I thought it was worthwhile to start from a fresh branch.
Sorry it's taken some time to go through this: this looks really solid; I think you've got basically all the skeleton there! I've got a thought or two about simplifying some aspects to accelerate the time it takes for us to flesh this out... perhaps the first PR could be just the interactors for rayleigh and absorption; so that way we can unit test them and make sure the initial
OpticalInteractionclass is good enough. (You know, we might even be able to leave out code like the secondary stack until later, just to keep things simple.) But I think virtually all of this code will eventually end up in the final version almost unchanged 😄
I believe @whokion has some preliminary interactors implemented. The absorption interactor is trivial (just returns an absorbed state -- might be fine with just an executor) and doesn't need to be super rigorously tested. Rayleigh is non-trivial, but hopefully I got enough code in here to draft what setting up its data and model would look like. I'll discuss getting another PR up for just the interactions and tests over slack.
I can add OpticalRayInteractor (which I already have) once we decide how to build required optical data for the interactor - I was using OpticalRaylieghParams class, which can be absorbed to OpticalPhysicsParams or can be added too if we decide to have a separated data Params class for each model. Let's have a consensus first how we support optical material properties.
@whokion I think the optical rayleigh model should have its own data independent of the physics. I assume it's not needed by the other models?
@sethrj Yes, the Rayleigh data is independent from other models - actually, there is no required optical data for the OpticalRayleigh interactor if all mfp are taken care by the OpticalPhysicsParams class. It was not clear to me whether each model is responsible to import its own mfp along with other properties or OpticalPhysicsParams manages all mfp.
The plan is for the models to provide the MFP at setup time (usually by just processing the imported optical data) for the "optical physics" to manage all together at runtime.