GitLab service scheduled maintenance on Friday, March 21st 2025 as of 08h00 Geneva time for an estimated period of 1 hour. Further information under OTG0154918.
This MR extend the new Jet config and implements a way of defining standard jet container and their components. The changes here do not affect standard reco yet : the new config is being developed in parallel to the existing config. The developments are not done yet but we think what we have at this stage is worth to be merge so we can progress and share development easily.
Text below was intended for the WIP discussion. I leave it here for reference.
First in order to properly implement option1, I had to significantly change the new JetRecConfig.
From TJ's code and comments I think/hope it's not too far from the devels he envisaged.
Mainly I added classes to describe all the components of a full jet definition. Beside the existing JetDefinition and JetModifier I added
JetInputDef, JetContitModifier and JetConstitSeq (the latter in place of JetConstit), see the docstring for more details about the intent of each.
I've also tried to move all the logic specialized to certain type of inputs or modifier out of the internal helper functions and into the above definiton classes. The idea is the helper function are as generic as possible and does no "hidden" decision based on some particular input/modifier. And so to understand how a modifier/input is configured there is only 1 place to read : its declaration.
As a consequence the resolution dependency solving was changed. Intead there is now a function (instantiateAliases) that starts from a JetDefinition, and translate all the aliases it contains (aliases to modifiers or inputs or ghosts) into proper instance of JetInputDef, JetModifier, etc... It then recursively translate the aliases contained in the modifiers, inputs & ghosts. At the same time it builds the ordered list of dependencies and a map of all the instances related to this JetDefinition`.
Then the helper functions in charge of instantiating the actual Athena tools are called. Those are in essence the same, but needed some technical adaptations so I've named the new ones with a '2' suffix (just so it's still possible to compare with the original).
(Some other details such as attribute names or PseudoJet container name have changed, usually for no bigger reasons than doing/undoing cycles during development)
Each modifier and input config now has a filterfn attribute : a function taking a ConfigFlag and telling if the modifier/input is compatible with the comditions (default function returns always True)
Before instantiating the final athena tools of a jetdef, all the filterfnof its modifier/inputs are called. If one fail, an exception is raised.
But if the jetdef as its attribute standardRecoMode==True (default false) then instead of an exception, the modifier/input is removed. The removal is logged with the reason of the removal (actually filterfn is expected to return (bool, string_describing_failure) ).
That way the standard jet definition contains directly the maximal list of modifier we want to run. And the condition for a modifier to be run or not is directly attached to this modifier.
In the current MR the machinery is in place and the only example is the JetDefInput "JetInputTruthParticles".
Sorry this MR is big. I'm happy to read comment about the 2 parts, modify and/or remove any of them. Of course there's are many technical and organisationnal details which can be improved. I wanted to quickly have a functional implementation ready.
Cheers, P-A
tagging experts for their review : @khoo @wbalunas @sawyer @sschramm @cdelitzs