Replace LArG4Parameters service with a data product
LArG4Parameters service seems to be designed to inform other modules and services of the configuration that was used for
This would be better implemented with a data product written by
LArG4 (either as a event or result data product).
The current implementation is error-prone because the configuration of the service on a subsequent run might be accidentally different from the one in the original
It also goes close to violate the protocol that prescribes modules nor communicating except via data products.
An alternative implementation, that is reading
LArG4 configuration from the configuration database in the art ROOT file, is less flexible because it does not allow the presence of additional information that the module might want to add, and it does not provide the configuration values assigned by default.
It should be checked if there are cases where the service can be used without LArG4 having ever been executed, though (e.g. event display).
#7 Updated by Hans-Joachim Wenzel about 2 years ago
The Larg4Parameter service is really an odd construct and doesn't represent good practices. It was used to communicate parameter values used in larg4 between different components of the old larg4.
First the new larg4 only deals with the Geant4 simulation. Things that don't belong there (e.g. electron drift to readout plane etc.) moved into their own modules/repositories. So overall there are much fewer parameters in the new larg4 to take care of and the parameter sets now would belong to complete different modules (we don't want to create many parameter services).
Second there already seems to be a well established pattern that demonstrates how to access the value of a parameter/parameter set used in a different module/service. I would argue that we should use the pattern throughout instead of having a special solution in larg4. To demonstrate the pattern I have created an example in artg4tk. Say I want to access the name of the Geant 4 reference list that was used to configure the physics list when I analyze the Geant4 hits in an analyzer module. The physics list is constructed in the artg4tk:source:artg4tk/pluginActions/physicsList/PhysicsList_service.cc with one of the parameters being the name of the reference physics list.
The example consists of:
artg4tk:source:artg4tk/fcl/standard_physicslist.fcl: the file contains all the parameters used to define the physics configuration
artg4tk:source:artg4tk/examples/eic_calo.fcl : includes
standard_physicslist.fcl is running the example and showing how to get access to the parameter set of the physics list service (as contained in
artg4tk:source:artg4tk/Analysis/CheckDRCalorimeterHits_module.cc and artg4tk:source:artg4tk/Analysis/CheckDRCalorimeterHits_module.hh: show how to access and print out the value of PhysicsList extracting it from the parameter set that was used to configure the physics.
By default the values are persistent e.g. all fcl files are maintained in the git repository. The all fcl file itself is stored in the event and the values could be extracted (with some effort)
#9 Updated by Hans-Joachim Wenzel almost 2 years ago
my bad I never pushed it to the main repository. I have created a feature branch:
which contains the modified files:
It was added to the release in the second week of January 2019.