Setting up the Software

Just the Offline

These instructions can be found in many places, with the workbook being the place to start.

For setting up the offline environment, use the requirements file

#---------------------------------------------------------------------
set CMTSITE CERN
set SITEROOT /afs/cern.ch
macro ATLAS_DIST_AREA /afs/cern.ch/atlas/software/dist
macro ATLAS_TEST_AREA ${HOME}/cmthome
apply_tag setup
apply_tag simpleTest
use AtlasLogin AtlasLogin-* $(ATLAS_DIST_AREA)
#---------------------------------------------------------------------

This used to include the line

macro ATLAS_RELEASE   "11.0.5"

but now this is set when you do

> source setup.sh -tag=12.0.3
> cmt config

This also makes the directory 12.0.3 automatically.

HLT Environment

What is the overall offline release with a number like 12.0.0 is a collection of many independent projects. One of these is the HLT software project for the HLT specific packages: https://twiki.cern.ch/twiki/bin/view/Atlas/HLTRelTestDist. For the time being, this is dependent on a certain offline release as shown in http://atlas.web.cern.ch/Atlas/project/hlt/admin/www/, for example 2.0.3 corresponds to offline 12.0.3.

To run athenaMT or PT you need to setup the HLT environment. The requirements file is very similar

#---------------------------------------------------------------------
set CMTSITE CERN
set SITEROOT /afs/cern.ch
macro ATLAS_DIST_AREA /afs/cern.ch/atlas/software/dist
macro ATLAS_TEST_AREA ${HOME}/cmthome_mt
apply_tag setup
apply_tag simpleTest
use AtlasLogin AtlasLogin-* $(ATLAS_DIST_AREA)
use HLTtdaqcommon     HLTtdaqcommon-*     HLTExternal
#---------------------------------------------------------------------

then to set it up do

source setup.sh -tag=AtlasHLT,2.0.3,runtime

This creates a directorty 2.0.3 where you should put the run directory.

Or with a nightly - not sure how to use the HLT, so offline only:

source setup.sh -tag=rel_x,runtime

Now, you can run "normal athena" or you can use athenaMT or athenaPT

athenaMT

athenaMT can be thought of as a way to emulate the L2PU within the offline software. In this way, code developed in the offline can be checked to be threadsafe as required to run at the L2.

A slightly old manual can be seen at http://atlas.web.cern.ch/Atlas/GROUPS/DAQTRIG/HLT/html/athenaMT-SW-Integration-v2.0.pdf

There are various command line options not available in normal athena. A typical example would be:

athenaMT -s -c doMT=True -C -o -g TopOptions_ReadBS_Egamma_Slice_co.py

• -C runs as a single thread, so should give same results as normal athena
• -o saves an output file with the L2 results fragments
• -g used with -o above, the output file contains the full event fragments, inclusive of Level-2 result fragments.

• - w 3 will test the multithreaded compatibility by running on 3 concurrent worker thread.s

An output file created as above contains the same information as it would be available in an online setup after event building and can be used as an input file for testing Level-2 seeded reconstruction in Event Filter (see below)

athenaPT

Recall that the Event Filter (EF) uses offline reconstruction and analysis algorithms within the TDAQ framework. For the Event Filter operation, TDAQ, HLT and Athena software components have to be integrated in a common environment. The athenaPT tool allows one to test the compatibility of Athena and HLT releases.

The manual can be seen at http://bosman.home.cern.ch/bosman/svs-review-pt_test-52-corr-html/review-pt_test-MAIN.html

An athenaPT job would need an input bytestream that contains both raw data and the L2 result - just as mentioned above.

By defaults, you may need a link to something called "athenaPT.input.data"

Typical command would be

> athenaPT -n 3 TopOptions_ReadBS_Calo_Slice_athenaPT.py |& tee output_athenaPT_EFOnly.log

where -n 3 generates just 3 events

-- PaulBell - 03 Nov 2006