a namespace for holding the ids for the different "virtual" containers More...

Classes
struct	cluster

struct	egamma

struct	electron

struct	eventContext
	a template to define a mutable version of a given container id More...

struct	eventInfo

struct	jet

struct	met

struct	met1

struct	metAssociation

struct	muon

struct	particle

struct	particle1

struct	photon

struct	regularCIBase
	a template that provides a base definition of container id for a regular container More...

struct	track

struct	track1

struct	track2

struct	vertex

Typedefs
using	particle0 = particle

using	mutableEgamma = mutableCI< egamma >

using	mutableJet = mutableCI< jet >

using	met0 = met

using	mutableMet = mutableCI< met >

using	track0 = track

Detailed Description

a namespace for holding the ids for the different "virtual" containers

This is a namespace that holds the container ids for the different "virtual" containers. The individual container ids are represented by structs that describe each container. The user should not be trying to create instances of these structs, but rather use them as identifiers to pass into various columnar templates.

To first order there is one container id for each xAOD type, and there is a direct mapping from container id to xAOD type. And for your code to compile in xAOD mode, your objects will be represented by a pointer to the underlying xAOD type. So to make your code compile in xAOD mode, you need to use the container id that corresponds to the xAOD type you want to use.

In the columnar world we don't really have objects like that, and the container ids are mostly arbitrary (objects in columnar mode are usually represented by integers). However, there are still columns that belong together, share an offset map, and have a common prefix to their names. These columns form a "virtual container" and the container id is used to identify that virtual container.

One important difference between xAOD types and container ids is that a container id is referring to a single container of a type. If you have e.g. two JetContainer instances in your tool, you need to use two different container ids for them. That is because in the columnar world the virtual containers come with completely separate columns, have separate offset maps, etc.

A given container id also only has a meaning within the context of one specific tool instance. If you have multiple instances of a tool they may be connected to different containers/columns each. If a tool has subtools they need to coordinate their container ids as well, making subtools a lot more tightly connected than in the xAOD world.

By default all referenced xAOD objects are const-qualified, as most tools will anyways work on const-qualified objects. In case your tool needs a non-const version of an object there is usually a "mutable" version of the container id available, which gives access to a mutable xAOD object and can be used wherever the corresponding const-qualified container id can be used, i.e. it doesn't introduce a separate container, but a different version of the same container.

Most classes in the columnar infrastructure are templates that take the container id as a template parameter. In part this is to use the correct type in xAOD mode, but it also serves an important role in columnar mode, as it allows to perform a lot of safety checks at compile time. E.g. it allows to guarantee that an ObjectId always refers to a valid entry in the container and that it can only be used with columns that are associated with that container.

For many of the containers there will be type aliases defined for some of the "common" infrastructure types, i.e. ObjectId, ObjectRange, OptObjectId, AccessorTemplate. This is meant to shorten the syntax for classes that users will regularly use in their own code. This is born out of experience during the prototyping stage when I found that the syntax that included all template parameters quickly became unwieldy.

Originally this was an enum class, and from a user perspective the syntax should still look mostly the same, except that there is no longer an enum that can be used to identify it, and the template parameters now take types instead of enum values. The main downside is that the container id can no longer be represented by an enum at runtime, but there are workarounds for the few situtations that need that.

The main motivation for representing this as a "traits" struct is that it makes it possible to define parametric container ids. It also alleviates the need to have a single list of all container ides in a single place.