ATLASLocalRootBase (v2)

NEW This is in production now.

Brief description and usage of the ATLASLocalRootBase package

ATLASLocalRootBase is a consistent "look and feel" user interface for ATLAS users on any platform or site where it is installed. It is installed with the manageTier3SW package and is available on cvmfs and on all grid sites, Tier3s as well as on CernVM.

From the user perspective, all one has to do is the following:

Tip, idea(CernVM users, or sites with cvmfs, replace below <path to> with /cvmfs/atlas.cern.ch/repo and see the section below for overrides.)

export ATLAS_LOCAL_ROOT_BASE=/<path to>/ATLASLocalRootBase # use your path
alias setupATLAS='source ${ATLAS_LOCAL_ROOT_BASE}/user/atlasLocalSetup.sh'
setupATLAS

or the equivalent c-shell variant:

setenv ATLAS_LOCAL_ROOT_BASE /<path to>/ATLASLocalRootBase  # use your path
alias setupATLAS 'source ${ATLAS_LOCAL_ROOT_BASE}/user/atlasLocalSetup.csh'
setupATLAS

Tip, idea The user can also add this in ~/.bash_profile and simply type setupATLAS when needed.

export ATLAS_LOCAL_ROOT_BASE=/<path to>/ATLASLocalRootBase # use your path
alias setupATLAS='source ${ATLAS_LOCAL_ROOT_BASE}/user/atlasLocalSetup.sh'

The equivalent in csh commands are

setenv ATLAS_LOCAL_ROOT_BASE /<path to>/ATLASLocalRootBase  # use your path
alias setupATLAS 'source ${ATLAS_LOCAL_ROOT_BASE}/user/atlasLocalSetup.csh'

TIP If you do not like the reverse highlight menu, you can disable it export ALRB_userMenuFmtSkip=true (bash/zsh) or setenv ALRB_userMenuFmtSkip true (tcsh).

CernVM users or using ATLASLocalRootBase from cvmfs

Non-CernVM users, you can also use ATLASLocalRootBase from cvmfs, for 64-bit OS, if you have cvmfs installed - almost all sites have it.)

(You should be using a 64-bit CernVM; 32-bit is no longer supported.

You should have the following lines in ~/.bash_profile:

export ATLAS_LOCAL_ROOT_BASE=/cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase
alias setupATLAS='source ${ATLAS_LOCAL_ROOT_BASE}/user/atlasLocalSetup.sh'
export ALRB_localConfigDir=$HOME/localConfig

See the next section on "Local Overrides" for what to insert in $HOME/localConfig.

Local Overrides

Note that you can override some settings by creating a local directory. This is mainly for users who are using CernVM or ATLASLocalRootBase from cvmfs,

For example, do the following:

mkdir $HOME/localConfig
cp $ATLAS_LOCAL_ROOT_BASE/exampleLocalConfig/* $HOME/localConfig/

Next edit the files in $HOME/localConfig and then insert the following line into ~/.bash_profile:

export ALRB_localConfigDir=$HOME/localConfig

This will setup the appropriate local overrides for DQ2 and Frontier-squid. Usually you need not do this as site admins will have done it for you globally.

MacOS

ATLASLocalRootBase is also available for MacOS users.

  • Please install cvmfs as described here.
  • Then define these:
export ATLAS_LOCAL_ROOT_BASE=/cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase
alias setupATLAS='source ${ATLAS_LOCAL_ROOT_BASE}/user/atlasLocalSetup.sh'
  • Note that only a subset of features are available because there is no grid middleware available for MacOS.

What do you want to do ?

Note about when to do voms-proxy-init

 If you setup any tool and you see emi (or grid middleware) setup, and this at the end of the setup:
>>>>>>>>>>>>>>>>>>>>>>>>> Information for user <<<<<<<<<<<<<<<<<<<<<<<<<
 emi:
   No valid proxy present.  Type "voms-proxy-init -voms atlas"
************************************************************************

or this:

>>>>>>>>>>>>>>>>>>>>>>>>> Information for user <<<<<<<<<<<<<<<<<<<<<<<<<
 emi:
   Your proxy has 0h:29m:54s remaining
     Renew by typing "voms-proxy-init -voms atlas"
************************************************************************

or even this (only if you want to extend your proxy beyond the time listed below):
>>>>>>>>>>>>>>>>>>>>>>>>> Information for user <<<<<<<<<<<<<<<<<<<<<<<<<
 emi:
   Your proxy has 10h:59m:55s remaining
************************************************************************


Then you should do the voms-proxy-init -voms atlas explicitly.  Otherwise you do not.  

The idea is that everything needed is already setup and you should not need to explicitly setup grid middleware through rucio or other ways.

Help

Help is available:

  • helpMe
  • lsetup -h
  • lsetup -h <tool>

Simple EMI grid-middleware test

  • setupATLAS
  • lsetup emi
  • Setup your proxy:
    • voms-proxy-init --voms=atlas
  • Submit the job, eg. glite-wms-job-submit -a -o jobIDfile helloworld.jdl
  • Check on the job status glite-wms-job-status -i jobIDfile
  • Logout after you are done. EMI should not be setup directly unless you need it. (See the other examples below.)

Using DQ2

(You should consider using rucio clients instead)

  • setupATLAS
  • lsetup dq2
  • get a proxy if needed (notice I do not setup grid middleware - it is automatically done with lsetup dq2):
    • voms-proxy-init --voms atlas
  • do the usual dq2 things; e.g.
    • dq2-ls user09.AsokaDeSilva.*DDM*TRIUMF.1
    • dq2-get user09.AsokaDeSilva.DDMTest.TRIUMF.1
    • etc
Note for CernVM users: By default, the DQ2_LOCAL_SITE_ID environment is set to "ROAMING" and this may not be the desired behaviour if datasets are not fetched from your nearest source. Since the software is on a read-only file system, you can overcome this by setting up the local overrides. See this section.

Using Rucio Clients

  • setupATLAS
  • lsetup rucio
  • get a proxy if needed (notice I do not setup grid middleware - it is automatically done):
    • voms-proxy-init --voms atlas
  • do the usual rucio commands. For details, refer to the links in helpMe

Using PandaClient

  • setupATLAS (you can do this anytime - when you need it, or type printMenu)
  • lsetup panda
  • If you need athena or an ASG release, you can set it up as follows:
    • lsetup "asetup <athena version>" panda or lsetup "rcsetup <ASG release version>" panda
  • use the pathena / prun / pbook tools as usual.
    • Notice that I did not setup grid-middleware anywhere and you should not either - Panda clients do it for you.
    • if a proxy is missing or invalid, the Panda clients will ask your password to generate it.

Using Ganga

  • setupATLAS (you can do this anytime - when you need it, or type printMenu)
  • lsetup ganga
  • If you need athena or an ASG release, you can set it up as follows:
    • lsetup "asetup <athena version>" ganga or lsetup "rcsetup <ASG release version>" ganga
  • You only need to do this the first time - generate the gangarc file:
    • generateGangarc
  • ganga (if you prefer to use the iPython interface / GUI instead of the command line).
    • Notice that I did not setup grid-middleware anywhere and you should not either - Ganga will do it for you.
    • If you do not have a proxy or is invalid, Ganga will ask for your password to generate it.
  • Submit your Ganga jobs as usual.

Running Athena

First, do setupATLAS.

(note: setup allows you to setup athena in addition to multiple tools. e.g.; see the sections above.)

You can do showVersions --show=athena to list athena versions. (similarly for showVersions --show=dbrelease). Note that the conditions pool files catalog is setup once setupATLAS is done. (If cvmfs is available, its Athena/DBRelease versions will also be listed; otherwise, only local disk versions are listed.)

To setup Athena, simply do eg.
asetup 15.6.9 (sets up by default AtlasOffline 15.6.9) or
asetup 15.6.9.8 (sets up by default 15.6.9.8,AtlasProduction) or
asetup 15.6.11.3.1,TopPhys (sets up the TopPhys project for 15.6.11.3.1).
The application asetup and its usage are described in this asetup Twik page. Note that you will have a $HOME/.asetup file which configures the test area location.

Note also that asetup has an option --dbrelease to setup the release with a different DBRelease version.

Using PROOF-on-Demand (PoD)

Please see the references:

Note This will work only if your site admin has not disabled it for users. Also, bash is supported, zsh works (not officially supported) but tcsh is unavailable. CLI (Command Line Interface) is available but not the GUI versions of PoD (you still get the ROOT GUI and PROOF Speedometer).

Here, we do not tell you how to run PROOF (or ROOT) jobs but only how to setup for use.

  • setupATLAS
  • lsetup pod
On the interactive machine where you have batch queue access, do
  • pod-server start Note the connection string which you can use in PROOF.
  • Grab a few batch queues (please play nice and leave some slots free for others); depending on whether your site has pbs or condor, do:
    • pod-submit -r pbs -n <number of queues> -q <pbs batch queue name>
    • pod-submit -r condor -n <number of queues>
  • Check if your batch queues are ready for use (note, after a certain idle timeout of ~ 30 minutes, these queues will be released):
    • pod-info -l
    • pod-info -n
  • root when you are ready to use PROOF.
  • When finished, kill the server.
    • pod-server stop Please do this so that the resources are freed for the next user at your site.
The log files are in $HOME/.PoD.

I recommend letting PoD setup the default versions of itself and ROOT, normally, this will be the latest production version of ROOT. In this case, you can also do a quick benchmark test (with ROOT 5.30/02 and newer):

  • root> TProofBench pb("pod://")
  • root> pb.RunCPU()
TIP You can get the connection string from gSystem->GetFromPipe("pod-info -c") for older ROOT versions; with 5.30/02, this may work "pod://".

Running PoD on Tier3 from CernVM (or remote laptop)

Tip, idea This would be easier if you also use passwordless logins with sshKeys as outlined here.

If you are running CernVM, and your Tier3 site allows PoD to run, then you can run it remotely as follows:

On the Tier3 interactive machine,

  • setupATLAS
  • lsetup pod (you can append any additional tools / setups to lsetup as needed.)
  • generatePoDSetups Then copy the generated cfg file to your CernVM guest as instructed.
On your CernVM guest, you can then do this (this example is for pbs batch queues but condor is similar):
  • setupATLAS
  • (optional) if you need Athena, asetup ...
  • lsetup pod (you can append any additional tools / setups to lsetup as needed.)
  • pod-remote -c <the file you copied over> --start (you can skip the -c option after the first time)
  • pod-remote --command "pod-submit -r pbs -q short"
  • pod-info -l will show the resources allocated at the Tier3 by the previous command
  • root (and do your PROOF analysis on the Tier3 but display results on CernVM)
  • pod-remote --stop

Setting up SFT packages (lsetup sft)

This is for power users or advanced users who know what they are doing. Please refer to this page for details. (You may want to also look into lcgenv in the section below.

lcgenv (lsetup lcgenv)

This is for power users or advanced users who know what they are doing. Please refer to this page for details.

Tutorials

This is for tutorial conveners who want to ask users to test that their computer is ready to be used for tutorials. Please refer to this page for details.

Diagnostics

Diagnostic tools offer a way for users and user support to understand issues; these are described in more detail here.

How-to

Batch Jobs

Bash does not expand aliases and so this is what you can do if you need to use the menu options in ATLASLocalRootBase. Do one of these to overcome this:

  • Either do this in your script:
source $ATLAS_LOCAL_ROOT_BASE/user/atlasLocalSetup.sh
# and the menu options will then be available

  • Or insert in your script:
#!/bin/bash

shopt -s expand_aliases

alias setupATLAS='source ${ATLAS_LOCAL_ROOT_BASE}/user/atlasLocalSetup.sh'

setupATLAS

#(the rest of your code should now work with the menu commands)

SLURM

Submit with the following option to prevent the local environment from being set on the batch job environment.

sbatch --export=NONE ...

LSF

Submit with the following option to prevent the local environment from being set on the batch job environment.

bsub -L /bin/bash ...

Release Notes

Release notes are found here.

A few of the changes from the previous ATLASLocalROOTBase:

  • backward compatible
  • allow multiple tool setups
  • protection against redefined system commands (to be completed after transition)
  • short options
  • case insensitive commands
  • tab completion
  • more checks during setups for issues
  • cleanups of variables (to be completed after transition)
  • no annoying confirmation messages
  • independent of LANG settings (to be completed after transition)

-- AsokaDeSilva - 24 Jun 2008</verbatim>

Edit | Attach | Watch | Print version | History: r11 | r8 < r7 < r6 < r5 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r6 - 2017-01-17 - AsokaDeSilva
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback