As a consequence of !63577 (merged) implementing the first iteration of ATR-27067, we realised (ATR-27796) that L1Calo PID thresholds not obeying a strict ordering in every eta bin can cause unintuitive behaviour. Notably, modifying only the Tight cut with reta being looser than Medium in specific eta bins resulted in L1CaloSim/FW differences leaking into the Medium definition:
- If an event passes
Tight, L1CaloSim concludes thatMediumis passed, hence looseningTightregionally caused count increases inMedium` - If an event fails
Medium, the FW would conclude thatTightis failed, hence candidates could failTightdespite passing the numerical thresholds -- opposite to what L1CaloSim would do
To avoid this, @watsona suggested to enforce that T >= M >= L is satisfied for each variable's working points in every eta bin when the thresholds are defined in the menu. This check fails as follows for the problematic cuts when running generateL1MenuRun3.py PhysicsP1_pp_run3_v1:
Py:TriggerMenuMT:TypeWideThresholdConfig ERROR Medium_reta_fw (92) > Tight_reta_fw (86) for eta bin -25
Traceback (most recent call last):
File "/lustre/fs22/group/atlas/tjkhoo/athena_dev/TMMT-alt/build/x86_64-centos7-gcc11-opt/bin/generateL1MenuRun3.py", line 44, in <module>
sys.exit( main() )
File "/lustre/fs22/group/atlas/tjkhoo/athena_dev/TMMT-alt/build/x86_64-centos7-gcc11-opt/bin/generateL1MenuRun3.py", line 39, in main
generateL1Menu(flags)
File "/cvmfs/atlas-nightlies.cern.ch/repo/sw/23.0_Athena_x86_64-centos7-gcc11-opt/2023-06-22T2101/Athena/23.0.34/InstallArea/x86_64-centos7-gcc11-opt/python/TrigConfigSvc/TrigConfigSvcCfg.py", line 200, in generateL1Menu
l1cfg = L1MenuConfig(
File "/lustre/fs22/group/atlas/tjkhoo/athena_dev/TMMT-alt/build/x86_64-centos7-gcc11-opt/python/TriggerMenuMT/L1/L1MenuConfig.py", line 73, in __init__
self._generate()
File "/lustre/fs22/group/atlas/tjkhoo/athena_dev/TMMT-alt/build/x86_64-centos7-gcc11-opt/python/TriggerMenuMT/L1/L1MenuConfig.py", line 90, in _generate
self._generateMenu()
File "/lustre/fs22/group/atlas/tjkhoo/athena_dev/TMMT-alt/build/x86_64-centos7-gcc11-opt/python/TriggerMenuMT/L1/L1MenuConfig.py", line 735, in _generateMenu
self.l1menu.checkPtMinToTopo()
File "/lustre/fs22/group/atlas/tjkhoo/athena_dev/TMMT-alt/build/x86_64-centos7-gcc11-opt/python/TriggerMenuMT/L1/Base/L1Menu.py", line 379, in checkPtMinToTopo
ttconfig = getTypeWideThresholdConfig(thrtype,self.do_HI_tob_thresholds)
File "/lustre/fs22/group/atlas/tjkhoo/athena_dev/TMMT-alt/build/x86_64-centos7-gcc11-opt/python/TriggerMenuMT/L1/Config/TypeWideThresholdConfig.py", line 92, in getTypeWideThresholdConfig
return getConfig_eEM()
File "/lustre/fs22/group/atlas/tjkhoo/athena_dev/TMMT-alt/build/x86_64-centos7-gcc11-opt/python/TriggerMenuMT/L1/Config/TypeWideThresholdConfig.py", line 268, in getConfig_eEM
validate_ordering(var,"Medium","Tight",confObj["workingPoints"])
File "/lustre/fs22/group/atlas/tjkhoo/athena_dev/TMMT-alt/build/x86_64-centos7-gcc11-opt/python/TriggerMenuMT/L1/Config/TypeWideThresholdConfig.py", line 64, in validate_ordering
assert leq_all_eta(_lesser,_greater), f"Working point ordering violated for {_lesser.name}, {_greater.name}"
AssertionError: Working point ordering violated for Medium_reta_fw, Tight_reta_fwThe check is preemptively implemented for jEM, jTAU, cTAU and eTAU as well.
The python check handles either both WPs being eta-dependent or both being eta-independent. Cross-comparisons could be implemented too, but as they are not currently necessary, such comparisons are identified as an error condition.
New eta-dependent eEM L,M,T cuts that satisfy the ordering principle were optimised by @thompson @hillier and are also included here.
The C++ implementation is done by defining comparison operators for the WorkingPoints_[thresholdtype] class, so that the enforcement check can in principle be applied to ValueWithEtaDependence<T> where T is a numerical type. This is chosen to evaluate as WP1 < WP2 if that holds for every value in all eta bins, which may not be entirely intuitive (in particular the behaviour of >, which is only true if this is satisfied in at least one eta bin, but < is satisfied in none) . Technically, only one (> or <) operator would need to be defined, but this would likely be more confusing. Note: this would have been much nicer in C++20 as it suffices only to overload <=>.
The keys used for the DoubleMenuLoad test referred to a L1 menu with eTAU cuts that did not obey the criteria above, so I have now switched this to check a recent ATN that predates !63577 (merged) (which would also fail). It hasn't been updated since !46711 (merged), so it doesn't hurt to have a more recent one. FYI @stelzer @mark in case either of you would prefer to choose different keys for whatever reason. We could generate the current menu and upload for these purposes, but I don't think it's all that necessary.
As pointed out by @mark, the C++ check on menu load is undesirable because it would break jobs that load older menus which violate the ordering.