[From the list, posted by Geoff]

Dear Michel, Andreas, and others group members,


A group of us currently meeting in KISTI, S.Korea have been sharing
ideas and considerations for the implementation of a parameter sweeping
mechanism to support the research community. Input has principally come
from David Meredith (NGS), Soonwook Hwang and Byungsang (KISTI) and
myself. David is the creator of the UK National Grid Service JSDL
Application Repository portal (https://portal.ngs.ac.uk), and has been
tasked with creating a parameter sweeping mechanism for the NGS portal
(I am currently working with David on implementing this functionality).
Naturally we would like to adopt JSDL sweep related standards. Soonwook
and Byungsang are in charge of development of KISTI's AURORA Application
Repository (http://aurora.kisti.re.kr), which has been in use for some
time and uses its own schema definition for parameter sweeping.


AURORA's mechanism is loosely aligned with JSDL, but focuses on the
sweeping of parameters within input files, rather than sweeping over
elements defined within the JSDL document itself. We consider this to be
an important additional functionality. Indeed, David has already
reported on a number of (bespoke) parametric job definition schemes used
to sweep over parameters within input files which have been developed as
a matter of requirement by a number of different NGS user communities. 


The JSDL parameter sweeping specification in its current draft form
appears to provide the flexibility to sweep over any element within a
JSDL document, and as such provides powerful flexibility to the user.
>From our experience however, many applications (for example KISTI and
NGS supported NSCCS applications, e.g. CFD Solver, AutoDock) require the
ability to sweep over values within input files. Consequently, where
possible, we would like to propose further extensions to the existing
draft sweep schema specification for including; a) the definition of
parametric variables that can exist within input files, and b) referral
to the associated data\input files. 



We were therefore wondering whether the same conclusion had been reached
by those contributors to the original draft specification or indeed,
whether you all feel that such an approach falls outside the remit of
the OGF standard specification. Maybe we could organize a joint phone
chat to discuss some of these issues and offer ideas and suggestions. We
will working together until late Friday so if it's possible to have some
feedback to these queries during this period it would be very much
appreciated.


Best wishes,


Geoff, Byungsang, David, Soonwook. 


Note,

**KISTI – Korea Institute for Science Technology Information

**NSCCS – National Service for Computational Chemistry