|US ATLAS SW Infrastructure|
Information for new users of U.S. ATLAS TIER I center|
This page is not updated since December 2005. Please refer to U.S. ATLAS Software Support Wiki for up-to-date information.
Please refer to the Tier I Computing Facility (ACF) help pages for details on accounts, file systems, and ACF computers. Here is a short summary.
acas00N.usatlas.bnl.govfarm nodes(N=0-8). There is also the general purpose interactive Sun workstation at atlas00.usatlas.bnl.gov with larger selection of programs (e.g.
netscape, xv, xfigthat are not installed on
acasmachines). However ATLAS software is not available on SunOS.
$HOMEvariable. Home directories are backed up but of rather limited size (500 MB is standard). There is a scratch (not backed-up) NFS system at
/usatlas/scratch/<username>for temporary file storage. When the scratch area becomes full the older and larger files are automatically purged. ACF has also established AFS cell,
/afs/usatlas.bnl.gov, for sharing files with remote institutions. Users have personal AFS areas at /afs/usatlas.bnl.gov/users/<username> and all ATLAS software is installed on AFS.
$LD_LIBRARY_PATH. The U.S. ATLAS accounts get automatically the standard login files in their home directories, such as
.cshrc, with the following contents:
if ( -r /usr/local/lib/hepix/shells/hep/central_env.[c]sh ) then source /usr/local/lib/hepix/shells/hep/central_env.[c]sh endifThis installs initial (very basic) U.S. ATLAS environment by sourcing a file on the central file server. A user can add its own definitions in login files if desired.
X,Y,Z = 0 - 9. The "production" ATLAS releases have
Y = 0, all other releases are "development". ATLAS software releases depend on many external packages (about 57 as of January 2004). The main OO framework, ATHENA, is based on the GAUDI architecture that is technically also an external package.
At the U.S. ATLAS Tier I Computing Facility the software organization mirrors the CERN ATLAS site. The major areas are
ATLAS software release consists of install area (
and directories of packages. Install area contains references (soft links)
to binaries, includes and share files dispersed in the release tree.
ATLAS releases are managed by CMT
The packages are organized according to CMT principles
and can be simple packages (with no subpackages) or containers
of simple packages and/or subcontainers. A CMT package consists
of the version directory(ies) containing
areas with sources, binaries, and
cmt directory with
CMT configuration (usually stored in single
Theoretically CMT allows multiple versions of one package in the release,
however in ATLAS releases all packages have single version.
CMT managerial principles and mechanisms are used in all stages of work (setting environment, compilation, linking, running) and they are evolving with ATLAS software. This means that the particular ATLAS releases must be handled with specific version of CMT. In addition the procedures for setting working environment vary for different releases. The helper scripts for automatic environment tuning have been developed for U.S. ATLAS users. The basic model of ATLAS software development include the following steps (click on links for concrete recipes):
$LD_LIBRARY_PATHpointing to correct compiler, as of Jan. 2004
gcc 3.2installed in
cmt cocommand because it creates the correct directory hierarchy.
setup.(c)shscript (generated by
cmt co) in
cmtdirectory of a package. As well in this directory CMT generates Makefile, so the compilation and linking is performed with standard
setup.(c)shprovides also a run time environment for jobs associated with the package.
athenathat loads components dynamically at run-time. The components (ATHENA algorithms and services) and job parameters are specified in jobOptions files located in the share directories of packages (and also referenced in InstallArea). Therefore all kinds of jobs (simulation, calibration, reconstruction...) are performed with standard command
athena<package name/specific jobOption>