User's Guide 5.8

GridWay enables you to treat your jobs as if they were Unix processes. Each job is given a numerical identifier, analogous to the PID of a process. This value is called the Job identifier, JID for short. If the job belongs to an array job, it will also have an array identifier, AID for short. A job index within an array is called the task identifier, TID for short.

Jobs are submitted using the gwsubmit command. A job is described by its template file. Here you can specify the job's executable file, its command line arguments, input/output files, standard stream redirection as well as other aspects.

Jobs can be monitored using the gwps command. You can control your jobs at runtime using the gwkill command. You can synchronize your jobs using the gwwait command. You can find out what resources your job has used with the gwhistory command.

System monitoring commands allow you to gather information of the GridWay system and the grids you are using. These commands are: gwuser to show information about the users using GridWay; gwhost to monitor the available hosts in the testbed; and gwacct to print usage (accounting) information per user or host.

A job can be in one of the following dispatch states (DM state):

• Pending (pend): The job is waiting for a resource to run on. The job reaches this state when it is initially submitted by the user or when it is restarted after a failure, stop or self-migration.
• Hold (hold): The owner (or GridWay administrator) has held the job. It will not be scheduled until it receives a release signal.
• Prolog (prol): The job is preparing the remote system, by creating the execution directory in the remote host and transferring the input and restart (in case of migration) files to it.
• Pre-wrapper (prew): The job is making some advanced preparation tasks in the remote resource, like getting some data from a service, obtaining software licenses, etc.
• Wrapper (wrap): The job is executing the Wrapper, which in turns executes the actual application. It also starts a self-monitoring program if specified. This monitor, watches the raw performance (CPU usage) obtained by the application.
• Epilog (epil): The job is finalizing. In this phase it transfers the output and restart (in case of failure, stop or self-migration) files and cleaning up the remote system directory.
• Migrate (migr): The job is migrating from one resource to another, by canceling the execution of Wrapper and performing finalization tasks in the old resource (like in Epilog state) and preparation tasks in the new resource (like in Prolog state).
• Stopped (stop): The job is stopped. If restart files have been defined in the Job Template, they are transferred back to the client, and will be used when the job is resumed.
• Failed (fail): The job failed.
• Done (done): The job is done and the user can check the exit status.

Figure 1. Simplified state machine of the GridWay Metascheduler.

When a job is in Wrapper dispatch state, it can be in one of the following execution states (EM state):

• Pending (pend): The job has been successfully submitted to the local DRM system and it is waiting for the local DRM system to execute it.
• Suspended (susp): The job has been suspended by the local DRM system.
• Active (actv): The job is being executed by the local DRM system
• Failed (fail): The job failed.
• Done (done): The job is done.

In order to obtain a reasonable degree of both application performance and fault tolerance, a job must be able to adapt itself according to the availability of the resources and the current performance provided by them. Therefore, the classical application model must be extended to achieve such functionality.

The GridWay system assumes the following application model:

• Executable: The executable must be compiled for the remote host architecture. GridWay provides a straightforward method to select the appropriate executable for each host. The variable GW_ARCH, as provided by the Information MAD, can be used to define the executable in the Job Template (for example, EXECUTABLE=sim_code.${GW_ARCH})
• Input files: These files are staged to the remote host. GridWay provides a flexible way to specify input files and supports Parameter Sweep like definitions. Please note that these files may be also architecture dependent.
• Output files: These files are generated on the remote host and transferred back to the client once the job has finished.
• Standard streams: The standard input (STDIN) file is transferred to the remote system previous to job execution. Standard output (STDOUT) and standard error (STDERR) streams are also available at the client once the job has finished. These files could be extremely useful for debugging.
• Restart files: Restart files are highly advisable if dynamic scheduling is performed. User-level checkpointing managed by the programmer must be implemented because system-level checkpointing is not possible among heterogeneous resources.

Migration is commonly implemented by restarting the job on the new candidate host. Therefore, the job should generate restart files at regular intervals in order to restart execution from a given point. However, for some application domains the cost of generating and transferring restart files could be greater than the saving in compute time due to checkpointing. Hence, if the checkpointing files are not provided the job is restarted from the beginning. In order not to reduce the number of candidate hosts where a job can migrate, the restart files should be architecture independent.

In order to set the user environment, follow these steps:

• 1. Set up the user environment for the middleware used. If Globus is used:

  $ source $GLOBUS_LOCATION/etc/globus-user-env.sh

  or

  $ . $GLOBUS_LOCATION/etc/globus-user-env.csh

  depending on the shell you are using.
• 2. Set up the GridWay user environment:

  $ export GW_LOCATION=<path_to_GridWay_installation>
  $ export PATH=$PATH:$GW_LOCATION/bin 

  or

  $ setenv GW_LOCATION <path_to_GW_location>
  $ setenv PATH $PATH:$GW_LOCATION/bin

  depending on the shell you are using
• 3. Optionally, you can set up your environment to use the GridWay DRMAA library:

  $ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$GW_LOCATION/lib

  or:

  $ setenv LD_LIBRARY_PATH $LD_LIBRARY_PATH:$GW_LOCATION/lib

• 4. If GridWay has been compiled with accounting support, you may need to set up the DB library. For example, if DB library has been installed in /usr/local/BerkeleyDB.4.4:

  $ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/BerkeleyDB.4.4/lib

• 5. DRMAA extensions for all the languages use the dynamic drmaa libraries provided by GridWay. To use this libraries it is needed to tell the operating system where to look for them. Here are described the steps needed to do this in Linux and MacOS X.
  • 1. In linux we have two ways to do this, one is using environment variables and the other one is modifying systemwide library path configuration. You only need to use one of this methods. If you do not have root access to the machine you are using or you do not want to setup it for every user in your system you have to use the environment variable method.
  • 1.1 The environment variable you have to set so the extensions find the required DRMAA library is LD_LIBRARY_PATH with a line similar to:

    $ export LD_LIBRARY_PATH=$GW_LOCATION/lib

    If you want to setup this systemwide you can put this line alongside GW_LOCATION setup into /etc/profile. If you do not have root access or you want to do it per user the best place to do it is in the user's .bashrc.You can also do this steps in the console before launching your scripts as it will have the same effect.
  • Systems that use GNU/libc (GNU/Linux is one of them) do have a systemwide configuration file with the paths where to look for dynamic libraries. You have to add this line to /etc/ld.so.conf:

    <path_to_gridway_installation>/lib

    After doing this you have to rebuild the library cache issuing this command:

    # ldconfig

• In MacOS X you have to use the environment variable method described for Linux but this time the name of the variable is DYLD_LIBRARY_PATH.

Job Templates allow you to configure your job requirements, in terms of needed files, generated files, requirements and ranks of execution hosts, as well as other options.

Syntax:

  <VARIABLE> = ["]<VALUE>["]
  # <Comments>

Table 1. Job Template options.

  #This file was automatically generated by the JSDL2GWJT parser
  EXECUTABLE=/bin/ls
  ARGUMENTS=-la file.txt
  STDIN_FILE=/dev/null
  STDOUT_FILE=stdout.${JOB_ID}
  STDERR_FILE=stderr.${JOB_ID}
  ENVIRONMENT=LD_LIBRARY_PATH=/usr/local/lib
  REQUIREMENTS=HOSTNAME="*.dacya.ucm.es" & ARCH="x86_32"
  INPUT_FILES=file.txt

This example shows the representation of a HPC profile job in JSDL format and the translator of this example in GridWay Job Template format.

  <?xml version="1.0" encoding="UTF-8"?>
 
  <jsdl:JobDefinition xmlns="http://www.example.org/"
      xmlns:jsdl="http://schemas.ggf.org/jsdl/2005/11/jsdl"
      xmlns:jsdl-posix="http://schemas.ggf.org/jsdl/2005/11/jsdl-posix"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <jsdl:JobDescription>
      <jsdl:JobIdentification>
        <jsdl:JobName>Simple Application GW Template vs JSDL</jsdl:JobName>
        <jsdl:Description> This is a simple example to describe the main
               differences between GW Template and the JSDL schema.
        </jsdl:Description>
      </jsdl:JobIdentification>
      <jsdl:Application>
        <jsdl:ApplicationName>ls</jsdl:ApplicationName>
        <jsdl-hpcpa:HPCProfileApplication>
          <jsdl-hpcpa:Executable>/bin/ls</jsdl-hpcpa:Executable>
          <jsdl-hpcpa:Argument>-la file.txt</jsdl-hpcpa:Argument>
          <jsdl-hpcpa:Environment name="LD_LIBRARY_PATH">/usr/local/lib</jsdl-hpcpa:Environment>
          <jsdl-hpcpa:Input>/dev/null</jsdl-hpcpa:Input>
          <jsdl-hpcpa:Output>stdout.${JOB_ID}</jsdl-hpcpa:Output>
          <jsdl-hpcpa:Error>stderr.${JOB_ID}</jsdl-hpcpa:Error>
        </jsdl-hpcpa:HPCProfileApplication>
      </jsdl:Application>
      <jsdl:Resources>
        <jsdl:CandidateHost>
          <jsdl:HostName>*.dacya.ucm.es</jsdl:HostName>
        </jsdl:CandidateHost>
        <jsdl:CPUArchitecture>
          <jsdl:CPUArchitectureName>x86_32</jsdl:CPUArchitectureName>
        </jsdl:CPUArchitecture>
      </jsdl:Resources>
      <jsdl:DataStaging>
        <jsdl:FileName>file.txt</jsdl:FileName>
        <jsdl:CreationFlag>overwrite</jsdl:CreationFlag>
        <jsdl:DeleteOnTermination>true</jsdl:DeleteOnTermination>
        <jsdl:Source>
          <jsdl:URI>gsiftp://hydrus.dacya.ucm.es/home/jose/file1.txt</jsdl:URI>
        </jsdl:Source>
      </jsdl:DataStaging>
      <jsdl:DataStaging>
        <jsdl:FileName>stdout.${JOB_ID}</jsdl:FileName>
        <jsdl:CreationFlag>overwrite</jsdl:CreationFlag>
        <jsdl:DeleteOnTermination>true</jsdl:DeleteOnTermination>
        <jsdl:Target>
          <jsdl:URI>gsiftp://hydrus.dacya.ucm.es/home/jose/stdout.${JOB_ID}</jsdl:URI>
        </jsdl:Target>
      </jsdl:DataStaging>
      <jsdl:DataStaging>
        <jsdl:FileName>stderr.${JOB_ID}</jsdl:FileName>
        <jsdl:CreationFlag>overwrite</jsdl:CreationFlag>
        <jsdl:DeleteOnTermination>true</jsdl:DeleteOnTermination>
        <jsdl:Target>
          <jsdl:URI>gsiftp://hydrus.dacya.ucm.es/home/jose/stderr.${JOB_ID}</jsdl:URI>
        </jsdl:Target>
      </jsdl:DataStaging>
    </jsdl:JobDescription>
  </jsdl:JobDefinition>

  #This file was automatically generated by the JSDL2GWJT parser
  EXECUTABLE=/bin/ls
  ARGUMENTS=-la file.txt
  STDIN_FILE=/dev/null
  STDOUT_FILE=stdout.${JOB_ID}
  STDERR_FILE=stderr.${JOB_ID}
  ENVIRONMENT=LD_LIBRARY_PATH=/usr/local/lib
  REQUIREMENTS=HOSTNAME="*.dacya.ucm.es" & ARCH="x86_32"
  INPUT_FILES=file.txt

GWD should be configured and running. Check the Installation Guide and Configuration Guide to do that. Do not forget to create a proxy with grid-proxy-init

To submit a job, you will need a Job Template. The most simple Job Template in GridWay could be:

EXECUTABLE=/bin/ls

Save it as file jt in directory example.

Use the gwsubmit command to submit the job:

$ gwsubmit -t example/jt

Let see how many resources are available in our grid, with gwhost:

  $ gwhost
  HID PRIO OS              ARCH   MHZ %CPU MEM(F/T)     DISK(F/T)  N(U/F/T) LRMS  HOSTNAME
  0   1    Linux2.6.17-2-6 x86   3215  100 923/2027 105003/118812     0/1/2 Fork  cygnus.dacya.ucm.es
  1   1    Linux2.6.17-2-6 x86   3216  189 384/2027 105129/118812     0/2/2 Fork  draco.dacya.ucm.es
  2   1    Linux2.6.18-3-a x86_6 2211  100 749/1003   76616/77844     0/2/2 SGE   aquila.dacya.ucm.es
  3   1                             0    0      0/0           0/0     0/0/0       hydrus.dacya.ucm.es
  4   1    Linux2.6.18-3-a x86_6 2009   74  319/878 120173/160796     0/1/1 Fork  orion.dacya.ucm.es
  5   1    Linux2.6.16.13- x86   3200  100  224/256       114/312     0/6/6 SGE   ursa.dacya.ucm.es

Note that hydrus is down in this example, so no information is received at all and of course, this host won't be considered in future scheduling decisions. If you want to retrieve more information about a single resource, issue the gwhost command followed by the host identification (HID):

  $ gwhost 0
  HID PRIO OS              ARCH   MHZ %CPU MEM(F/T)     DISK(F/T)  N(U/F/T) LRMS  HOSTNAME
  5   1    Linux2.6.16.13- x86   3200  100  224/256       114/312     0/6/6 SGE   ursa.dacya.ucm.es

  QUEUENAME            SL(F/T) WALLT CPUT  COUNT MAXR  MAXQ  STATUS   DISPATCH   PRIORITY
  all.q                6/6     0     0     0     6     0     enabled  NULL       0

You can also check the resources that match your requirements with gwhost -m 0.

  $ gwhost -m 0
  HID QNAME      RANK  PRIO  SLOTS HOSTNAME
  0   default    0     1     2     cygnus.dacya.ucm.es
  1   default    0     1     0     draco.dacya.ucm.es
  2   all.q      0     1     2     aquila.dacya.ucm.es
  4   default    0     1     1     orion.dacya.ucm.es
  5   all.q      0     1     6     ursa.dacya.ucm.es

Now, you can check the evolution of the job with the gwps command.

  $ gwps 
  USER  JID DM   EM   START    END      EXEC    XFER    EXIT NAME  HOST
  user  0   pend ---- 10:42:09 --:--:-- 0:00:00 0:00:00 --   jt    --

and in succesive states

  user  0   prol ---- 10:42:09 --:--:-- 0:00:00 0:00:01 --   jt    cygnus.dacya.ucm.es/Fork
  user  0   wrap ---- 10:42:09 --:--:-- 0:00:27 0:00:04 --   jt    cygnus.dacya.ucm.es/Fork
  user  0   wrap pend 10:42:09 --:--:-- 0:00:27 0:00:04 --   jt    cygnus.dacya.ucm.es/Fork
  user  0   wrap actv 10:42:09 --:--:-- 0:00:27 0:00:04 --   jt    cygnus.dacya.ucm.es/Fork
  user  0   epil ---- 10:42:09 --:--:-- 0:00:31 0:00:05 --   jt    cygnus.dacya.ucm.es/Fork
  user  0   done ---- 10:42:09 10:43:01 0:00:31 0:00:08 0    jt    cygnus.dacya.ucm.es/Fork

At the beginning, the job is in pending state and not allocated to any resource. Then, the job is allocated to cygnus.dacya.ucm.es/Fork and begins the prolog stage.

You can see the job history with the gwhistory command:

  $ gwhistory 0
  HID START    END      PROLOG  WRAPPER EPILOG  MIGR    REASON QUEUE    HOST
  0   10:42:22 10:43:01 0:00:04 0:00:31 0:00:04 0:00:00 ----   default  cygnus.dacya.ucm.es/Fork

Now it's time to retrieve the results. As you specified by default, the results of the execution of this job will be in the same folder, in a text file called sdtout_file.$JOB_ID.

  $ ls -lt example/
  total 8
  -rw-r--r-- 1 user staff  0 2007-02-20 10:42 stderr.0
  -rw-r--r-- 1 user staff 72 2007-02-20 10:42 stdout.0
  -rw-r--r-- 1 user staff 19 2007-02-20 10:33 jt
  $ cat example/stdout.0
  job.env
  stderr.execution
  stderr.wrapper
  stdout.execution
  stdout.wrapper

Done! You have done your first execution with GridWay!

This is a well known exercise. For our purposes, we will calculate the integral of the following function:

Being f(x) = 4/(1+x2). So, π will be the integral of f(x) in the interval [0,1].

In order to calculate the whole integral, it's interesting to divide the function in several sections and compute them separately:

As you can see, the more sections you make, the more exact π will be:

So, you have a grid with some nodes, you have GridWay… Why don't use them to calculate the π number by giving all the nodes a section to compute with only one command?

For this example, we have chosen the C Programming Language. Create a text file called pi.c and copy inside the following lines:

  #include <stdio.h>
  #include <string.h>
 
  int main (int argc, char** args)
  {
    int task_id;
    int total_tasks;
    long long int n;
    long long int i;
 
    double l_sum, x, h;
 
    task_id = atoi(args[1]);
    total_tasks = atoi(args[2]);
    n = atoll(args[3]);
 
    fprintf(stderr, "task_id=%d total_tasks=%d n=%lld\n", task_id, total_tasks, n);
 
    h = 1.0/n;
 
    l_sum = 0.0;
 
    for (i = task_id; i < n; i += total_tasks)
    {
      x = (i + 0.5)*h;
      l_sum += 4.0/(1.0 + x*x);
    }
 
    l_sum *= h;
 
    printf("%0.12g\n", l_sum);
 
    return 0;
  }

Now it's time to compile it:

$ gcc -O3 pi.c -o pi

after this, you should have an executable called pi. This command receives three parameters:

• Task identifier: The identifier of the current task.
• Total tasks: The number of tasks the computation should be divided into.
• Number of intervals: The number of intervals over which the integral is being evaluated.

For making GridWay work with your program, you must create a Job Template. In this case, we will call it pi.jt. Copy the following lines inside:

  EXECUTABLE  = pi
  ARGUMENTS   = ${TASK_ID} ${TOTAL_TASKS} 100000
  STDOUT_FILE = stdout_file.${TASK_ID}
  STDERR_FILE = stderr_file.${TASK_ID}
  RANK        = CPU_MHZ

This time, we will submit an array of jobs. This is done by issuing the following command:

  $ gwsubmit -v -t pi.jt -n 4
  ARRAY ID: 0

  TASK JOB
  0    0
  1    1
  2    2
  3    3

In order to wait for the jobs to complete, you can use the gwwait command.

The argument passed to gwwait is the array identifier given by gwsubmit when executed with the -v option. It could be also obtained through gwps

This command will block and return when all jobs have been executed:

  $ gwwait -v -A 0
  0   : 0
  1   : 0
  2   : 0
  3   : 0

This command, when issued with option -v shows the exit codes for each job in the array (usually, 0 means success).

The execution of these jobs has returned some output files with the result of each execution:

  stdout_file.0
  stdout_file.1
  stdout_file.2
  stdout_file.3

Now, we will need something to sum the results inside each file. For this, you can use an awk script like the following:

  $ awk 'BEGIN {sum=0} {sum+=$1} END {printf "Pi is %0.12g\n", sum}' stdout_file.*
  Pi is 3.1415926536

Well, not much precision, right? You could try it again, but this time with a much higher number of intervals (e.g. 10,000,000,000). Would you increment also the number of tasks? Which would be the best compromise?

Do you imagine how easy would be to implement these steps in a shell script in order to perform them unattendedly? Here you are the prove:

  #!/bin/sh
 
  AID=`gwsubmit -v -t pi.jt -n 4 | head -1 | awk '{print $3}'`
 
  if [ $? -ne 0 ]
  then
      echo "Submission failed!"
      exit 1
  fi
 
  gwwait -v -A $AID
 
  if [ $? -eq 0 ]
  then
      awk 'BEGIN {sum=0} {sum+=$1} END {printf "Pi is %0.12g\n", sum}' stdout_file.*
  else
      echo "Some tasks failed!"
  fi

When applications show fine-grain parallelism, with small computation to communication ratio, and thus need lower latencies, MPI (Message Passing Interface) jobs give a better choice.

Following the π example, we will now perform its computation using MPI in a single job. Notice that MPI jobs can also be part of an array or complex job.

Create a text file called mpi.c and copy inside the following lines:

  #include "mpi.h"
  #include <stdio.h>
  #include <math.h>
 
  int main( int argc, char *argv[])
  {
      int done = 0, n, myid, numprocs, i;
      double PI25DT = 3.141592653589793238462643;
      double mypi, pi, h, sum, x;
      double startwtime = 0.0, endwtime;
      int  namelen;
      char processor_name[MPI_MAX_PROCESSOR_NAME];
 
      MPI_Init(&argc,&argv);
      MPI_Comm_size(MPI_COMM_WORLD,&numprocs);
      MPI_Comm_rank(MPI_COMM_WORLD,&myid);
      MPI_Get_processor_name(processor_name,&namelen);
 
      printf("Process %d on %s\n", myid, processor_name);
 
      n = 100000000;
 
      startwtime = MPI_Wtime();
 
      h   = 1.0 / (double) n;
      sum = 0.0;
      for (i = myid + 1; i <= n; i += numprocs)
      {
          x = h * ((double)i - 0.5);
          sum += 4.0 / (1.0 + x*x);
      }
      mypi = h * sum;
 
      MPI_Reduce(&mypi, &pi, 1, MPI_DOUBLE, MPI_SUM, 0, MPI_COMM_WORLD);
 
      if (myid == 0)
      {
          printf("pi is approximately %.16f, Error is %.16f\n",
                 pi, fabs(pi - PI25DT));
          endwtime = MPI_Wtime();
          printf("wall clock time = %f\n", endwtime-startwtime);
      }
 
      MPI_Finalize();
 
      return 0;
  }

Notice that the above program already performs postprocessing in a single operand reduction operation MPI_Reduce which sums the partial results obtained by each processor.

Now it's time to compile it. Notice that you will need a compiler with MPI support like mpicc:

  $ mpicc -O3 mpi.c -o mpi

Now you must create a Job Template. In this case, we will call it “mpi.jt”:

  EXECUTABLE   = mpi
  STDOUT_FILE   = stdout.${JOB_ID}
  STDERR_FILE   = stderr.${JOB_ID}
  RANK          = CPU_MHZ
  TYPE          = "mpi"
  NP            = 2

The powerful commands provided by GridWay to submit, control and synchronize jobs allow us to programmatically define complex jobs or workflows, where some jobs need data generated by other jobs. GridWay allows job submission to be dependent on the completion of other jobs. This new functionality provides support for the execution of workflows.

GridWay allows scientists and engineers to express their computational problems by using workflows. The capture of the job exit code allows users to define workflows, where each task depends on the output and exit code from the previous task. They may even involve branching, looping and spawning of subtasks, allowing the exploitation of the parallelism on the workflow of certain type of applications. The bash script flow control structures and the GridWay commands allow the development of workflows with the following functionality:

• Sequence, parallelism, branching and looping structures
• The workflow can be described in an abstract form without referring to specific resources for task execution
• Quality of service constraints and fault tolerance are defined at task level

Job dependencies can be specified at submission by using the -d option of the gwsubmit command. A Job with dependencies will be submitted in the hold state, and once all the jobs on which it depends have successfully finished, it will be released. You can also release this job by hand with the gwkill.

A DAG-based workflow consists of a temporal relationship between tasks, where the input, output or execution of one ore more tasks depends on one or more other tasks. For this example we have chosen a simple workflow.

Figure 2. Workflow example.

In this example, job A generates a random number, jobs B and C add 1 to that number and, finally job D adds the result of these jobs. This is the final result is two times the number generated by A, plus two. In our case, the numbers are passed between jobs using the standard output files.

Job Template for job A (A.jt):

  EXECUTABLE=/bin/echo
  ARGUMENTS="$RANDOM"
  STDOUT_FILE=out.A

Job Template for jobs B and C (“B.jt” and “C.jt”):

  EXECUTABLE=/usr/bin/expr
  ARGUMENTS="`cat out.A`" + 1
  INPUT_FILES=out.A
  STDOUT_FILE=out.B #out.C for job C

Job Template for job D (“D.jt”):

  EXECUTABLE=/usr/bin/expr
  ARGUMENTS="`cat out.B`" + "`cat out.C`"
  INPUT_FILES=out.B, out.C
  STDOUT_FILE=out.workflow

Once you have set up the previous Job Templates, the workflow can be easily submitted with the following commands:

  $ gwsubmit -v -t A.jt
  JOB ID: 5

  $ gwsubmit -v -t B.jt -d "5"
  JOB ID: 6

  $ gwsubmit -v -t C.jt -d "5"
  JOB ID: 7

  $ gwsubmit -t C.jt -d "6 7"

The above steps can be easily implemented in a shell script.

  #!/bin/sh
 
  A_ID=`gwsubmit -v -t A.jt | cut -f2 -d':' | cut -f2 -d' '`
  B_ID=`gwsubmit -v -t B.jt -d "$A_ID" | cut -f2 -d':' | cut -f2 -d' '`
  C_ID=`gwsubmit -v -t C.jt -d "$A_ID" | cut -f2 -d':' | cut -f2 -d' '`
  D_ID=`gwsubmit -v -t D.jt -d "$B_ID $C_ID"| cut -f2 -d':' | cut -f2 -d' '`
 
  #Sync with last job of the workflow
  gwwait $D_ID
 
  echo "Random number `cat out.A`"
  echo "Workflow computation `cat out.workflow`"

Note that when input and output files vary depending on the iteration or job id number, you should generate Job Templates dynamically before submitting each job. This can be done programmatically by using the DRMAA API, or via shell scripting.

Alternatively you can describe DAG workflows using a file similar to the one used by Condor DAGMAN. In this case the dependencies are not managed by GW but by the gwdag tool. You only have to substitute Condor job descriptions with GridWay job templates. Here is a file describing the same DAG as the previous example:

  JOB  A  A.jt
  JOB  B  B.jt
  JOB  C  C.jt
  JOB  D  D.jt
  PARENT A CHILD B C
  PARENT B C CHILD D

To submit this job you only have to specify the file describing this DAG to gwdag tool:

  $ gwdag <name of the file>

You can also get a DOT file for a DAG description that you can use later to generate a graph showing the flow using -d flag:

  $ gwdag -d <name of the file> > <name of the dot file>

Figure 3. Dag graph generated by the gwdag tool.

GridWay reporting and accounting facilities provide information about overall performance and help debug job execution. GWD generates the following files under the $GW_LOCATION/var directory:

• gwd.log: System level log. You can find log information of the activity of the middleware access drivers; and a coarse-grain log information about jobs.
• $JOB_ID/job.log: Detailed log information for each job, it includes details of job state transitions, resource usage and performance.
• $JOB_ID/stdout.wrapper: Standard output of the wrapper executable.
• $JOB_ID/stderr.wrapper: Standard error output of the wrapper executable. By default, wrapper is executed with shell debugging options (-xv) active, so this is usually the best source of information in case of failure.

Currently, many errors are handled silently and are only shown in the job.log file.

Also, there is a number of failures related to the underlying middleware that could make some jobs fail. It is a good idea to perform some basic testing of the middleware when some jobs unexpectedly fail (check the Configuration Guide to learn how to verify a Globus installation).

Use the GridWay lists, to submit your problems and they will be eventually appear in this guide.