FCL file parameters not properly tracked
We've come across a case where the input fcl file parameters are not properly tracked.
The file used to run the job is attached as original_fcl.fcl. There are a number of includes, but the key part is the services.user.TriggerAlgoMicroBoone parameter, which is set up and then has some default parameters overwritten.
We can run with $ART_DEBUG_CONFIG=1, and get the debug_config.fcl file attached. TriggerAlgoMicroBoone is in that file.
But, after running the job, running "config_dumper" on the output file produces the config_dump.fcl file, which has no TriggerAlgoMicroBoone in it. We do know that this parameter is being read in and used, as we spent some time debugging an issue where we uncovered a difference in the parameter values used which caused the job to run differently.
#1 Updated by Christopher Green over 5 years ago
- Tracker changed from Bug to Feature
- Category set to Application
- Status changed from New to Resolved
- Target version set to 1.09.03
- % Done changed from 0 to 100
- SSI Package art added
- SSI Package deleted (
The original (admittedly not comprehensive) feature set of
config_dumper only prints out module configurations. In the upcoming release, this functionality has been extended to print out entire parameter sets, module configurations or service configurations. Please see the original issue #3639 for details.