Atlas Distributed Analysis (ADA) is a project to deliver the tools necessary for analysis (in particular, the manipulation and extraction of summary data, e.g. histograms, from any type of event data and the user-level production of such data) over a distributed computing enviroment such as the grid.

See Also grid.

The Andrew File System is a distributed network file system that enables file sharing from any machine running the AFS deamon (an open source version for your own machine can be had from here) and having the proper credentials. Most notably, your home directory at CERN is mounted on AFS, and your lxplus account is typically your so-called AFS principal. You can use As with any network file system, AFS suffers from delays as files are checked for updates and, especially for Atlas software, when caches overflow.

See Also Distribution Kit, kerberos.

The Abstract Interfaces for Data Analysis project has as goal to define abstract interfaces for common physics analysis objects, such as histograms, ntuples, fitters, IO etc., to allow for easy exchange and porting of physicist' analysis code. Concrete AIDA implementations exist for a.o. JAS, python, and ROOT.

See Also python, ROOT.

The Analysis Object Data, which consists of a reduced size output of physics quantities from the reconstruction that should suffice for most kinds of analysis work. Separate tailor-made streams of AODs are foreseen for different needs of the physics community. For more information, see the AOD/ESD Definition Task Force.

See Also ESD, RDO, ZeeRec.

The software framework for Atlas. Based on GAUDI, ATHENA provides common services such as the transient data store, (interactive) job configuration and auditing, data(-base) access, message streams, etc. for Atlas software. The idea is to improve the coherency of the different software domains within Atlas, and thereby the ease of use for end-users and developers, by having them all use the same well-defined interfaces. For more information, see the Atlas architecture site.

See Also GAUDI.

A CMT run-time environment package for the Atlas offline simulation; similar to what TestRelease is for the full Atlas release. Its use is described under the installation> and HowTo sections of the simulation project site. Note, however, that since the releases from mid-2005, it has been superseded by the G4AtlasApps package (see the same links, above).

See Also G4AtlasApps, GEANT4, TestRelease.

A CMT bootstrap package that allows you to perform the required CMT setup to be able to do the Atlas setup for your chosen work environment. Typically, you set it up by adding a dependency to it in an additional bootstrap in your home directory, which first specifies such variables as SITEROOT, CMTSITE, and the work directory that will form the first part of CMTPATH. AtlasLogin will then take care of the rest. See the relevant part of the workbook account setup for the exact steps, which differ from site to site. AtlasLogin is not internally used by ASK.

See Also CMT, SITEROOT, CMTSITE, CMTPATH.

A fast simulation package for Atlas. The full simulation, which propagates in great detail all particles from the collision through the Atlas detector, is rather slow. Instead of these CPU-intense computations, the AtlFast package performs a parametrised smearing of the output from the generator. This produces results that closely resemble, physics-wise, those of the reconstruction of the full simulation output, and are, computing-wise, in the same format. With AtlFast, analysis code can be quickly tested on many different physics processes, and, once matured, immediately applied to the full simulation and reconstruction.

See Also GEANT4, generator.

A large set of sophisticated, free, peer-reviewed, portable C++ source libraries, several of which are likely to make it into the C++ standard when it gets revised. The libraries range the gamut from compile-time pre-requisite checking to smart pointers, from regular expressions to threading, from wrapping C++ in python to an improved iostream interface. See the project site for details.

See Also C++, python.

There are many advantages to keeping data in a (relational) database. Speedy sequential access to the data that makes up a physics event, when layed out as a table, is not one of them. One way around this, is to keep the metadata of an event (run and event numbers, timestamp, trigger menu, etc.) in tables, such that they can be queried, but to put the event data itself in a Binary Large Object, or blob, which serves as a single value for a field in a table.

A highly versatile, multi-paradigm, multi-level, standardized programming language, that is used as the main development language in Atlas (for example, ATHENA itself is written in it, as is ROOT). C++ is widely used over an enormous range of domains, because of its versatility. In fact, it is at least the second best choice for pretty much every computing problem, and therefore great to have in your programmer's toolkit. More information is available all over the web (for example, here).

See Also ATHENA, ROOT.

The CERN Advanced STORage manager is designed to handle the huge storage requirements of LHC. The main storage for data is tape, handled by robots. Any data that you want to access needs to be mounted ('staged') onto an experiment owned scratch or stage area ('pool'), which you can then use from your jobs. If you have an account at CERN, you can find your private CASTOR space under /castor/cern.ch/user. Full details are at the CASTOR project site, where you'll find user manuals etc.

See Also LSF.

The ComBined NTuple has been the vehicle of choice for user analysis since the physics performance technical design report (PPTDR), but its usage is now slowly being replaced by AOD. Filling of the CBNT is controlled by an ATHENA algorithm, which also allows you to add your own variables to it.

See Also AOD, RecExCommon.

A C/C++ interpreter that is embedded in ROOT, to be used as command line interpreter and as macro processor. See the relevant pages on the ROOT project site.

See Also ROOT, ROOT.

A Configuration Management Tool: it is used for building software releases, for package dependency management, and for the setup of the run-time environment. Practically everything is treated as a package by CMT, even the run-time environment which is setup by "compiling" a run-time package. Detailed information is available, but be cautious! Much of CMT's behaviour (and hence how it should be used and configured) is determined by project-specific policy files.

A shell environment variable that defines a colon-separated search path which CMT uses to locate packages. Absolutely any action performed by CMT requires a properly set CMTPATH, which typically includes the top directory of your work environment, the top directory of the GAUDI installation you want to use, and the top directory of the Atlas release you are working with. If you use ASK, it will automatically take care of CMTPATH.

See Also CMT.

A shell environment variable that acts as a directive to CMT to select site specific configuration if such is made available to it. In principle, SITEROOT should be the only site specific detail, but in practice this is not the case. Consequently, some requirements files specify different configurations conditioned on the value of CMTSITE (e.g. "CERN") and CMT acts accordingly. If you use ASK, it will automatically take care of CMTSITE for the major sites CERN, BNL, and LBNL.

See Also CMT, SITEROOT.

A concurrent versions system that allows for sharing of source code among the members of a distributed development team, such as Atlas. All offline code resides in the official repository, which can be browsed online and from which users can download ("checkout") code. You can either lookup the CVS documentation on the project site, or let ASK handle the checking out of code through CMT. The latter is the preferred way of working, because it allows you to build the code, using CMT.

See Also CMT, kerberos.

An environment variable that defines the root directory of the CVS repository to be used, as well as the proper access protocol. For example, ":kserver:atlas-sw.cern.ch:/atlascvs" for use of the repository called "atlascvs" located on server "atlas-sw.cern.ch" with access permission handled through kerberos.

See Also CVS, kerberos.

Also known as reflection information, a dictionary refers to an object that contains a detailed description of another object. This information includes the object type, member functions and arguments, member data, etc. There are two prevailing dictionaries in HEP: the one provided by SEAL (typically referred to as the LCG dictionary) and the one provided by ROOT.

See Also CINT, LCG, SEAL, ROOT.

A CMT run-time environment package for the Atlas offline digitization, the simulation of the detector and electronics response; similar to what the TestRelease package is for the full Atlas release. More information is available from the site of the digitization work group.

See Also TestRelease.

The Atlas software is distributable through a set of tools, collectively referred to as the "Distribution Kit." Roughly, you download all the binaries and header files for your platform from a website and have PACMAN install it locally. Go to the Atlas code distribution pages for specific details.

See Also PACMAN.

Common interfaces and data objects are a necessity to ensure maintainability and coherence of the Atlas software platform over a long period of time. The Event Data Model (EDM) improves commonality across the detector subsystems and subgroups such as trigger, testbeam, and offline. Detailed information (implementation issues, schema evolution, etc.) is available.

See Also AOD, ESD, RDO.

The Event Summary Data, which consists of sufficient information to re-run (parts of) the reconstruction, such track refitting, jet calibration, etc., as for some kinds of analysis, the information available in the AOD may not be enough. By selecting information from the ESD (or by selecting certain reconstruction algorithms and hence, transparently, the required ESD), rather than going back to the original byte stream, the needed I/O can still be kept to a minimum. For more information, see the AOD/ESD Definition Task Force.

See Also AOD, RDO.

The Event Selection, Reconstruction, and Analysis Tools (ESRAT) is an overarching project to ensure that the Atlas software can deliver on the requirements of the full trigger chain, the detector commissioning, and the physics productions.

See Also EDM.

A python-based interface and run-time environment package for the Atlas offline simulation based on GEANT4. Its use is described under the installation section of the (new) simulation project site.

See Also GEANT4.

The software framework for LHCb. The GAUDI framework was originally developed by LHCb, but is now in use by several experiments, including Atlas. When referring to GAUDI in the context of ATHENA, the term is meant to describe the common core of the two frameworks. For more information, see the GAUDI project site.

See Also ATHENA.

The package that provides the python interface to ATHENA. GaudiPython is part of GAUDI and consists of a python extension module that provides bindings to the core classes and objects of the ATHENA framework.

See Also ATHENA, GAUDI, python.

A toolkit for building geometries of physical structures, e.g. the Atlas detector, and simulating the physics processes that occur as particles traverse through these structures. For use within Atlas, refer to the Atlas simulation pages; for general use, refer to the GEANT4 project site.

Short for "event generator." A computer program that models the physics processes that occur in the collisions in high-energy physics experiments. The results of running a generator consist of a list of particles (incoming, created, decay products, etc.), their properties, and their origins, just after the collision. Detailed information is available in this tutorial.

See Also HERWIG, PYTHIA.

A specific set of ATHENA algorithms that allow you to select from the event generator output, exactly those events that you are interested in. A large set of filters is available in the repository.

See Also ATHENA, generator.

An infrastructure of computing resources, such as storage and processing units, that is transparently made available to the user through a network. The term "grid" originates from the analogy of the electric grid, as the idea is to make computing just as ubiquitous and easy to use.

A utility to convert HBOOK/PAW files into ROOT files. h2root is part of the ROOT releases; see the HowTo for its use.

See Also ROOT.

An event record for high-energy physics Monte Carlo generators. HepMC stores the output from an event generator as a graph of particles and vertices, where the vertices maintain a listings of the incoming and outgoing particles and the particles point back to their production vertices. Documentation, papers, downloads, etc. are available.

A program for the generation of high-energy physics events. The simulation of events as they will take place in the Atlas detector, starts with the simulation of the collisions themselves. This is done in event generators such as HERWIG, a Monte Carlo package for simulating Hadron Emission Reactions With Interfering Gluons, which contains theory and models for e.g. hard and soft interactions, parton distributions, initial and final state parton showers, particle decay, etc. The output of an event generator can subsequently be fed into the Atlas detector simulation, which tracks the particles from the events through Atlas. Detailed information is available on the HERWIG site. There is also Atlas specific information, which describes the Herwig_i interface package for use with ATHENA.

See Also JIMMY.

The number of events in some physics channels in Atlas is expected to be very, very small (order of thousands or even hundreds of events over the lifetime of the experiment). The analysis of these events will therefore span many runs, each with their own set of alignments, calibrations, geometry layout, etc. When such an analysis is done in a single job, it is then important to maintain the interval of validity (IOV) of the values currently loaded, such that new ones are loaded as needed. In ATHENA, this is provided for by the IOVSvc.

See Also ATHENA.

JIMMY is a plugin to HERWIG; a library of routines that allows the generation of multiple parton scattering events in hadron-hadron, photon-photon, or photon-hadron events. Detailed information is available on the JIMMY project site. There is also Atlas specific information, which describes how to use JIMMY with the Herwig_i interface package.

See Also HERWIG.

The job options search path environment variable consists of a comma (!) separated list of directories where ATHENA can look for job options files.

See Also ATHENA.

A network authentication protocol for client/server applications using secret-key cryptography, developed by MIT. Clients obtain so-called "tickets" from ticket granting servers that are trusted by the server application. Once a ticket is obtained, client applications can interact with the server application using the kerberos protocol. In Atlas, kerberos is used to authenticate users to the CVS repository. Thus, for any work that involves the code repository, you will need to obtain a kerberos ticket.

See Also CVS.

The LHC Compuring Grid Project, which intends to serve the computing needs of LHC by deploying a world-wide grid. The most visible LCG applications for Atlas end-users are POOL and SEAL, which is an LCG subproject. The LCG project site has extensive information.

See Also grid, POOL, SEAL.

The Les Houches Accord Parton Density Function inteface, which was agreed upon at the Les Houches 2001 workshop by the PDF working group. Downloads, manual, underlying theory, and more.

The Load Sharing Facility is a batch queing system that regulates the use of computing resources. Jobs are submitted into queues based on their expected load and executed in an as fair as possible scheme following pre-set priorities. Detailed information and reference guides are available at the CERN batch services site.

In order to facilitate integration testing of the Atlas software, a process that is non-trivial because of the sheer number of developers involved, every (CERN timezone) night, a release is build based on the latest CVS tags that have been collected. These releases are referred to as "nightlies" by developers, and are located at CERN AFS under /afs/cern.ch/atlas/software/dist/nightlies/rel/. They can, in principle, be used just like any other release.

See Also CVS, TagCollector, AFS.

A PACkage MANager, which allows you to install parts of, or the whole, Atlas offline software release on your local machine. In principle, this should allow you to work without a dependence on AFS, because PACMAN retrieves the release over HTTP. The Atlas code distribution pages have specific details on how to use PACMAN in Atlas and you can get the latest release of PACMAN itself from its project site.

See Also Distribution Kit, python.

PHOTOS is a Monte Carlo algorithm for the generation of QED radiative corrections in decays of any resonances, simulated by a "host" Monte Carlo generator (e.g. HERWIG). Detailed information is available in this preprint. There is also Atlas specific information, which describes the usage of PHOTOS and TAUOLA within the ATHENA framework.

See Also HERWIG, TAUOLA.

A Pool Of persistent Objects for LHC, POOL is a persistency framework designed for the LHC experiments and allows for the storage of the large volumes of experiment data and metadata in a grid enabled way. If you code within the ATHENA framework, you will not deal directly with POOL. Instead, you specify POOL as a conversion service (that is, the facility that converts the transient data into persistent data) in the configuration of your job and, unless you have special needs, its use is transparent. Some examples of use cases are available as well.

See Also ATHENA, LCG.

An implementation of a software bus in python. Analogous to a hardware bus, PyBus allows for discovery, installation, configuration, loading, unloading, and run-time replacement of software components, as well as channeling of inter-component communication. Documentation is available and some more information is given at the SEAL project site.

See Also python, SEAL.

A bridge between python and ROOT. The PyROOT package provides run-time generated python bindings for ROOT classes. It also allows calls from ROOT into python, either as call-backs or directly from the ROOT prompt. Originally part of SEAL, it is now distributed with ROOT, see the HowTo and/or the extensive user documentation for more details.

See Also ROOT, python, SEAL.

A program for the generation of high-energy physics events. The simulation of events as they will take place in the Atlas detector, starts with the simulation of the collisions themselves. This is done in event generators such as PYTHIA, which contains theory and models for e.g. hard and soft interactions, parton distributions, initial and final state parton showers, particle decay, etc. The output of an event generator can subsequently be fed into the Atlas detector simulation, which tracks the particles from the events through Atlas. Detailed information is available on the PYTHIA site. There is also Atlas specific information, which describes the Pythia_i interface package for use with ATHENA.

An interpreted, interactive, object-oriented, open-source programming languange. The python interpreter is used as the scripting interface for ATHENA, because of its excellent extending and embedding facilities. Detailed information, tutorials, reference guides, as well as downloads (note that python is included by default in most Unix distributions) are available at: http://www.python.org.

A shell environment variable that defines a colon-separated search path which python uses to locate modules.

See Also python.

The Raw Data Objects contain the raw data as it comes off the detector, while adding an identifier.

See Also AOD, ESD.

A CMT run-time environment package for the Atlas offline reconstruction; similar to what TestRelease is for the full Atlas release. It is, however, important to notice that RecExCommon includes an additional setup script (share/RecExCommon_links.sh) that is to be run once after the standard building of the run-time. RecExCommon is part of RecExample and the Atlas reconstruction pages have more details.

See Also TestRelease.

A class library for data analysis. The ROOT package provides an extensive set of functionality for data analysis in high-energy physics; it includes data display, persistency, minimization, fundamental classes, etc., as well as an interactive interpreter. The full class reference, tutorials, and other documentation, are available at the ROOT project site.

The Shared Environment for Applications at LHC, which provides common core and services (such as system, utility, framework, and mathematics) libraries for LCG applications in order to improve their coherency. For the Atlas end-user, the most visible products of SEAL are the LCG dictionary and the scripting services such as PyROOT an PyBus. Refer to the project seal for documentation, releases, and other details. Note that the SEAL project has recently merged with the ROOT project.

See Also ROOT, PyROOT, PyBus, LCG.

A shell environment variable that defines the site specific top directory for all software used in an Atlas release. Most major Atlas computing sites (or individual laptops for that matter) have copies or installations of the releases and the external software that is needed for them. Such sites can individually choose a location that suits them best, because all directory paths used in the configuration of Atlas software are relative to SITEROOT (e.g. /afs/cern.ch at CERN). Note that ASK takes automatically care of SITEROOT for the major sites CERN, BNL, and LBNL.

See Also CMTSITE.

StoreGate implements a transient data store for ATHENA and is described in the ATHENA manual. For more information, see the Atlas architecture site.

See Also ATHENA, TDS.

The TagCollector is a web portal and associated administrative tools that eases the process of obtaining all the CVS tags that make up a release. It is also capable to automatically update and tag container packages that CMT needs for recursive checkouts.

See Also CVS, CVS.

PHOTOS simulates the tau-lepton decay for tau's from a "host" Monte Carlo generator (e.g. HERWIG). Some more information is available here. There is also Atlas specific information, which describes the usage of TAUOLA and PHOTOS within the ATHENA framework.

See Also HERWIG, PHOTOS.

The Transient Data Store (TDS) is a box where data producers can drop off their results to be picked up by clients (more often referred to as consumers, even though they don't actually consume the data). The use of a store decouples producers from clients. Examples of producers include algorithms that perform calculations to come up with new data, but also services that read data from disk. Clients can be other algorithms that perform further calculations, or services that write data to disk or a database. In ATHENA, the transient store is implemented by StoreGate.

See Also ATHENA, StoreGate.

A CMT run-time environment package for the full Atlas release. Building the TestRelease package against a specific Atlas release (the one that is found through CMTPATH, or the one given to ASK when TestRelease was checked out of the repository) results in setting up the run-time for that release, usually by creating a run directory and copying and/or linking files to that directory. The Atlas software developer's guide gives you all the details.

See Also CMT, CMTPATH.

An example package of Z -> ee reconstruction that shows how to run your analysis code as an ATHENA algorithm. The current code in this package runs off the AOD, the older code uses a more direct access to the physics quantities. It may be worthwhile to compare older and current code for an improved understanding of the AOD. ZeeRec is available in the the CVS repository under Reconstruction/RecExample/ZeeRec.

See Also AOD, ATHENA, RecExCommon.