Overview of Columnar Infrastructure

The general design of the columnar infrastructure is that it provides an abstract interface for accessing event data that can be switched at compile time to different environments and memory models. If you are familiar with the dual-use tool design, this is similar, but instead of relying on the preprocessor the core classes are all implemented as templates, and the switch happens via an implicit template parameter (Columnar Mode or CM for short).

The individual classes in the infrastructure track closely what the corresponding xAOD classes do. There are some deviations since some things are not possible in columnar, or need to be done slightly differently, but for the most part we try to stay close. Among other things this makes it a lot simpler to migrate existing tools to columnar.

If you are more familiar with writing columnar kernels, things will likely seem a bit off, but in general all classes have some direct equivalent in columnar code. One of the big changes is that we need to go from a push model for data access to a pull model, i.e. we don't pass individual columns into the tool, but access them via accessors. How that works will become a lot clearer as we go through the individual classes.

As you write your tool code you should for the most part be fine to think about it in either way, i.e. either like it was regular xAOD code (just wrapped) or like it was a columnar kernel. You normally don't have to constantly think about how it would work in the other mode, as long as you stay within the limitations that come from supporting all modes.

Columnar Mode Selection

The primary way to select the columnar mode to use (xAOD vs columnar) is by setting up the ColumnarAnalysis project via asetup. This is based on AnalysisBase, but is switched to columnar mode. It is currently (Nov 25) not run as part of the CI, nor do we build releases for it yet, but you can set up a nightly build and work with that.

If you want to set it manually you can change the CMake variable COLUMNAR_MODE_DEFAULT to a number corresponding to the columnar mode defined in the prototype. This will then in turn update the ColumnarModeDefault to point to the right columnar mode. Then you have to recompile all the packages relying on the columnar infrastructure with that new definition. I generally advocate against doing this, if you can avoid it.