1. The ATLAS software in the Grid Alessandro De Salvo <Alessandro
The ATLAS software in the Grid Alessandro De Salvo
Outline
Overview
The Experiment Software Structure in the Grid
Using the ATLAS software from a Grid node
Selecting software releases
Using the Installation System for EGEE
Documentation & contacts
A. De Salvo – 20 Apr 2008

2. The ATLAS software in the Grid: overview
The Grid nodes are installed with standard distribution kits
Using pacman from the central caches or from one of the mirrors
Same installation as you would have in your local machine
pacman -get am-CERN:
After the installation step, each site is validated using KitValidation
Only if the site passes the KV tests is considered validated
When a site is validated for a given release number, the relevant tag is published to the Information System
In EGEE a tag is published to the CE (we’ll see later how to use it)
In OSG this corresponds to publishing the number of the release and the path to the information system

3. The Experiment Software Area
The ATLAS software in the Grid is installed in the Experiment Software Area reserved for ATLAS
Disk area shared among the Worker Nodes via a shared filesystem (NFS, AFS, GPFS, PANFS, …)
The user may access the software from a WN by using some variables defined at runtime in the WN
EGEE
$VO_ATLAS_SW_DIR
OSG
$OSG_APP/atlas
Example: CERN
VO_ATLAS_SW_DIR=/afs/cern.ch/project/gd/apps/atlas/slc3

4. The structure of the software installations in EGEE
Each release has a separate entry point
$VO_ATLAS_SW_DIR/software/<release_number>
Example
$VO_ATLAS_SW_DIR/software/
The entry point (logical installation) is a displaced installation of the physical release
The physical area is located in a different place and may have multiple releases sharing the same disk area
Different areas for production, development and nightly releases
Production: $VO_ATLAS_SW_DIR/prod/releases
Development: $VO_ATLAS_SW_DIR/dev/releases
Nightlies: $VO_ATLAS_SW_DIR/nightlies
The users should never use directly the physical releases, which could change location at any point
Always use the release entry point under $VO_ATLAS_SW_DIR
Once the release has been set up from the logical release, the variable SITEROOT will be set to point to the physical installation area

5. Using the main ATLAS releases in EGEE
Setup the runtime environment
For releases <
For future releases (> )
Run athena as normal
source $VO_ATLAS_SW_DIR/software/<rel_num>/setup.sh
cd $SITEROOT/AtlasOffline/<rel_num>/AtlasOfflineRunTime/cmt
source setup.sh
cd -
source $VO_ATLAS_SW_DIR/software/<rel_num>/setup.sh
Athena <jobOption>

6. Simulating a Grid run: running Athena HelloWorld at Roma1
From the practical point of view, running within the Grid environment and in local mode is equivalent, provided that
We have the env var $VO_ATLAS_SW_DIR set
We have access to the Experiment Software Area
Let’s simulate a Grid environment at CERN and run an Athena HelloWorld, using release
Login to the Roma1 Tier2 (atlas-ui.roma1.infn.it)
Use the following commands
# Set the Experiment Software Area
export VO_ATLAS_SW_DIR=/opt/exp_soft/atlas
# Setup the release
source $VO_ATLAS_SW_DIR/software/ /setup.sh
cd $SITEROOT/AtlasOffline/ /AtlasOfflineRunTime/cmt
source setup.sh
cd –
# Start Athena
athena AthExHelloWorld/HelloWorldOptions.py

7. Using patch releases
Patch releases are shipped separately, after the main release is built
Main release
Patch releases
Each patch release is
Sharing the same physical area of the main release
Sharing the same release entry point of the main release
To use a patch release the user has to
Setup the main release
Setup the patch release from the AtlasProduction or AtlasPoint1 package

8. Using patch releases (2)
Example: setting up AtlasProduction
Example for recent releases (> )
# Setup the main release
source $VO_ATLAS_SW_DIR/software/ /setup.sh
# Setup the patch release
unset CMTPATH
cd $SITEROOT/AtlasProduction/ /AtlasProductionRunTime/cmt
source setup.sh
cd –
# Setup the patch release
source $VO_ATLAS_SW_DIR/software/ /setup.sh –tag= ,AtlasProduction,runtime

9. Compiling user code
User code may be compiled against an installed kit during a Grid job
To complie user code
Create a test area using the create-cmthome.sh script from
…or use a simple requirements file
Compile your code and use your testarea ($HOME/testarea)
$> cat requirements
set CMTSITE STANDALONE
macro ATLAS_DIST_AREA ${SITEROOT}
apply_tag projectArea
macro SITE_PROJECT_AREA ${SITEROOT}
macro EXTERNAL_PROJECT_AREA ${SITEROOT}
apply_tag opt
macro ATLAS_TEST_AREA ${HOME}/testarea
use AtlasLogin AtlasLogin-* $(ATLAS_DIST_AREA)
$> source $VO_ATLAS_SW_DIR/software/ /setup.sh
$> cmt config
$> source setup.sh –tag=AtlasOffline, ,opt,oneTest,runtime

10. Which releases do we expect to find in the Grid?
The release installation in the Grid is centrally managed
Production releases are automatically pushed in the sites
Obsolete releases are automatically removed when they are no more required for production
The analysis people should also play a fundamental role here
Need to pin releases if used for analysis, even if considered obsolete from the production point of view
The ATLAS Installation System is able to manage user requests for installation, testing and removals of releases
What you may install in the grid
Production releases (>= 11.0.X)
(Some) development releases
Nightly releases (also with automatic deployment)
Production patches
Point1 patches
Installation architectures
All the nodes are currently installed with SLC3, gcc323, 32bits releases, independent from the underlying architecture
64 bits releases are not yet officially released
Need to use SLC3 software until the majority of the nodes in the Grid will be updated to SL4 or copatible OS
SLC4 nodes may run SLC3 software, while the reverse is not true

11. Selecting sites with the required software release
For each release installed, a VO software tag is published
VO-atlas-<project>-<rel_num>
Examples
VO-atlas-production
VO-atlas-production
The VO software tags may be used in the requirements of your jobs to select the sites and resources where a given software release is available and working
In case of failures of a release in a site
Try to identify the problem
Open a ticket in GGUS, possibly specifying the application you were running, the software release, the site and the node where you had the problem
Requirements =(Member(“VO-atlas-production ",other.GlueHostApplicationSoftwareRunTimeEnvironment));

12. Checking if a release is actually present in the sites
Sometimes the sites still publish tags even if the release is missing
To check if a release is actually present in the sites
Easy approach
Check for the presence of the $VO_ATLAS_SW_DIR/software/<rel_num>/setup.sh file
Safer approach
Check the return code of “source $VO_ATLAS_SW_DIR/software/<rel_num>/setup.sh”
#!/bin/sh
if [ ! -s $VO_ATLAS_SW_DIR/software/ /setup.sh ] ; then
echo “Release not found!!!” fi
#!/bin/sh
source $VO_ATLAS_SW_DIR/software/ /setup.sh
if [ $? –ne 0 ] ; then
echo “Release not found!!!” fi

13. The ATLAS Installation System for LCG/EGEE
The software installations in EGEE are operated via the Installation System
Every user may browse the online status of the installations in LCG/EGEE

14. The ATLAS Installation System for LCG/EGEE (2)
On-demand installations or maintenance requests may also be requested
The page will be shown only if you have a valid personal certificate imported in your browser

15. The ATLAS Installation System for LCG/EGEE (3)
The Installation System may also give you the following informations
Informations on the releases (Release Matrix:
Release name
Architecture
Project name
Installation paths
Tags …
Snapshots of the current tags in the Grid (Tags Matrix:

16. The ATLAS Installation System for LCG/EGEE (4)
Users may set pins to releases to avoid the Installation System to remove specific releases
For example if you need a specific release for your analysis in a minimum number of sites and you want to keep it even if it has been considered obsolete

17. The ATLAS Installation System for LCG/EGEE (5)
Exercise
Login to the Roma1 Tier2 (atlas-ui.roma1.infn.it), setup release using the logical area
Discover where is the physical location of the release
Compare the paths of the logical and physical location you found to what you get from the Release Matrix page in the Installation System

18. Documentation and contacts
Using the Distribution Kits
In case of failures of a release in a site
Try to identify the problem
Open a ticket in GGUS, possibly specifying the application you were running, the software release, the site and the node where you had the problem
For site-specific issues (EGEE only)
The ATLAS Installation Team
The ATLAS Installation System
Main page
On-demand installation and test requests
Release pinning
Overview and status of the installed releases
Overview of the tags in the sites