Build Materials Dynamically as Needed

Currently in BDSMaterials, we build quite a selection of materials. A lot of the material definitions are old and include various optical parameters. With the evolving interface in Geant4, we can cause runtime exceptions from Geant4 if these are not implemented correctly, which will cause every test involving geometry to crash and fail. While we should ideally keep these up to date, we can also make things a little clearer and independent. I propose to change materials to a factory much like the design of BDSModularPhysicsList, where we have a map of acceptable material names to function pointers.

‌

std::map<G4String, std::pair<BDSMaterials::*, G4bool>> materials;
// name -> <funciton to construct that material, has been constructed or not>

This is one solution. But this would involve perhaps too many trivial functions. Other solutions:

Move the optical property materials into AWAKE module (just hiding the problem) - the materials are very useful for accelerators, so good to keep them.
Isolate only the complex optical materials into functions (mixed bag of design) - could fall back to dictionary of ‘complex’ materials to build. Requires tests for these (especially to not degrade code coverage).

‌

Comments (1)