Custom Writing Service http://StudyHub.vip/Application-Parameter-Description-Schem 👈

1. Application Parameter Description Scheme for Multiple Job Generation
in Problem Solving Environment
Byungsang Kim, Dukyun Nam, Young-Kyoon Suh, June Hawk Lee,
Kumwon Cho, and Soonwook Hwang
e-Science Division,
Korea Institute of Science and Technology Information (KISTI)
52-11, Eoeun-dong, Yuseong-gu, Daejeon, 305-806, Korea
{bskim, dynam, yksuh, juneh, ckw, hwang}@kisti.re.kr
Abstract
In e-Science environments, scientists need to execute a
scientific application with various parameters multiple
times to simulate and experiment complicated
problems on the Grid. For this, they should write every
single job description with distinct parameters even if
this is a troublesome task. To provide the flexibility
and adaptability for parameter study, we propose an
Application Parameter Description Language (APDL)
and a service oriented parameter study scheme, called
a Parametric Study Service (PSS), for parameterized
simulations on the Grid. The APDL extends the Job
Submission Description Language (JSDL) to generate
parameters for multiple jobs. The proposed PSS
provides a unified interface to submit jobs into various
middleware platforms such as gLite, Globus, etc. The
Problem Solving Environment (PSE) assists a
parameter study for their applications and every
research fields tend to construct individual own PSE.,
The proposed PSS can be easily adapted into the
specific PSE because of being implemented as Web
Services. In practice, we apply the APDL and the PSS
into aerospace research PSE which carry out the
three-dimensional turbulent analysis for compressible
flow.
1. Introduction
e-Science paradigm intends to exploit shared
computing and storage resources on the Grids for
researchers to cooperate anytime and anywhere. The
paradigm makes it possible to simulate and experiment
complicated problems, which have never done before,
in the science area such as astrophysics, particle
physics, biology, chemistry, medical science and so on
[1, 2].
Parametric study, more formally known as
parameter value exploration on High Performance
Computing (HPC) [3] and High Throughput
Computing (HTC) [4], executes a scientific application
related to their parameters multiple times. Whenever
the application runs, it takes one or more parameter
values which differ from the previous execution. As
the problem complexity increases, the requirements are
more complex for the design refinement mechanism of
the application and the optimization mechanism of
parameter values. These mechanisms are used to
examine the characteristics of the applications and
change their parameters. If the application needs to run
atop the Grid, the requirements exponentially increase.
This is because the Grid environment is dynamic and
heterogeneous in nature. Therefore, to provide the
flexibility and adaptability for parameter study, the
Grid-aware description language and scheduler are
essential parts [5].
In this paper, we propose an Application Parameter
Description Language (APDL) and a service oriented
parameter study scheme which called as a Parametric
Study Service (PSS). The APDL extends the Job
Submission Description Language (JSDL) [6] and is a
XML schema which includes the specific way to
describe the parameters for scientific applications. A
proposed PSS provides users with the following merits.
First, the PSS can generate multiple-job descriptions
from a single APDL description. The APDL includes
arguments for multiple jobs in the remaining parts
excluding JSDL. Therefore, a user needs not write
every single description. Second, the PSS does not
require any specific interface for submitting jobs, but
Third IEEE International Conference on e-Science and Grid Computing
0-7695-3064-8/07 $25.00 © 2007 IEEE
DOI 10.1109/e-Science.2007.32
509

2. provides a unified interface. When a user tries to
submit a job described in APDL to various Grid
middleware platforms, the PSS converts the job
description into the corresponding job-submission-
related language, and then run the job via their native
submission interfaces. From the APDL, for example,
the PSS converts a Job Description Language (JDL)
and a Resource Script Language (RSL) in cases of
gLite [8] and Globus [9,10], respectively. Lastly, the
PSS can be adapted into the specific Problem Solving
Environments (PSEs) without any change. The PSE
assists parameter study for their applications. Thus
every research fields tend to construct individual own
PSE. However, the proposed PSS does not depend on
any specific PSE because it is implemented as Web
services. In practice, we show that the APDL and the
PSS are applied to Aerospace Integrated Research
System (e-AIRS) [11] which carry out the three-
dimensional turbulent analysis for compressible flow.
The remainder of the paper is organized as follows:
Section 2 discusses the existing approaches for
declarative languages and architectures related to
parameter study. Section 3 presents the service-
oriented parameter study scheme and Section 4
describes the proposed application parameter
description language and the parameter sweep
algorithms, respectively. The architecture and
implementation of PSS is presented in Section 5. We
show the case study applying the PSS into aerospace
research field in Section 6. A conclusion follows in
Section 7.
2. Related Work
The Job Submission Description Language (JSDL)
[6] is a standard recommendation as a job description
language to describe a job running on a Grid
environment [7]. The JSDL language includes a variety
of vocabularies and a formal XML Schema which
makes it possible to describe the expression and the
requirement of an application as a set of XML
elements. It is very powerful in that it provides formal
extension for expressing jobs or resources. Recently,
parameter sweep extension is proposed to utilize the
parameter sweep applications in Grid environment [6].
This extension attempts to normalize how parameter
sweep applications are defined in conjunction with
JSDL documents. However, it just handles simple
inserted arguments when an application is executed.
However, it does not deal with the parameters which
written in specific input-file forms for an application.
Nimrod [12] and Condor [4, 13], as systems
supporting the parameter sweep functionality, are
predominantly used in a Grid environment. They are
designed for the local cluster with a local scheduler.
Thus they do not consider input and output data
acquisition. The unified data location scheme needs to
be specified on the Grid environment because
parameter sweep applications generally accompany
with input data located in remote resources.
ILab [14] provides an integrated Graphical User
Interface (GUI) for manipulating and parameterizing
input file, launching jobs, monitoring progress and
managing output. Especially, it focuses on simplicity
of use, self-document, and flexible submission of jobs.
ILab can sweep the parameters which explicitly
described in input file on the modeling stage. It can
handle not only input parameters file, but data files
which are related to the input parameter. However, it
does not support argument types which are a general
form of a parameter. In addition, it does not consider
how to prepare and locate the parameterized input data
file. On a Grid environment, since input data should be
located on a remote site, not a local one, it is more
carefully managed by a data repository in order of
stage-in and stage-out of necessary data. Moreover
ILab does not consider how to adapting the other PSEs
and different infrastructures.
APST [15,16] system is a framework for easily and
efficiently developing, scheduling, and executing
large-scale parameter sweep applications on
Computational Grids. APST’s approach focuses on the
efficient co-location of data and experiments and
adaptive scheduling rather than developing user
interfaces. APST XML describes not only works to be
performed as part of an application, but the Grid
resources available to perform it. To put it another
way, APST XML gives a description of site-specific
executables or paths and provides relative estimation
on the priority of a user-submitting task and its
execution end time for scheduling. However, it does
not have an interest in supporting types each parameter
is able to take, on a purpose of automatic sweeping of
parameters. Also, it expresses only a static value for
each parameter as an attribute in a XML file and does
not support various options for the configuration of
each parameter.
3. Service Oriented Parameter Study
Scheme
To provide flexible parameter study on scientific
simulations, we proposed service oriented parameter
study scheme. The proposed Parametric study service
(PSS) focuses on following design issues.
510

3. Parameter Study Service
Input parameter
File Template
JSDL + APDL
Multiple Job Generation
Job Instance
Repository
GT2 GT4 gLite …
Application PSE
Job submission interfaces
Input Data
Preparation
Input File
Template Register
Parameter Study Service
Input parameter
File Template
JSDL + APDL
Multiple Job Generation
Job Instance
Repository
GT2 GT4 gLite …
Application PSE
Job submission interfaces
Input Data
Preparation
Input File
Template Register
Figure 1. Schematics of Parametric study service.
y Adaptability for PSEs
Many communities construct and utilize own PSE
for parameter sweep applications (PSAs) in HTC
domains or Grids. In order to support unified access for
describing application parameter, we propose service
oriented parameter study interface using Web Services
and an Application Parameter Description Language
(APDL) which makes it possible to define an
application specific parameter template and generate
parameter instances on run-time. Therefore, the
proposed approach is independent from specific PSE
and provides the adaptability for PSEs. The APDL
describes various type of parameters and their
attributes as well as flexible parameter sweep methods.
In Figure 1, an application PSE can request the
parameter sweep using APDL when choosing their job
and resource requirement with JSDL [6].
y Support for multiple job submission interfaces
For e-Science infrastructure, various Grid
middleware platforms are used for their applications
and exploit the own job-submission-related language.
For example, EGEE[17] have a gLite[8] and Job
Description Language (JDL) for job submission
interface. On the other hand, OSG[18], and
PRAGMA[19] use together with a Globus Toolkit
2(GT2)[9] and a Globus Toolkit 4 (GT4) [10] and
different version of Resource Script Language(RSL).
Job Submission Description Language (JSDL) is a
standard resource description format proposed by Open
Grid Forum (OGF). The proposed APDL extends the
JSDL. The proposed PSS internally converts the APDL
to various job submission languages such as JDL and
RSL.
y Support for various parameters and sweep
algorithms
Parameters can be represented by argument or
multiple input files of an application. Each parameter
of them has different data types such as float, integer or
character. Some kinds of parameters can be
parameterized but the other not. Moreover, various
kinds of sweep methods will need to obtain an
optimized set of parameters. The APDL can support
various types of parameters which are written by an
input file form as well as an argument form. In
addition, by using multiple kinds of sweeper
algorithms in it, users are able to acquire a more
flexible parameter set which they want.
y Integrated management for input data
Generally, parameter sweep applications entail
moving input data from and result data into remote
storage. Some data may be required by all jobs and
other may be taken as mutually exclusive input data
per job. Because those jobs are not executed at a local
or static site, all data that are represented by a certain
parameter should be globally identified in order that
they are transferred to an arbitrary location.
APDL uses data staging attributes for indicating the
requirement of the data transfer and makes it possible
to acquire a Uniform Resource Location (URL) for
accessing target data source.
4. Application Parameter Description
Language (APDL)
An APDL is an extension of the JSDL. APDL
mainly focuses on defining each parameter with native
attributes and their sweep methods for generating
parameter set.
4.1. Definition of Parameters and Parameter
Sweeper
Simply, a parameter represents as a pair of the name
and value. It includes on run-time as a form of an
argument or a specific input file. We define a
Parameter and a ParameterType for constructing its
data type.
Column vector Pi means the number of parameters
for an application.
0
1
i m
m
P
P
P
∈
 
 
 
=
 
 
 
 
P
#
(1)
where, m means the number of parameters for an
application and i is the index of the parameter. Each
parameter is represented by following elements in
APDL as a form of complex type.
511

4. // Name of this parameter
// Value of this parameter
// Data type of this parameter’s value
// whether this parameter is arg type
or input file type
// Unified input file location
// Unified data file location
// whether this parameter is needed
for transferring data
// whether this parameter is
mandatory
Figure 2. Data Structure of Application Parameter.
Figure 2 shows the data structure of Pi. A parameter
is represented by a name and a value with its data type.
We insert two kinds of elements for identifying its
input type and data preparation components. At first, If
a parameter input type is an input file then, this
parameter will be written within the pre-defined input
file. Otherwise, this parameter will be written within an
argument. In case of the preparation of the input data,
if this parameter is necessary for transferring data from
remote location, the target data should be moved
before execution of a job.
In addition, we define the Sweeper in order to
represent the instance of each parameter and a
SweepType so as to construct its data type.
Row vector Pm
means the discrete range of each
parameter value.
[ ]
0 1
j n
n
P P P
∈
=
P " (2)
where, n means the number of the instances for each
parameter and j is the index of the instances.
Each sweeper is represented by the following
elements in APDL as a form of complex type.
// Defined parameter type
// static ordered or auto stepping
// when value list type is static ordered
// start value when value list
type is auto stepping
// end value when value list
type is auto stepping
// step interval when value list
type is auto stepping
Figure 3. Data Structure of Sweeper.
In Figure 3, ParameterElement is a ParameterType
that is mentioned by Figure 2.
We define two kinds of list types for values of
parameters. It determines how to generate the
parameter instances. A static ordered list is used when
inserting the values directly and auto stepping is used
when inserting the values dynamically using start, end
and interval.
From Eq.(1) and Eq.(2), we can define the
parameter space P as a two dimensional matrix as
follows.
1
1 1 1
1
1
where ,
j n
j j n
i i i i
x
j n
m m m
p p p
p p p
p p p
i m j n
 
 
 
 
 
= =
   
 
 
 
∈ ∈
m n
P P
" "
# % # $ #
" "
# $ # % #
" "
(3)
With the parameter space P, user can apply various
sweep algorithms for obtaining a customized parameter
set.
4.2. Three Kinds of Sweep Algorithms
Using parameter space as shown by Eq.(3), we adapt
three kinds of algorithms - serial, parallel and nested.
This algorithms are originally suggested at [6] as a
parameter sweep extension. Those usages are described
in
y serial
P - All parameter in P, Parameter set S is a
collection of the instances obtained when a
parameter is varying itself, and yet the other
parameters only has a default value
y pa ra llel
P - All parameter in P, Parameter set S is
a collection of the instances obtained by the
same position of the variation of each parameter.
y nested
P - All parameter in P, Parameter set S is
a collection of the instances obtained by the
infinite products of P.
In order to adapt those kinds of sweep algorithms,
we define the Pivot Value of each parameter.
0
1
pv
pv
p v
i m
pv
m
P
P
P
∈
 
 
 
=
 
 
 
 
P
#
(4)
Ppv
provides a default value for each parameter. In
parameter space P, if a certain parameter instance is
not specified, we substitute the pivot value for the
value.
Figure 4 shows the pseudo code for three kinds of
sweep algorithms.
About Parameter Space P and Parameter Set S
1)For Sserial
SET l = 1, k=1
512

5. FOR j=1 TO n
FOR i=1 TO m
IF (i = k) THEN
j j
i i
=
S P
ELSE
j pv
i i
=
S P
END IF
j
l i
 
=  
S S
Increment counter l,i
END FOR
Increment counter j,k
END FOR
2)For Sparallel
SET l = 1
FOR j=1 TO n
FOR i=1 TO m
IF ( j
i ≠ ∅
P ) THEN
j j
i i
=
S P
ELSE
j pv
i i
=
S P
END IF
j
l i
 
=  
S S
Increment counter l,i
END FOR
Increment counter j
END FOR
3) For Snested
SET l = 1
FOR i=1 TO m
S = CALL SUB(i)
END FOR
Increment counter i
SUB(i)
IF(i < m)
FOR j TO n
RETURN [ j
i
P , CALL SUB(i)]
END FOR
ELSE
EXIT
END IF
END SUB
Figure 4. Pseudo code for Proposed Algorithms.
When we denote l
nS , k
nP are total number of
instance of l
S and the total number of parameter
instance k
P respectively, we can draw l
nS which
determined by above parameter sweep algorithms
from k
nP .
, w h en
1
, w h en
, w h en
1
l
i
n k seria l
k
n p a ra llel
i
i
n k n ested
k
n

∑

 =





∏

 =

≤
P P
P P
P P
S (5)
5. Architecture of Parametric Study
Service
The Proposed Parametric Study Service (PSS)
provides the standard interface using Web Services. An
application PSE makes it possible to find and bind the
service through Web Service Description Language
(WSDL). PSS can be adapted to various PSEs and
support job submission interfaces.
Figure 5 shows the overall architecture and internal
and external modules of the PSS.
Parameter Parser
Job Dispatcher
Job Scheduler
Web Service Interface
JSDL + APDL
WebMDS
Job Instance Generator
Plug-in
Information
Service
GT4 GridFTP
Security
Services
(GSI)
MJFS
Data Manager
Figure 5. Overall architecture of PSS.
5.1. Internal Modules
-Parameter Parser
A parameter parser generates the parameter set
based on user defined parameter space and its sweep
element specified in APDL as well as essential
information for remote execution through JSDL
- Job Instance Generator Plug-in
A Job instance generator plug-in generates the
multiple jobs and the corresponding resource script
files according to the job submission interface which
supported in the PSE.
- Job Scheduler
A job scheduler with a standard interface selects the
computational resources for executing the jobs
generated by Parameter Parser. It contacts the
WebMDS in order to find out currently available
resources based on the resource requirements. Because
513

6. it has a standard interface for scheduling, PSS can use
FIFO or user-defined scheduling algorithm.
- Job Dispatcher
A job dispatcher submits the jobs scheduled by job
scheduler and address the End Point References
(EPRs) of the computation resources for invoking the
WS-GRAM on GT4. Once submitted, it stores a job
identifier to trace the progress of each job.
- Data Manager
A data manager is responsible for file transfer.
When a job finishes, the data manager retrieves the
temporarily stored result data at the job execution site
and moves them into pre-defined data storage server.
5.2. External Modules
External Modules are the components of the GT4.
GT4 provides security mechanism, execution
management, data management and information
mechanism such as GSI, WSGRAM, WebMDS and
GridFTP. See the Globus website for further
information [10].
6. Case Study: e-AIRS
The Aerospace Integrated Research System (e-
AIRS) [11] is a virtual organization designed to
support the aerospace engineering processes which
include both the computational and experimental
aerodynamic researches on the e-Science
infrastructure.
Figure 6. CFD research process on e-AIRS.
As shown in Figure 6, users can conduct the full
Computational Fluid Dynamics (CFD) research
processes, request a wind tunnel experiment and carry
out the comparative analysis between computational
and experimental results on the web portal.
When a user submits jobs with various input
conditions, he also should consider available resources
and processes of combining these. Proposed PSS
supplies not only assigning jobs related with several
parameters to resources efficiently based on the job
scheduling technique efficiently, but also executing
massive computation jobs atop grid resources. After
completion of several executions, all of results are
aggregated in a graph by PSS to plot the trace of
simulation change. The execution of a CFD solver
requires several flow parameters such as Mach
number, Reynolds number, Inflow
pressure/temperature, and so on. These parameters are
created by the user input and written on a flow
condition file. With these flow condition file and the
prepared mesh data file, the CFD solver is simulated
on PSS environment to reduce computation time
dramatically.
Input file template
#Name Name:Data TypeDefault Value
AMACH $AMACH:FLOAT:0.73d0
RE $RE:FLOAT:5.0D6
AOA $AOA:FLOAT:2.0d0
TOL $TOL:FLOAT:1.0d-4
TINF $TINF:FLOAT:290.0d0
CFL $CFL:FLOAT:0.5d0
IERRWRT $IERRWRT:INTEGER:1
TOTPES $TOTPES:INTEGER:6
NSEULER $NSEULER:INTEGER:-1
KWKEBL $KWKEBL:INTEGER:0
INTWRT2 $INTWRT:INTEGER:50
ITMAX2 $ITMAX2:INTEGER:500
Figure 7. Parameters and sweep process of CFD
solver.
Figure 7 shows parameters and sweep type instance
from client interface. Users will analysis the relations
of Angle Of Attack(AOA) and Reynolds number using
Three-dimensional Turbulent Analysis Code for
Compressible flow(3DTurb). When we change the
AOA and Reynolds number, flow around wing is
dynamically changed. Using these results, we can
discover new physical phenomenon and flight
principle.
Currently, Two-dimensional compressible and
incompressible CFD codes are also implemented on e-
AIRS. These codes can cover the compressible and
514

7. incompressible steady/unsteady inviscid/laminar/
turbulent CFD analysis. The e-AIRS used for
education purpose in aerospace department and will be
extend to research for industry.
7. Conclusion and Future Works
In this paper, we propose a SOA-based parametric
study service (PSS) that enables parameterized
simulations on the various Grid platforms and user
environment. An application parameter description
language (APDL) acts as a tool for describing the
characteristics and types of parameters. From the
APDL, the proposed PSS automatically carries out the
whole procedure for Grid jobs, e.g., generating and
scheduling jobs, allocating resources, and collecting
result data. Consequently, the PSS helps scientists
carried out large-scale simulations on the Grid without
the knowledge of the underlying structure including
the Grid. We plan to develop parameter-optimization
functionalities using feedback mechanism, which
repeatedly change the input parameters and get their
revised output results.
8. References
[1] National e-Science Project, Application Development,
http://www.escience.or.kr/
[2] UK e-Science, All Hands Meeting 2006
http://www.allhands.org.uk
[3] National Research Coucil, Evolving the High
Performance Computing and Communications Initiative to
Support the Nation's Information Infrastructure, National
Academy Press, March 1995.
[4] The Condor project, http://www.cs.wisc.edu/condor
[5] I. Foster, C. Kesselman, J.M. Nick, and S. Tuecke, “The
Physiology of the Grid: An Open Grid Services Architecture
for Distributed Systems Integration”, Open Grid Service
Infrastructure WG, Global Grid Forum, 2002
[6] Job Submission Description Language WG (JSDL-WG),
https://forge.gridforum.org/projects/jsdl-wg/
[7] Job Submission Description Language (JSDL)
Specification, Version 1.0,
www.ggf.org/documents/GFD.56.pdf
[8] gLite user guide https://edms.cern.ch/file/722398/gLite-3-
UserGuide.html
[9] Globus Toolkit 2.4 Release Manuals
http://www.globus.org/toolkit/docs/2.4/
[10] Globus Toolkit 4.0 Release Manuals
http://www.globus.org/toolkit/docs/4.0/
[11] e-Science Integrated Research Systems,
http://eairs.kisti.re.kr/gridsphere/gridsphere
[12] D. Abramson, R. Sosic, J. Giddy, and B. Hall, "Nimrod:
A Tool for Performing Parametised Simulations using
Distributed Workstations", in Proceedings of the 4th IEEE
Symposium on High Performance Distributed Computing,
pages 112-121, Washington, D.C., USA, August 1995.
[13] R Raman, M Livny, and M Solomon, "Matchmaking:
Distributed Resource Management for High Throughput
Computing", in Proceedings of the Seventh IEEE
International Symposium on High Performance Distributed
Computing, pages 140-146, Chicago, IL., USA, July 1998.
[14] M. Yarrow, K. McCann, R. Biswas, and R. Van der
Wijngaart, "An Advanced User Interface Approach for
Complex Parameter Study Process Specification on the
Information Power Grid," in Proceedings of the First
IEEE/ACM International Workshop on Grid Computing,
pages 146-157, Bangalore, India, December 2000.
[15] H. Casanova, G. Obertelli, F. Berman, and R. Wolski,
“The AppLeS Parameter Sweep Template: User-Level
Middleware for the Grid”, in Proceedings of the 2000
ACM/IEEE conference on Supercomputing (CDROM),
Article No. 60, Dallas, Texas, USA, November 2000.
[16] APST XML man page
http://grail.sdsc.edu/projects/apst/apst_xml_man.html
[17] Enable Grids for E-Science http://public.eu-egee.org/
[18] Open Science Grid http://www.opensciencegrid.org/
[19] Pacific Rim Applications And Grid Middleware
Assembly http://www.pragma-grid.net/
515