From ATLAS-TRIUMF

[edit] Kit Installation

You just need to follow the instructions, in principle, to install a release of the ATLAS software Athena on your own machine.

If you are installing inside the TRIUMF domain, and you can mount trshare, then you can use our local mirror. For example, to install the 12.0.2 release, you would do:

 pacman -allow tar-overwrite -get /triumfcs/trshare/atlas/AtlasSoftware/AtlasMirror/ATLAS.mirror:12.0.2

This should be the fastest way to install a release locally. You can see what is in the mirror by doing

 pacman -lc /triumfcs/trshare/atlas/AtlasSoftware/AtlasMirror/ATLAS.mirror

A cron job runs automatically to keep the mirror up to date. For the time being we have no plans to put this mirror in a public place; eventually the TRIUMF Tier 1 will be responsible for that.

[edit] Install Nightly Release Kit

Nightlies are also distributed as kits.

On my x86_64 machine, I would first check here to see which is the latest nightly (bugfix for X.0.Y, dev for X.Y.0, currently only dev has x86_64 architecture, but in retrospect, that was a mistake), then I would install it with

pacman -get http://atlas-computing.web.cern.ch/atlas-computing/links/buildDirectory/kitrel/nightlies/bugfix/cache:AtlasProduction_rel_1_i686_slc4_gcc34_opt
 

Then I would run create-cmthome.sh as below, but I would edit the script first to replace all instances of cmthome with cmthome.nightlies.

[edit] This should work for the Multi release installed on your own PC

Start from a totally clean login shell.

source <Path to kit>/Multi/CMT/v1r19/mgr/setup.sh (where v1r19 is currently the most recent version - check first)... in principle I didn't think you had to do this step, but in practice I have had wrong CMT versions if I didn't.

As an alternative, if you run afs on your computer and if the CMT version v1r20p20070720 (or later) is STILL not included in Multi, and you want "cmt show versions" to work as expected, do source /afs/cern.ch/sw/contrib/CMT/v1r20p20070720/mgr/setup.sh instead of sourcing the latest local one.

Copy the create_cmthome.sh setup script to your home directory or some other convenient place.

cd <Path to kit>/Multi

source ~/create-cmthome.sh

Note that if you already have a ~/cmthome directory, it will be renamed ~/cmthome.bak. You might want to copy it somewhere safe before running this script a second time, though... If all goes well, it will create a ~/cmthome directory for you with all the right CMT versions for the kits installed. There are some assumptions (e.g. your test area will be called testarea) so you might want to edit it first if you want something different.

Now, when you log on and want to run Athena, you must set up the runtime environment and everything else for a particular release and project. Here is a setupAthena.sh script which you can modify appropriately. In particular, you must change ATLAS_ROOT to point to your own <Path to kit>. Save the modified script in your home directory, and source it when you want to run Athena. It takes optional arguments for the release and project name (in order) so you can do source setupAthena.sh or source setupAthena.sh 12.0.5 or source setupAthena.sh 12.0.5 AtlasOffline. Now you should be able to run athena.

[edit] This should work for single project releases installed on your own PC

The instructions are identical to the preceding ones for Multi, except that instead of running create-cmthome.sh from <Path to kit>/Multi, you run it from e.g. <Path to kit>/12.0.5. And obviously if you use an optional release parameter which does not correspond to your single release (e.g. 12.0.5), it won't work.

[edit] If you sometimes run against your own kit and sometimes trshare

In that case, after running create-cmthome.sh, rename the new cmthome directory (e.g. cmthome.trshare or cmthome.localMulti) and change all cmthome in the setupAthena.sh script and in all the .sh and .csh scripts within cmthome.trshare to cmthome.trshare. Then you can have multiple versions, setupAthena_trshare.sh and setupAthena_local.sh, which just have different ATLAS_ROOT and cmthome.whatever values.

[edit] Older details

Much of the following is now obsolete or redundant, but some of it is still useful:

• it took me a while to figure out that a release kit does not include AtlasSettings, so when I just copied my CERN requirements file to my new cmthome directory and updated the paths, it didn't work. In the end, I copied this setup script from Rob McPherson and adapted the paths to fit my needs. The example is for release 10.4.0. The script assumes that in your .zshrc or some equivalent place you have defined the variables ATLAS_ROOT and ATLAS_RELEASE_PATH to point to the place where you install your releases (e.g. export ATLAS_ROOT=/data; export ATLAS_RELEASE_PATH=${ATLAS_ROOT}/AtlasReleaseArea).
• With pacman versions 3.18 and higher, you probably want to replace all pacman with pacman -allow tar-overwrite (otherwise the job keeps stopping while you are performing the very important "go to lunch/coffee/bed" stage...)
• It is much faster (compared with installing from CERN) to install from the mirror at http://particle.phys.uvic.ca/~atlas/pacman/slc3/cache, with

  pacman -get http://particle.phys.uvic.ca/~atlas/pacman/slc3/cache:11.0.3/AtlasRelease-slc3_ia32-opt

  , rather than from the main CERN cache,

  pacman -get http://cern.ch/atlas-computing/links/kitsDirectory/projects/cache:AtlasOffline_11_4_0_i686_slc3_gcc323_opt

• For project releases this address is (for example)

  http://particle.phys.uvic.ca/~atlas/pacman/projects/cache:AtlasOffline_11_3_0_i686_slc3_gcc323_opt

• I had no trouble installing multiple releases with pacman 3, but I had a lot of trouble using them, especially when two releases built against different cmt versions were involved, or when the links to things above the "dist" level (SEAL, LCG stuff in general) changed between versions. I think I have now understood how to use multiple releases properly. In particular, note that in this case I use a slightly modified Multiple Release Setup Script.
• I wanted to rebuild Muonboy locally one day, and realized that we did not have a fortran compiler. See page on dealing with fortran.
• Your testbeam jobs will run much faster if you copy the calibration files locally instead of reading them from /afs/cern.ch/atlas/testbeam/muontbh8/scratch05/calibration_data_2004/; I copied the whole directory to my local machine (it is only 15 MB).
• If you run on simulated testbeam files, you have to follow the instructions for Pool
• Your jobs will run much faster if you do not have to connect to a database at CERN. For some things, like the conditions databases for real testbeam runs, it is unavoidable, but if you are just using the database for geometry, try to set up a local replica database. This may get you in trouble if you are running on real testbeam data; the replica database does not always get updated as quickly as the kit, so sometimes a database fix you need (e.g. for automatic geometry selection) goes into the official database but won't be in your replica. In that case you are better off connecting to the CERN DB, even for geometry!--Isabel 15:40, 1 Dec 2005 (PST)

If the kit is patched after you have installed it, you may want to update it. For me, just doing "pacman -update" works fine now (I used to have problems with overwrites).

--Isabel 10:39, 17 Nov 2005 (PST)

--Isabel 14:55, 13 Sep 2005 (PDT) (major revision)

--Isabel 09:41, 6 September 2006 (PDT) (major revision)

--Isabel 14:46, 1 March 2007 (PST) (major revision) --Isabel 14:57, 29 May 2007 (PDT)