Skip to content

CPAlgorithm: fix configuration bug in TriggerAnalysisSFConfig

Baptiste Ravina requested to merge ravinab/athena:fix_triggersf into main

A first issue was reported by @abhishek on the TopCPToolkit support Mattermost channel: running with the multiTriggerChainsPerYear option and two trigger configurations (e.g. DLT vs SLT) leads to

  File "/cvmfs/atlas.cern.ch/repo/sw/software/25.2/AnalysisBase/25.2.15/InstallArea/x86_64-el9-gcc13-opt/python/TriggerAnalysisAlgorithms/TriggerAnalysisSFConfig.py", line 172, in makeAlgs
    self.makeTriggerGlobalEffCorrAlg(config, matchingTool, self.noEffSF, suffix)
  File "/cvmfs/atlas.cern.ch/repo/sw/software/25.2/AnalysisBase/25.2.15/InstallArea/x86_64-el9-gcc13-opt/python/TriggerAnalysisAlgorithms/TriggerAnalysisSFConfig.py", line 100, in makeTriggerGlobalEffCorrAlg
    alg = config.createAlgorithm( 'CP::TrigGlobalEfficiencyAlg', 'TrigGlobalSFAlg' )
  File "/cvmfs/atlas.cern.ch/repo/sw/software/25.2/AnalysisBase/25.2.15/InstallArea/x86_64-el9-gcc13-opt/python/AnalysisAlgorithmsConfig/ConfigAccumulator.py", line 229, in createAlgorithm
    raise Exception ('duplicate algorithms: ' + name)

This is fixed in the first commit by making the name of the CP::TrigGlobalEfficiencyAlg depend on the trigger configuration.

The second issue is that an exception is raised on the second pass of the block config because self.triggerChainsPerYear is updated from an empty dictionary after the first pass, here. The second commit relaxes the condition for the exception to be raised.

Merge request reports