Getting Started with the Grid at Dartmouth

Overview of Globus Software

Grid Security Infrastructture (GSI)

Public Key Infrastructure (PKI) certificates
Two keys - public and private keys
Dartmouth grid uses Dartmouth Certificate Authority
Commonly used commands:

grid-proxy-init, grid-proxy-info, grid-proxy-destroy
grid-cert-info, grid-cert-request
grid-change-pass-phrase

Grid Resource Allocation and Management Service (GRAM)

remote job submission and management
relies on a resource manager for scheduling and resource brokering
Commonly used commands:

globusrun, globus-job-run,
globus-job-submit, globus-job-status, globus-job-get-output
globus-job-clean

GridFTP

high-performance, secure, reliable data transfer
uses GSI security
Commonly used commands

globus-url-copy

Uberftp - interactive client for GridFTP

Monitoring and Discovery Services (MDS)

discover and publish system configuration and status information

Overview of Globus GSI Security

Uses PKI (Public Key Infrastructure) X.509 certificates
Users have a public and private key
Dartmouth Grid Uses Dartmouth Signing Authority
Use getcert program to obtain a certificate
User certificates in .globus subdirectory

Contents of $HOME/.globus

userkey.pem (private key readable only by you)
usercert.pem (public key)

Grid Server files: located in /etc/grid-security

grid-mapfile
certificates /
hostcert.pem
hostkey.pem

Grid Servers use a grid-mapfile to map authorized grid users to an existing account.

"/DC=edu/DC=dartmouth/C=US/O=Dartmouth College/UID=29846/CN=Susan A. Schwarz/emailAddress=Susan.A.Schwarz@Dartmouth.EDU" grid

Obtain A Personal PKI Certificate

The first step is to obtain a personal certificate from the Dartmouth Certificate Authority. You only need to do this once and you will use this certificate each time you want to use the grid. Here us an example of how to run the getcert program.

sierra:~> getcert

DND User Name: Susan A. Schwarz

DND Password:

Verify Password:

SSL configuration initialized...



 ----------  I M P O R T A N T  ----------

You will be asked to choose and enter a PEM password.

This password is used to protect your private key from

being used by another user. You are encouraged to pick

a strong password that is different from your DND password

or any other password that you already have in use.

 ----------  I M P O R T A N T  ----------



Using configuration from /tmp/sslconf.10231

Generating a 1024 bit RSA private key

.............................++++++

...........................++++++

writing new private key to '/afs/northstar/ustaff/sas/.globus/userkey.pem'

Enter PEM pass phrase:

Verifying password - Enter PEM pass phrase:

Check for your certificates:

sierra:~/.globus> cd ~/.globus
sierra:~/.globus> ls -l
2 -rw-------    1 sas      users        1627 Mar 18 10:51 usercert.pem
1 -rw-------    1 sas      users         963 Mar 18 10:51 userkey.pem
sierra:~/.globus>

Prepare To Use the Grid - Obtain a Proxy Certificate

Login into to one of the grid portal computers - polaris or sierra. Both have AFS home directories so the files are same on both. The condor software that we will use does not work with AFS so we will make a new directory in the /scratch directory. The next step is to obtain a Globus proxy certificate using the Globus command grid-proxy-init. The proxy certificates are good for a limited amount of time, the default life span is 12 hours. You can use the command grid-proxy-info to view your proxy certificate.

sierra:~> mkdir /scratch/sas
sierra:~> cd /scratch/sas
sierra:/scratch/sas> grid-proxy-init
Your identity: /DC=edu/DC=dartmouth/C=US/O=Dartmouth College/UID=29846/CN=A. Schwarz/emailAddress=Susan.A.Schwarz@Dartmouth.EDU
Enter GRID pass phrase for this identity:
Creating proxy ................................................. Done
Your proxy is valid until: Wed Mar 23 02:27:44 2005
sierra:~>
sierra:~>
sierra:~> grid-proxy-info
subject  : /DC=edu/DC=dartmouth/C=US/O=Dartmouth College/UID=29846/CN=Susachwarz/emailAddress=Susan.A.Schwarz@Dartmouth.EDU/CN=1383623875
issuer   : /DC=edu/DC=dartmouth/C=US/O=Dartmouth College/UID=29846/CN=Susachwarz/emailAddress=Susan.A.Schwarz@Dartmouth.EDU
identity : /DC=edu/DC=dartmouth/C=US/O=Dartmouth College/UID=29846/CN=Susachwarz/emailAddress=Susan.A.Schwarz@Dartmouth.EDU
type     : Proxy draft compliant impersonation proxy
strength : 512 bits
path     : /tmp/x509up_u729
timeleft : 11:59:46
sierra:/scratch/sas>

Check to be sure that you can authenticate to GRAM, the Globus resource manager.

sierra:/scratch/sas> globusrun -a -r beowulf2.dartmouth.edu

GRAM Authentication test successful

Run Jobs Using Globus

The command globus-job-run will allow you to run a command on a grid computer. The command globus-job-submit will submit a job to be run on a grid computer and allow you to query the results. The syntax of globus-job-run is:

% globus-job-run <hostname> </path/executable> <arguments>


sierra:~> globus-job-run beowulf2.dartmouth.edu /bin/date
Tue Mar 22 15:06:22 EST 2005
sierra:~>
sierra:~> globus-job-run cs-01.grid.dartmouth.edu /bin/echo Hello World
Hello World
sierra:~>

The command globus-job-submit command is used for batch jobs. You submit a job to the scheduling manager (PBS,SGE,Condor) and connect later to get the results. Use the command globus-job-status to see if the job has been completed and the command globus-job-get-output to get the output from the job. The syntax of globus-job-submit is:

% globus-job-submit <hostname> </path/executable> <arguments>


sierra:~> globus-job-submit beowulf2.dartmouth.edu/jobmanager /bin/date
https://beowulf2.dartmouth.edu:45001/18715/1111691071/
sierra:~> globus-job-status https://beowulf2.dartmouth.edu:45001/18715/1111691071/
DONE
sierra:~> globus-job-get-output https://beowulf2.dartmouth.edu:45001/18715/1111691071/
Thu Mar 24 14:04:37 EST 2005
sierra:~>

Different Forms of the Contact String

hostname - job is submitted to the resource manager (if it exists)
hostname/jobmanager-fork - runs on the master node with no resource manager
hostname/jobmanager - job is submitted to the resource manager (if it exists)
hostname/jobmanager-pbs - job is submitted to the PBS resource manager
hostname/jobmanager-sge - job is submitted to the Sun Grid Engine (SGE) resource manager
hostname/jobmanager-condor - job is submitted to the Condor resource manager

Overview of Condor-G Examples

Example 1: Simple example /bin/date
Example 2: run a program with arguments, read standard output
Example 3: stage input file, run program ,retrive output file
Example 4: multiple runs of the same program with different inputs
Example 5: Matlab example
Example 6: MPI Example
Example 7: DAG Example

Download these Condor-G Examples

Commonly Used Condor Commands: (all commands have -help option)

condor_submit - submit a job
condor_submit_dag - submit a DAG job
condor_q - see jobs in Condor queue
condor_rm - remove jobs from the Condor queue
condor_hold - put job(s) on hold
condor_release - release held jobs

Note:
Current version of Condor-G doesn't work with AFS
Work from a scratch directory
Condor sends you email when a job finishes

Simple Condor-G Example

Open the Condor submit file called example1.submit and which contains the following lines:

executable = /bin/dateTransfer_Executable = falseglobusscheduler = beowulf2.dartmouth.edu/jobmanager-forkuniverse = gridoutput = date.outerror=date.errorlog = date.logqueue

Next submit the job to Condor and checks for the job to complete


sierra:~> condor_submit example1.submit
Submitting job(s).
Logging submit event(s).
1 job(s) submitted to cluster 10.
sierra:~> condor_q -globus

-- Submitter: sierra.dartmouth.edu : <129.170.16.93:32921> : sierra.dartmouth.edu
 ID      OWNER          STATUS  MANAGER  HOST                EXECUTABLE

  10.0   sas           SUBMITTED fork     beowulf2.dartmouth  /bin/date


sierra:~> condor_q -globus

-- Submitter: sierra.dartmouth.edu : <129.170.16.93:32921> : sierra.dartmouth.edu
 ID      OWNER          STATUS  MANAGER  HOST                EXECUTABLE

   10.0   sas           ACTIVE  fork     beowulf2.dartmouth  /bin/date

sierra:~> condor_q -globus

-- Submitter: sierra.dartmouth.edu : <129.170.16.93:32921> : sierra.dartmouth.edu
 ID      OWNER          STATUS  MANAGER  HOST                EXECUTABLE

   10.0   sas           DONE  fork     beowulf2.dartmouth   /bin/date

sierra:~> condor_history
 ID      OWNER            SUBMITTED     RUN_TIME ST   COMPLETED CMD

  10.0   sas             3/24 14:32     0+00:00:00 C   ???      /bin/date

Condor-G Example 2 - Stage An Executable and Specify Inputs

In this exampl e we will submit a job that runs a user-supplied application that requires two command line arguments. Condor will need to transfer the application to the grid computer.

Build the application for correct architecture
Use of Static vs. Shared Libraries

Create a Condor submit file called example2.submit and which contains the following lines:

executable = myapp
arguments= George 90
Transfer_Executable = true
globusscheduler = beowulf2.dartmouth.edu/jobmanager-fork
universe = globus
output = myapp.out
error=myapp.error
log = myapp.log
queue

Next check the libraries required by the application, submit the job to Condor and wait for the job to complete


sierra:~> ldd myapp
        libm.so.6 => /lib64/tls/libm.so.6 (0x0000002a95683000)
        libc.so.6 => /lib64/tls/libc.so.6 (0x0000002a9580b000)
        /lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x0000002a95556000)

sierra:~> condor_submit example2.submit
Submitting job(s).
Logging submit event(s).
1 job(s) submitted to cluster 12.
sierra:~> condor_q -globus

-- Submitter: sierra.dartmouth.edu : <129.170.16.93:32921> : sierra.dartmouth.edu
 ID      OWNER          STATUS  MANAGER  HOST                EXECUTABLE

  12.0   sas           SUBMITTED fork     beowulf2.dartmouth  /home/sas/myapp


sierra:~> condor_q -globus

-- Submitter: sierra.dartmouth.edu : <129.170.16.93:32921> : sierra.dartmouth.edu
 ID      OWNER          STATUS  MANAGER  HOST                EXECUTABLE

   12.0   sas           ACTIVE  fork     beowulf2.dartmouth  /home/sas/myapp

sierra:~> condor_q -globus

-- Submitter: sierra.dartmouth.edu : <129.170.16.93:32921> : sierra.dartmouth.edu
 ID      OWNER          STATUS  MANAGER  HOST                EXECUTABLE

   12.0   sas           DONE  fork     beowulf2.dartmouth   /home/sas/myapp

sierra:~> cat myapp.out
Hi George. The sine of 90 is 1

Condor-G Example 3 - Stage An Executable and Input Files, Retrive Output Files

In this example we will submit a job that runs a user-supplied application that requires an input file and writes an output file.
We will use uberftp to transfer the input file to the computer and retrive the file after the program has run.

Create a Condor submit file called example3.submit which contains the following lines:

executable = test-input-file arguments= number-list Transfer_Executable = true globusscheduler = beowulf2.dartmouth.edu/jobmanager universe = grid remote_initialdir=/home/grid1/grid-class/sas output = test-input-file.out error=test-input-file.error log = test-input-file.log queue

Next compile the application, ftp the input file, submit the job to Condor, wait for the job to complete, ftp the output file back

to your computer.


sierra:~> gcc -m32 -static -o test-input-file test-input-file.c
sierra:~/Testing/VDT> file test-input-file
test-input-file: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5,
statically linked, not stripped
sierra:> uberftp beowulf2.dartmouth.edu "mkdir grid-class/sas; cd grid-class/sas; put number-list"
220 beowulf2.dartmouth.edu GridFTP Server 1.17 CAS/SAML enabled GSSAPI type Globus/GSI wu-2.6.2 (gcc32dbg, 1083879869-52) ready.
230 User grid1 logged in.
521 "/home/grid1/grid-class/sas" directory exists
250 CWD command successful.
150 Opening BINARY mode data connection.
226 Transfer complete.
Transfer rate 16 bytes in 0.04 seconds. 0.40 KB/sec
sierra:~> condor_submit example3.submit
Submitting job(s).
Logging submit event(s).
1 job(s) submitted to cluster 19.
sierra:~/Testing/VDT> condor_q -globus


-- Submitter: sierra.dartmouth.edu : <129.170.16.93:33505> : sierra.dartmouth.edu
 ID      OWNER          STATUS  MANAGER  HOST                EXECUTABLE
  19.0   sas           UNSUBMITTED fork     beowulf2.dartmouth  /afs/northstar.dar
sierra:~> condor_q -globus


-- Submitter: sierra.dartmouth.edu : <129.170.16.93:33505> : sierra.dartmouth.edu
 ID      OWNER          STATUS  MANAGER  HOST                EXECUTABLE
  19.0   sas           ACTIVE fork     beowulf2.dartmouth  /afs/northstar.dar
sierra:~> condor_q -globus


-- Submitter: sierra.dartmouth.edu : <129.170.16.93:33505> : sierra.dartmouth.edu
 ID      OWNER          STATUS  MANAGER  HOST                EXECUTABLE
  19.0   sas           DONE fork     beowulf2.dartmouth  /afs/northstar.dar
sierra:~> uberftp beowulf2.dartmouth.edu "cd grid-class/sas; get number-list.output"
220 beowulf2.dartmouth.edu GridFTP Server 1.17 CAS/SAML enabled GSSAPI type Globus/GSI wu-2.6.2 (gcc32dbg, 1083879869-52) ready.
230 User grid1 logged in.
250 CWD command successful.
150 Opening BINARY mode data connection.
226 Transfer complete.
Transfer rate 59 bytes in 0.03 seconds. 1.81 KB/sec

sierra:~> more number-list.output
The sum of the numbers in file: number-list is 123.450005

Condor-G Example 4 - Multiple Runs of a Program With Different Inputs

In this example we will submit multiple jobs that run the same program but use different input values

Create a Condor submit file called example4.submit and which contains the following lines:

executable = myappTransfer_Executable = trueglobusscheduler = beowulf2.dartmouth.edu/jobmanager-forkuniverse = globusoutput = myapp.$(Process).outerror=myapp.$(Process).errorlog = myapp.$(Process).logarguments= George 90queuearguments= Jane 45queuearguments= Robert 30queue

Next check the libraries required by the application, submit the job to Condor and wait for the job to complete


sierra:~> condor_submit example4.submit
Submitting job(s)...
Logging submit event(s)...
3 job(s) submitted to cluster 20.
sierra:~> condor_q -globus


-- Submitter: sierra.dartmouth.edu : <129.170.16.93:33505> : sierra.dartmouth.edu
 ID      OWNER          STATUS  MANAGER  HOST                EXECUTABLE
  20.0   sas           UNSUBMITTED pbs      beowulf2.dartmouth  /afs/northstar.dar
  20.1   sas           UNSUBMITTED pbs      beowulf2.dartmouth  /afs/northstar.dar
  20.2   sas           UNSUBMITTED pbs      beowulf2.dartmouth  /afs/northstar.dar
sierra:~> condor_q -globus


-- Submitter: sierra.dartmouth.edu : <129.170.16.93:33505> : sierra.dartmouth.edu
 ID      OWNER          STATUS  MANAGER  HOST                EXECUTABLE
  20.0   sas           PENDING  pbs      beowulf2.dartmouth  /afs/northstar.dar
  20.1   sas           PENDING  pbs      beowulf2.dartmouth  /afs/northstar.dar
  20.2   sas           PENDING  pbs      beowulf2.dartmouth  /afs/northstar.dar

sierra:~> condor_q -globus


-- Submitter: sierra.dartmouth.edu : <129.170.16.93:33505> : sierra.dartmouth.edu
 ID      OWNER          STATUS  MANAGER  HOST                EXECUTABLE
  20.0   sas           DONE     pbs      beowulf2.dartmouth  /afs/northstar.dar
  20.1   sas           DONE     pbs      beowulf2.dartmouth  /afs/northstar.dar
  20.2   sas           DONE     pbs      beowulf2.dartmouth  /afs/northstar.dar

sierra:~> ls -l myapp.*.err
ls: No match.
sierra:~> ls -l myapp.*.error
-rw-r--r--    1 sas      users           0 Apr  1 13:34 myapp.0.error
-rw-r--r--    1 sas      users           0 Apr  1 13:34 myapp.1.error
-rw-r--r--    1 sas      users           0 Apr  1 13:34 myapp.2.error
sierra:~> ls -l myapp.*.out
-rw-r--r--    1 sas      users          32 Apr  1 13:34 myapp.0.out
-rw-r--r--    1 sas      users          37 Apr  1 13:34 myapp.1.out
-rw-r--r--    1 sas      users          34 Apr  1 13:34 myapp.2.out
sierra:~/Testing/VDT> more myapp.*.out
::::::::::::::
myapp.0.out
::::::::::::::
Hi George. The sine of 90 is 1
::::::::::::::
myapp.1.out
::::::::::::::
Hi Jane. The sine of 45 is 0.707107
::::::::::::::
myapp.2.out
::::::::::::::
Hi Robert. The sine of 30 is 0.5

Condor-G Example 5 - Run Matlab

In this example we will submit a script file called 'run-matlab' which runs matlab on an m-file called 'sinewave.m'.

Create a Condor submit file called example5.submit and which contains the following lines:

Transfer_Executable = true executable=run_matlab remote_initialdir=/home/grid1/grid-class/sas globusscheduler = beowulf2.dartmouth.edu/jobmanager universe = grid output = run_matlab.out error=run_matlab.error log = run_matlab.log queue

Before submitting the job to Condor-G, we must transfer the m-file 'sinewave.m' to directory specified in the remote_initialdir directive in thge condor submit file.

polaris:/scratch/sas/grid-class/example5> uberftp beowulf2.dartmouth.edu
220 beowulf2.dartmouth.edu GridFTP Server 1.17 CAS/SAML enabled GSSAPI type Globus/GSI wu-2.6.2 (gcc32dbg, 1083879869-52) ready.
230 User grid1 logged in.
uberftp> pwd
257 "/home/grid1" is current directory.
uberftp> cd grid-class/sas
250 CWD command successful.
uberftp> put sinewave.m
150 Opening BINARY mode data connection.
226 Transfer complete.
Transfer rate 75 bytes in 0.04 seconds. 1.84 KB/sec
uberftp> quit
polaris:/scratch/sas/grid-class/example5> condor_submit example5.submit
Submitting job(s).
Logging submit event(s).
1 job(s) submitted to cluster 120.
polaris:/scratch/sas/grid-class/example5> condor_q -globus

-- Submitter: polaris.dartmouth.edu : <129.170.16.51:46252> : polaris.dartmouth.edu
 ID      OWNER          STATUS  MANAGER  HOST                EXECUTABLE
 120.0   sas           UNSUBMITTED fork     beowulf2.dartmouth  /scratch/sas/grid-class/example5/run-matlab 

polaris:/scratch/sas/grid-class/example5> condor_q -globus

-- Submitter: polaris.dartmouth.edu : <129.170.16.51:46252> : polaris.dartmouth.
edu
 ID      OWNER          STATUS  MANAGER  HOST                EXECUTABLE
 120.0   sas           ACTIVE fork     beowulf2.dartmouth  /scratch/sas/grid-class/example5/run-matlab

polaris:/scratch/sas/grid-class/example5> condor_q -globus

-- Submitter: polaris.dartmouth.edu : <129.170.16.51:46252> : polaris.dartmouth.
edu
 ID      OWNER          STATUS  MANAGER  HOST                EXECUTABLE
 120.0   sas           DONE fork     beowulf2.dartmouth  /scratch/sas/grid-class/example5/run-matlab

Condor-G Example 6- Run An MPI Parallel Program

In this example we will submit an MPI program and run it on 4 processors.

Create a Condor submit file called example6.submit which contains the following lines:

executable = monte_pi_mpi globusscheduler = beowulf2.dartmouth.edu/jobmanager universe = globus Arguments ='100000' output = monte_pi.out error = monte_pi.error log = monte_pi.log globusrsl=(jobType=mpi) (count=4) queue

sierra:~>condor_submit example6.submit
Submitting job(s). 
Logging submit event(s).
1 job(s) submitted to cluster 21.

sierra:~/Testing/VDT> condor_q -globus


-- Submitter: sierra.dartmouth.edu : <129.170.16.93:33505> : sierra.dartmouth.edu
 ID      OWNER          STATUS  MANAGER  HOST                EXECUTABLE
  21.0   sas           PENDING fork     beowulf2.dartmouth  /afs/northstar.dar

sierra:~> more monte_pi.out

 rank = 2, # of iterations is 1000000
 Processor 2 sending results= 785266 to master process
 rank = 3, # of iterations is 1000000
 Processor 3 sending results= 785040 to master process
 rank = 1, # of iterations is 1000000
 Processor 1 sending results= 785506 to master process
 rank = 0, # of iterations is 1000000

 # of trials= 4000000 , estimate of pi is 3.14173

Condor-G Example7 - Run A DAGMan Example

DAG - Directed Acyclic Graph
Programs are interdependent and must run in a certain order
Programs are Nodes on Graph
Edges Identify the Dependencies
DAGMan - Directed Acyclic Graph Manager

There is a DAGMAN submit file called mydag.dag which contains the following lines and describes
a DAG :
Job Setup setup.submit Job WorkerNode_1 run1.submit Job WorkerNode_2 run2.submit Job WorkerNode_3 run3.submit Job Finalize finalize.submit PARENT Setup CHILD WorkerNode_1 WorkerNode_2 WorkerNode_3 PARENT WorkerNode_1 WorkerNode_2 WorkerNode_3 CHILD Finalize
There are Condor submit files for each part of the DAG. The file setup.submit looks like this:executable = setup Transfer_Executable = true globusscheduler = beowulf2.dartmouth.edu/jobmanager universe = grid output = setup.out error=setup.error log = setup.log queue
Create run1.submit, run2.submit, run3.submit and finalize.submit. They will look like setup.submit
except they will replace submit by run1, run2, etc. Here is what run1.submit will look like:

executable = run1 Transfer_Executable = true globusscheduler = beowulf2.dartmouth.edu/jobmanager universe = grid output = run1.out error=run1.error log = run1log queue

sierra:~> more setup.submit
executable = setup
Transfer_Executable = true
globusscheduler = beowulf2.dartmouth.edu/jobmanager
universe = globus
output = setup.out
error=setup.error
log = setup.log
queue
sierra:~>condor_submit_dag mydag.dag

sierra:/scratch/sas/VDT/DAG_example> condor_q


-- Submitter: sierra.dartmouth.edu : <129.170.16.93:37147> : sierra.dartmouth.edu
 ID      OWNER            SUBMITTED     RUN_TIME ST PRI SIZE CMD
  74.0   sas             5/3  15:36   0+00:00:26 R  0   2.6  condor_dagman -f -
  75.0   sas             5/3  15:36   0+00:00:01 C  0   0.0  setup

1 jobs; 0 idle, 1 running, 0 held

sierra:/scratch/sas/VDT/DAG_example> condor_q


-- Submitter: sierra.dartmouth.edu : <129.170.16.93:37147> : sierra.dartmouth.edu
 ID      OWNER            SUBMITTED     RUN_TIME ST PRI SIZE CMD
  74.0   sas             5/3  15:36   0+00:00:36 R  0   2.6  condor_dagman -f -
  76.0   sas             5/3  15:37   0+00:00:00 I  0   0.0  run1
  77.0   sas             5/3  15:37   0+00:00:00 I  0   0.0  run2
  78.0   sas             5/3  15:37   0+00:00:00 I  0   0.0  run3
sierra:/scratch/sas/VDT/DAG_example> condor_q


-- Submitter: sierra.dartmouth.edu : <129.170.16.93:37147> : sierra.dartmouth.edu
 ID      OWNER            SUBMITTED     RUN_TIME ST PRI SIZE CMD
  74.0   sas             5/3  15:36   0+00:01:04 R  0   2.6  condor_dagman -f -
  76.0   sas             5/3  15:37   0+00:00:01 C  0   0.0  run1
  77.0   sas             5/3  15:37   0+00:00:00 C  0   0.0  run2
  78.0   sas             5/3  15:37   0+00:00:01 C  0   0.0  run3
  79.0   sas             5/3  15:37   0+00:00:00 I  0   0.0  finalize

sierra:/scratch/sas/VDT/DAG_example> condor_q


-- Submitter: sierra.dartmouth.edu : <129.170.16.93:37147> : sierra.dartmouth.edu
 ID      OWNER            SUBMITTED     RUN_TIME ST PRI SIZE CMD
  76.0   sas             5/3  15:37   0+00:00:01 C  0   0.0  run1
  77.0   sas             5/3  15:37   0+00:00:00 C  0   0.0  run2
  78.0   sas             5/3  15:37   0+00:00:01 C  0   0.0  run3
  79.0   sas             5/3  15:37   0+00:00:00 C  0   0.0  finalize

0 jobs; 0 idle, 0 running, 0 held

sierra:/scratch/sas/VDT/DAG_example> more setup.out
Program /home/grid1/.globus/.gass_cache/local/md5/96/207e9f53e87feadf3a56685588c998/md5/6d/d401fa98af43ef66bce4d45d7b47dc/data  
running on beowulf2 at Tue May  3 15:37:07 2005.

sierra:/scratch/sas/VDT/DAG_example> more run1.out
Program /home/grid1/.globus/.gass_cache/local/md5/09/8dd5cf2546294a0db47f933a21f7a4/md5/65/519da3da90171ce2cb1edb2ba85ac9/data 
running on beowulf2 at Tue May  3 15:37:33 2005.

1.	Overview of Grid Computing
2.	Grid Computing at Dartmouth
3.	Dartmouth Grid Catalog
4.	Advantages and Disadvantages of Grid Computing
5.	Diagram of Grid Hardware
6.	Globus Overview
7.	Diagram of Grid Software
8.	Overview of Globus GSI Security
9.	How to Get a Certificate
10.	How to Get A Globus Proxy Certificate
11.	Sample Globus Job Run
12.	Globus GridFTP
13.	Overview of Condor-G Examples
14.	Simple Condor-G Example
15.	Condor-G Example2 - stage an application requiring inputs
16.	Condor-G Example3 - stage an application and input files
17.	Condor-G Example4 - Multiple Runs of a Program
18.	Condor-G Example5 - Run Matlab
19.	Condor-G Example 6 - Run An MPI Parallel Program
20.	Condor-G Example6- Run A DAG EXample
21.	Acknowledgements and Resources

Getting Started with the Grid at Dartmouth

Course Handout: (last update Wednesday, 08-Jun-2005 12:10:04 EDT)

Getting Started On The Dartmouth Computational Grid

Topics Covered

What is Grid Computing

The Grid at Dartmouth

Dartmouth Grid Catalog

Advantages/ Disadvantage of Grid Computing

Grid Hardware View