CP Algorithms Introduction

The CP Algorithms are a common framework ATLAS provides for configuring and applying the CP recommendations. It is built as a layer on top of the CP Tools that were introduced during LS1 for applying the CP recommendations. In Run 2 it was expected of users or groups to develop their own analysis frameworks based on the CP Tools, to fulfill a similar role. However, the Run 2 experience showed a number of issues with this approach, which then lead to the development of the CP Algorithms to replace that approach.

For a hands-on introduction, see the CP Algorithms Tutorial.

The fundamental issue is that while using individual CP Tools is very straightforward, assembling the full suite of CP Tools into an overall framework is non-trivial. That lead to issues with getting different analysis frameworks at times not agreeing with each other, or (at times) even doing something incorrect. So just for analysis harmonization it was deemed necessary to have a common framework. Beyond that replacing individual frameworks with a common one is also expected to free up manpower for other purposes.

Since the CP Algorithms are meant to be used throughout ATLAS, they have a lot of flexibility in terms of the configurations they support, particularly when compared to some of the Run 2 frameworks, which at times had trouble turning off specific aspects or running multiple configurations at once. They are also meant to be about as efficient as they can be (within the paradigm), particularly they are meant to handle systematics efficiently and not include superfluous systematics branches in the output n-tuple.

Note that there are some analysis frameworks build on top of the CP Algorithms:

• TopCPToolKit
• easyjet

These can differ in how some of the higher-level functionality is presented, but for a lot of the core functionality this documentation will still apply. And importantly they should all produce the same physics output for the same configuration. And they may provide valuable functionality on top, e.g. the TopCPToolKit provides extra top specific algorithms that don't exist in central code (yet).

Use Cases

The primary use case for the CP Algorithms is to take a user configuration (in form of a YAML file) and produce an output n-tuple (in a mostly standardized format). The configuration is meant to be "physics near" and shouldn't require users to understand the underlying implementation. Top level scripts are provided to allow running such scripts without writing a custom EventLoop or Athena wrapper.

While YAML is the primary and preferred configuration format, there is also the option to configure the CP Algorithms from python, with both mechanisms interfacing with the same underlying configuration mechanism. This is primarily meant for running the CP Algorithms as part of larger Athena jobs (e.g. Derivations) which are configured from python.

While n-tuples are the expected output for most users, there is also the option to use the CP Algorithms to populate the event store with the output information. The prime example use case for this is in the derivations which use the CP Algorithms for calculating the variables in PHYSLITE.

Users are able to extend the CP Algorithms by implementing their own custom algorithms, together with the associated custom configuration blocks.

In the future it is expected that the CP Algorithm configuration will also be shared with columnar environments to allow having a shared physics configuration between all environments.

Implementation Design

The CP Algorithms are designed to run as a sequence of Athena/EventLoop algorithms (hence the name). This is meant to make it very easy to add/remove specific tools as needed, as well as running the same tool multiple times in different configurations (e.g. tight and loose, or using different calibration settings).

The configuration happens via the so called Configuration Blocks, with each block corresponding to one section in the configuration file as well as an atomic sequence of algorithms (e.g. calibrating one physics object). The blocks interface with the environment and each other via the ConfigAccumulator (not to be confused with the ComponentAccumulator).