This MR creates a separate
top-el executable that uses the EventLoop DirectDriver and almost all functionality in top-xaod is copied to TopxAODAlg algorithm. This should be considered as a first step, there's likely much more cleanup possible.
There are a handful of issues, for which I do not have an immediate solution:
- As mentioned in !46081 (closed), AnalysisTop relies on a single
TopConfigconfiguration class which is passed to pretty much every AnalysisTop-specific AsgTool. This does not really follow the philosophy of current ATLAS analysis code -- which to my understanding is more of a "each tool / algorithm is responsible for it's own configuration". The problem with this approach is that it makes it much harder for us to manage all user configuration from a single text file, if we have to set a bunch of stuff all over the codebase. My hope is that this is something the text-based CP algorithms configuration could solve by providing the interface that we could use and shift away from this singleton configuration style.
- Ideally for now, I wanted to create a single instance of the
TopConfigand pass them to the algorithm, but this seems messy, so I just create two instances, one in
top-el, and one in the algorithm itself. For the moment, we need access to the configuration in both places, since it impacts both job steering and algorithm-specific stuff.
- 90% of the metadata we now manage to read from
initialize()step of the
TopxAODlgalgorithm, this is nice. There is one remaining issue, which is that we currently need to determine the year of data-taking, primarily meant to ease trigger configuration for users, when triggers differ between years. Currently this is done by manually peeking into a file and reading
EventInfo. This again seems to be incompatible with EventLoop approach as-is -- one alternative that might be worth investigating is "ala SUSYTools", to parse the
AMITagfrom FileMetaData and have some dictionary to translate between r-tags and years of data-taking / MC campaign.
- There are some facilities in AnalysisTop such as counting sum of weights, the question is whether there is already an EventLoop-based infrastructure for this that we could re-use instead of maintaing our own in-house solution.
- Homework for me to examine the NTupling facilities in AnalysisBase -- perhaps we could greatly simplify the monstrously huge
EventSaverFlatNTupleclass, that does this job at the moment.