[kepler-users] New Kepler 2.2 user would like some methodology advice for my application...

[J. Marc Edwards]

All:

I am new to Kepler, so please forgive my immaturity in developing Kepler
workflows.

Now that I have completed a lot of reading and browsing of Kepler
workflows, I am now really digging into the development of my first
Kepler workflows. 

I have been working with some of the actors that I thought would be
appropriate for my workflow, but now have some questions about the most
efficient manner to implement my application workflow.

First, my application description...

  * The application is developing cloud-based workflows for
    semiconductor design methodology.
  * I am working with multiple, standalone external applications that
    are traditionally invoked with shell scripts, e.g. C-shell, Perl,
    bash, etc.
  * Each standalone application is part of a very loosely coupled
    "design methodology" that defines how all of the external
    applications should be used as part of the design process.
  * The external applications all have MANY (as in dozens) user
    parameters that configure the application upon invocation.
      o The user parameters range from simple "-gui" type parameters, to
        "-file filename1.txt filename2.txt", to parameters that are
        embedded macros.
  * I would like to get some user recommendations & advice from this
    community wrt how to encapsulate these types of external
    applications into a Kepler workflow.
      o I have identified the "External Application" actor as the
        appropriate actor to begin this application.
  * My main question lies in the best way to assemble the various user
    parameters for each external application, i.e.
     1. As each application assemblage of user parameters is simply a
        string, should string actors be used to complete the final
        concatenation?
     2. What would be the best way to present the various user parameter
        options to the person using the workflow?
          o In some situations the user will invoke the application in a
            interactive mode, in other scenarios, in a batch execution.
     3. The users of the applications will usually have 4 or 5 most
        commonly used set of user parameters that fit their needs and
        will adjust their application scripts accordingly for these
        configurations.
     4. But, out of 20 users, each with their 4 or 5 common
        configurations, this may add up to hundreds of commonly used
        parameter configurations.
     5. Should I create a workflow that is effectively a "configuration
        workflow" that would then assemble for a user their most
        commonly used configurations and then have a "run workflow" that
        takes the output from the "configuration workflow" that the user
        would run?

Your advice would be greatly appreciated.

Regards, Marc
-- 

J. Marc Edwards
Lead Architect - Semiconductor Design Portals
Nimbis Services, Inc.
Skype: (919) 747-3775
Cell:  (919) 345-1021
Fax:   (919) 882-8602
marc.edwards at nimbisservices.com
www.nimbisservices.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-users/attachments/20111003/5b0f4390/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: marc_edwards.vcf
Type: text/x-vcard
Size: 234 bytes
Desc: not available
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-users/attachments/20111003/5b0f4390/attachment.vcf>