Getting access to LHC Computing Grid. One can find a brief introductory material at the
RMKI's getting started page, where you can find information on how to get access to LCG. There are also simple examples on that page.
Some more practical information on running a typical job.
- Get authenticated on the LCG:
> grid-proxy-init
Here, you will be prompted for your grid password. Or:
> grid-proxy-init -valid 4:00
This is the same, but the authentication will be only valid for 4 hours.
Now you can perform various operations on the grid, e.g. send jobs. You can get info on your authentication (e.g. expiration etc.) by
grid-proxy-info
. You can destroy your authentication proxy by
grid-proxy-destroy
.
- Get your jobs authenticated on the LCG:
> myproxy-init
Here, you will be prompted for your grid password, and to specify a password attached to your so called
job proxy to be created. Or:
> myproxy-init -n
Here, you won't be asked to specify a password for your proxy.
Running
myproxy-init
is necessary when you are running long-term jobs. In this case, the
myproxy-init
ensures that your jobs still will have authentication even after your interactive proxy (obtained by
grid-proxy-init
) has expired. You can get information on your job proxy by
myproxy-info
. You can destroy your job proxy by
myproxy-destroy
. Note: if you don't use this, you may not be able to retrieve your job outputs for long-term jobs!
A "Hello World!" example can be found at
RMKI's getting started page. Instead of a "Hello World!" example, we present here a framework, with which one can send jobs in mass to the LCG: see the attached tarball called
submit.tar.gz. You can adjust these shell script wrappers to your needs. This assumes that your jobs are placed in a directory scheme like in the attached example
skeleton.tar.gz. This latter is a framework for simple jobs, which are ran on a simple computers (contains an automated Makefile and an automated starter shell script).
- Specifying system requiremets:
It is a common task to require some software environment from the working nodes, where your jobs will be executed (e.g. AFS). You can specify requirements by placing lines like the following line to your .jdl file:
Requirements = (Member("AFS", other.GlueHostApplicationSoftwareRunTimeEnvironment));
One can apply logical operations to the arguments, like:
Requirements = (Member("AFS", other.GlueHostApplicationSoftwareRunTimeEnvironment) && Member("VO-cms-ORCA_8_13_1", other.GlueHostApplicationSoftwareRunTimeEnvironment));
- Using the storage elements of the LCG:
The files are stored on Storage Elements on the LCG. Usually these have different physical file administration schemes. Therefore, a logical layer was built on top of them, which makes the file access uniform from the user point of view. To use this facility , use the environmental variable LCG_CATALOG_TYPE:
export LCG_CATALOG_TYPE = lfc
(for
bash), or
setenv LCG_CATALOG_TYPE lfc
(for
tcsh).
The Logical File Name (
lfn) is resolved by the Logical File Catalogue (
lfc) server. You have to specify this:
export LFC_HOST = lfc-cms-test.cern.ch
(for
bash), or
setenv LFC_HOST lfc-cms-test.cern.ch
(for
tcsh).
Now you can refer to files with their logical file names, which are site-independent. The logical file names have to be unique. A very convenient way to generate them is to imitate the UNIX type file naming scheme. With the command
lfc-mkdir
one can make logical directories, like
> lfc-mkdir -m 755 /grid/cms/user_name/some_directory
(Here, the
-m xxx
option is optional, this sets the permissions of the directory. All logical file names begin with
/grid/virtual_organization
. If you are a new user, the directory
/grid/virtual_organization/user_name
will not exist initially: you have to create it first, if you want an own directory. It is recommended to restrict write permissions like in the example.)
There are various commands to manage logical file names, all beginning with
lfc-
, like
lfc-chmod
,
lfc-getacl
,
lfc-setacl
,
lfc-chown
,
lfc-ln
,
lfc-rename
,
lfc-ls
,
lfc-rm
,
lfc-mkdir
etc. Refer to the
man
pages of these commands, but the usage of these should be self-explanatory.
As the given logical directory is ready, one can copy files into it. If you want to store a file in the LCG storage infrastructure permanently, copying a file is not enough: you have to register the file in the logical file catalogue. It is done like:
> lcg-cr --vo cms -d grid100.kfki.hu -l lfn:/grid/cms/alaszlo/destionation/testfile.txt \
file:/afs/kfki.hu/home/alaszlo/source/testfile.txt
(Here, the
-d destination_Storage_Element
is optional, and is used to force the destination Storage Element to be
destination_Storage_Element
; otherwise the file may be copied to a Storage Element anywhere in the World.) This command will
copy and register your file onto LCG storage system. Once your file is there, you can get a copy of it with
lcg-cp
e.g. as an input for a job:
> lcg-cp --vo cms lfn:/grid/cms/alaszlo/some_directory/test_file.txt file:$PWD/test_file.txt
(This command stages out the file in question onto a local --or AFS-- disc area, pointed at by
$PWD
, i.e. into your current directory.)
There are various commands to manage the stored files (e.g. unregister and delete them, or create replicas), all beginning with
lcg-
, like
lcg-rep
,
lcg-aa
,
lcg-rf
,
lcg-cp
,
lcg-cr
,
lcg-la
,
lcg-uf
,
lcg-del
,
lcg-lg
,
lcg-lr
,
lcg-gt
,
lcg-ra
etc. Refer to the
man
peges of these commands, but most of them are self-explanatory.
Unfortunately, one cannot copy and register complete directory trees. Therefore, I wrote a shell script wrapper to do this:
> lcgcr.sh source_directory destination_directory_lfn
(You can find this here:
lcgcr.sh.)
Note: unfortunately, I encountered that the
lcg-cr
action often fails (this should be remedied in future). Therefore, it is convenient to put an
lcg-cr
command into a checker loop:
RESULT = 1
while (( $RESULT != 0 )) ; do
lcg-cr --vo cms -d grid100.kfki.hu \
-l lfn:/grid/cms/alaszlo/destintation/test_file.txt \
file:/afs/kfki.hu/home/alaszlo/source/test_file.txt
RESULT = $?
if (( $RESULT != 0 )) ; then sleep 1m ; fi
done
This precaution may also be recommended for
lcg-cp
.
--
AndrasLaszlo - 06 Mar 2006