Atlfast Physics Output Entities

General

The ARD gives rise to several physics output entities, i.e. entities which the user requires for manipulation in an application.

  1. Electron
  2. Photon
  3. Muon
  4. Jet
  5. Track
  6. Cell

An inspection of the public attributes required by each of the entities leads
us to the following entity -> class mapping decisions.

The attributes required by each of the principle particle entities (Electron, Photon, Muon) are identical, therefore

The Jet and Track entities each required additional information with respect to what is required for particle entities, therefore: The Cell entity has a rather different place in the structure.
In the original Atlfast Fortran it was not a public output entity: it was used purely as an internal representation of the calorimeter.
It is only in the more recent UR survey that requests for this to become an output entity were made.

Class Diagram

All physics output entities can be seen in the Physics Output Entities Class Diagram


Interfaces

It has been proposed that ATLAS should develop a comprehensive set of interfaces
to be implemented by many (if not all) of its reconstruction and analysis classes.
This is described in great detail in:

Atlas Interfaces

where a comprehensive discussion is given as well as suggestions for sets of attributes.

Decisions on ATLAS wide interfaces manifestly involve many interest groups, and cannot converge quickly.
Therefore in this iteration of Atlfast we have implemented a simple prototype interface to capture kinematic attributes.
This is achieved through the abstract base class:

IKinematic

This interface is currently a placeholder for accessors for all kinematic attributes, but as yet only a subset of the possible accessor methods have been implemented. All of the physics output entities implement IKinematic except the Track class.

The Track implements the interface ITrackTrajectory
which is based upon the well known tracking oriented parameter set.

Note: Similar trajectory information is actually required for all the particle classes as matching between particle position and cluster postion is  required.
This was not included in the Atlfast Fortran implementation. A suitable extention to the Ikinematic interface is discussed in the general interfaces docment referenced above, however, this has not yet been implemented in Atlfast.

History associations

The question of safe and OO history associations has not yet been properly solved in the Athena framework.
History associations are those such as tracing the Generator particle upon which a simulated partice is based, or the Cells from which a Cluster is created.

As a stop gap measure an ad-hoc solution is used in Atlfast. This is achieved by the inherited class

AssociationManager

It is intended that this will be replaced when a proper Athena wide solution is adopted.

Other associations

There is also a different sort of association required.
This is typified by the this electron is close to this cluster association,
i.e. not a creation history, but a post creation association which may in general have arbitrary criteria.

This is even more complicated to solve safely and in an OO fashion.
This is not yet done and the AssociationManager mechanism is used for this need at present.