Removing compile-time dependencies from Physics Lists

1. Removing compile-time dependencies from Physics Lists Witek Pokorski 08.10.2012

2. Problem and goal • physics lists include header files of physics constructors: #include "G4EmExtraPhysics.hh” and instantiate them explicitly: this->RegisterPhysics( new G4EmExtraPhysics(ver) ); • class G4PhysListFactory (which is not a factory in design patters language) includes the physics list headers #include "QGSP_BERT.hh" and therefore depends on physics constructors • making some models (CHIPS, LHEP) and its physics constructors optional would require putting #ifdefs in the physics lists • we would need to remove the header files of the physics constructors that are not built • goal: remove compile-time dependencies between physics lists and physics constructors (and therefore physics models)

3. Approach • introduce registry of physics constructors (like it was done for the cross sections) • instrument physics constructors to provide factories that get registered in the registry • replace the explicit instantiation of physics constructors (and therefore the need to have header files) in physics lists by calls to the registry giving the name of the physics constructor (string) as argument • as a possible option, provide a ‘generic physics list’ which is configured (physics constructors, cuts, etc) from a macro file

4. Implementation • implemented (in physics_lists/lists) class G4PhysicsConstructorRegistry • methods used in client code static G4PhysicsConstructorRegistry* Instance(); G4VPhysicsConstructor* GetPhysicsConstructor(const G4String& name); • provided G4PhysicsConstructorFactory.hh containing templated factory to instrument the physics constructors

5. Needed Physics Constructors classes modification • two lines added in the .cc file #include "G4PhysicsConstructorFactory.hh” G4_DECLARE_PHYSCONSTR_FACTORY(G4EmStandardPhysics); • that’s all • 100% backward compatible

6. How to use it in clients code in FTFP_BERT.icc • #include "G4PhysicsConstructorRegistry.hh” • and one can remove all includes of physics constructors like #include "G4EmStandardPhysics.hh” • this->RegisterPhysics(G4PhysicsConstructorRegistry::Instance()->GetPhysicsConstructor("G4EmStandardPhysics")); • resulting physics list do not have compile time dependencies on particular physics constructors • physics lists do not create compile-time binding between different models • physics list can be compile without the models • if we try to use a physics list for which the models are missing, we will get an exception saying “... physics constructor missing”

7. Going further • implemented GenericPhysicsListclass which comes with no physics constructors but with: • UI commands to register ‘physics’ • constructor taking vector<string> as argument, containing list of ‘physics’

8. Using GenericPhysicsList 1/3 • FTFP_BERT.mac: /PhysicsList/defaultCutValue 0.7 /PhysicsList/SetVerboseLevel 1 /PhysicsList/RegisterPhysics G4EmStandardPhysics /PhysicsList/RegisterPhysics G4EmExtraBertiniPhysics /PhysicsList/RegisterPhysics G4DecayPhysics /PhysicsList/RegisterPhysics G4HadronElasticPhysics /PhysicsList/RegisterPhysicsHadronPhysicsFTFP_BERT /PhysicsList/RegisterPhysics G4BertiniAndFritiofStoppingPhysics /PhysicsList/RegisterPhysics G4IonFTFPBinaryCascadePhysics /PhysicsList/RegisterPhysicsG4NeutronTrackingCut • in the main() phys= new GenericPhysicsList(); G4UImanager* UImanager = G4UImanager::GetUIpointer(); UImanager->ApplyCommand("/control/execute FTFP_BERT.mac"); runManager->SetUserInitialization(phys);

9. Using GenericPhysicsList2/3 • create vector<string> MyPhysicsConstructors containing names of the physics constructor • instatiate generic physics list new GenericPhysicsList(MyPhysicsConstructors) • where this constructor iterates over the physics constructors names and registers them

10. Using GenericPhysicsList3/3 • one can also mimic exactly the current situation, i.e. to have ‘pre-cooked’ (like now) physics list inheriting from GenericPhysicsList (combining the two steps described on previous slide) FTFP_BERT::GenericPhysicsList(MyPhysicsConstructors) • so then you can do • new FTFP_BERT like now

11. One issue... • static builds are a problem with the factory machinery • object are not referenced to, so symbols are dropped from the executable • there are solutions • add ‘dummy’ references to the factories to pull the symbols in • use ‘-allarchive’ linker option to have all the symbols (from the builders in) • to make it easier, physics constructors that are in ‘lists’ should be moved to ‘builders’ directory • request to Ben M. to provide a flag that identifies static build during the compile time • and we need to investigate the use of –allarchive for physics builders

12. Conclusion • introduction of the registry and providing factory mechanism for physics constructors allowed to remove compile-time dependencies of physics list on physics models • makes it possible to ‘switch off’ some models (not even check them out from SVN) • generic physics list allows to use macros for configuration • adds a lot of flexibility • can also provide ‘pre-cooked’ physics lists like before • all those developments are 100% backwards compatible and do not require any change in the users code • started instrumenting the physics constructors (FTFP_BERT ones done) • generic physics list committed and tagged • for the moment works only with dynamic libraries