Project

General

Profile

Support #13560

Replace LArG4Parameters service with a data product

Added by Gianluca Petrillo about 3 years ago. Updated 8 months ago.

Status:
Resolved
Priority:
Normal
Category:
Simulation
Target version:
Start date:
08/15/2016
Due date:
% Done:

100%

Estimated time:
Spent time:
Experiment:
LArSoft
Co-Assignees:
Duration:

Description

The LArG4Parameters service seems to be designed to inform other modules and services of the configuration that was used for LArG4 module.
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 LArG4 job.
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).


Related issues

Related to LArSoft - Milestone #14454: Refactoring LArG4 Resolved06/15/201609/05/2017

History

#1 Updated by Katherine Lato about 3 years ago

  • Status changed from New to Feedback

Need to investigate users of this service.

#2 Updated by Katherine Lato over 2 years ago

#3 Updated by Katherine Lato over 2 years ago

  • Status changed from Feedback to Accepted
  • Target version set to 2017-3-quarter

#4 Updated by Katherine Lato over 2 years ago

  • Status changed from Accepted to Assigned
  • Assignee set to Hans-Joachim Wenzel

#5 Updated by Hans-Joachim Wenzel 9 months ago

  • % Done changed from 0 to 100

#6 Updated by Hans-Joachim Wenzel 9 months ago

  • Status changed from Assigned to Resolved

#7 Updated by Hans-Joachim Wenzel 9 months 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 standard_physicslist.fcl)
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)

#8 Updated by Gianluca Petrillo 8 months ago

I have some trouble finding the relevant code in CheckDRCalorimeterHits module. Could you be explicit about where that code is in the class?

#9 Updated by Hans-Joachim Wenzel 8 months ago

my bad I never pushed it to the main repository. I have created a feature branch:

feature/wenzel_parsets

which contains the modified files:

artg4tk/Analysis/CheckDRCalorimeterHits_module.cc
artg4tk/Analysis/CheckDRCalorimeterHits_module.hh

/examples/CMakeLists.txt
examples/eic_calo.fcl

It was added to the release in the second week of January 2019.



Also available in: Atom PDF