<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Marc,<br>
<br>
Edward might have some input here, but below are my thoughts.<br>
<br>
Marc writes:<br>
<blockquote type="cite">I have identified the "External Application"
actor as the appropriate actor to begin this application.</blockquote>
Hmm, I don't have an "External Application" actor in Kepler-2.2, but
I do have an "External Execution" actor that<br>
uses ptolemy.actor.lib.Exec. <br>
<blockquote type="cite">
<ol>
<li>As each application assemblage of user parameters is simply
a string, should string actors be used to complete the final
concatenation?</li>
</ol>
</blockquote>
<br>
You could use String actors to concatenate the command string but
you could also use the expression language.<br>
<br>
The ExternalExecution actor has a command PortParameter that is a
StringParameter. StringParameters are<br>
Variables that are in "string mode", which means you can access a
model parameter named "id" via $id, $(id) or ${id}.<br>
See
<a class="moz-txt-link-freetext" href="http://ptolemy.eecs.berkeley.edu/ptolemyII/ptII8.0/ptII/doc/codeDoc/ptolemy/data/expr/Variable.html">http://ptolemy.eecs.berkeley.edu/ptolemyII/ptII8.0/ptII/doc/codeDoc/ptolemy/data/expr/Variable.html</a><br>
<br>
So, you could build up your command line by setting model parameters
and then having an Expression actor<br>
connected to the command input of an External Execution actor.<br>
<br>
<br>
The ParameterSet actor could be of use to you, see<br>
<a class="moz-txt-link-freetext" href="http://chess.eecs.berkeley.edu/ptexternal/src/ptII/doc/codeDoc/ptolemy/actor/parameters/ParameterSet.html">http://chess.eecs.berkeley.edu/ptexternal/src/ptII/doc/codeDoc/ptolemy/actor/parameters/ParameterSet.html</a><br>
The ParameterSet actor puts parameters into a file.<br>
<br>
I've attached a Kepler model that uses ParameterSet and the External
Execution actor.<br>
<br>
Another idea would be to place parameters in a file and use the
Expression Reader actor or the<br>
File to Array Converter actor.<br>
<br>
<blockquote type="cite">
<ol>
<li>What would be the best way to present the various user
parameter options to the person using the workflow?</li>
<ul>
<li>In some situations the user will invoke the application in
a interactive mode, in other scenarios, in a batch
execution.</li>
</ul>
</ol>
</blockquote>
<br>
In Ptolemy, parameters may container subparameters. When the user
configures an actor, the edit<br>
parameter dialog is displayed. <br>
The ScopeExtendingAttribute makes the subparameters visible in the
current scope, its documentation says:<br>
"
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
An attribute that extends its container's scope. Any parameter
contained by such an attribute has the same visibility<br>
as parameters of the container of the attribute. They are shadowed,
however, by parameters of the container.<br>
That is, if the container has a parameter with the same name as one
in the parameter set, the one in the container<br>
provides the value to any observer."<br>
<br>
To create a parameter that contains subparameters:<br>
1) In the "Search Components" field, type in <br>
ScopeExtendingAttribute<br>
2) Drag in a ScopeExtendingAttribute<br>
3) Double click on the ScopeExtendingAttribute<br>
4) In the Edit Parameter Dialog, click on Add<br>
5) In the "Add a new parameter to ...ScopeExtendingAttribute":<br>
Name: foo<br>
Default value: "bar"<br>
6) Hit OK<br>
7) The foo parameter appears in the edit parameters dialog.<br>
8) To hide the other fields, use the Preferences button<br>
<br>
I've attached ScopeExtendingAttributeExec.xml, which uses a
ScopeExtendingAttribute. <br>
You could change the name from ScopeExtendingAttribute to something
that makes more sense.<br>
<br>
If you used ScopeExtendingAttributes, then the user would drag in
parameters from a library.<br>
The Unit system has parameters that describe the units, try
searching for "unit", dragging in<br>
BasicUnit and double clicking on it.<br>
<br>
Another approach would be to pass ordered records or arrays of
records around that define the command<br>
line arguments and their values.<br>
<br>
The External Execution actor has an input named "command" that
expects the command name and the <br>
command arguments. It would not be that hard to modify the External
Execution actor so that it took<br>
an optional array of arguments, much like the environment
parameter. The argument parameter could<br>
be a PortParameter so that it was possible to more easily change the
parameters.<br>
<br>
<blockquote type="cite">
<ol>
<li>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.</li>
</ol>
</blockquote>
The user could drag in ScopeExtendingAttributes from the library or
from another model.<br>
<blockquote type="cite">
<ol>
<li>But, out of 20 users, each with their 4 or 5 common
configurations, this may add up to hundreds of commonly used
parameter configurations.</li>
</ol>
</blockquote>
This is a classic configuration management issue. Using the file
system to define the different sets of parameter configurations<br>
is one method. It might be nice if there was an actor that would
refer to another model that contained all the parameters.<br>
This would be sort of a combination of ScopeExtendingAttributes and
ParameterSets. The idea is that when I double click<br>
on this actor, it would have a fileOrURL that referred to another
model that defined the parameters to be used.<br>
It would be nice if it were possible to edit those parameters,
either by editing the remote model itself or by using<br>
Actor Oriented Classes to edit a local version of those parameters.<br>
<br>
Actor Oriented Classes are a way of using object-oriented design
with actors. The idea is that there is an actor<br>
class definition that defines a collection of actors. Then, there
are instances of the actor definition that share<br>
the actor class definition. The Sinewave actor is actually a actor
class definition in the library and actor class<br>
instances in the model. There is also the notion of subclasses. A
subclass can make only certain changes<br>
to the class definition. Perhaps you could use Actor Oriented
Classes to define groups of parameters<br>
that could then be subclassed. Actor Oriented Classes is a bit of a
mind bender, see<br>
<a class="moz-txt-link-freetext" href="http://ptolemy.eecs.berkeley.edu/publications/papers/07/classesandInheritance/index.htm">http://ptolemy.eecs.berkeley.edu/publications/papers/07/classesandInheritance/index.htm</a><br>
<br>
<br>
<blockquote type="cite">
<ol>
<li>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?</li>
</ol>
</blockquote>
<br>
It depends on how you see users running the models. The method you
describe makes sense if you want to create a ParameterSet<br>
with the configuration workflow and later run it.<br>
<br>
<br>
<br>
BTW - <br>
Ptolemy Classic had a Design Flow Management model of computation
that was part of<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
Asawaree Kalavade and Jose Pino's work, see<br>
<a class="moz-txt-link-freetext" href="http://ptolemy.eecs.berkeley.edu/publications/papers/95/managing_complexity/">http://ptolemy.eecs.berkeley.edu/publications/papers/95/managing_complexity/</a><br>
The Ptolemy Classic DFM work never really made it into a release.<br>
<br>
Ptolemy II had not done much with Design Flow Management, though
there is a research abstract from 1999 at<br>
<a class="moz-txt-link-freetext" href="http://ptolemy.berkeley.edu/projects/summaries/99/wbwu99b.html">http://ptolemy.berkeley.edu/projects/summaries/99/wbwu99b.html</a><br>
<br>
_Christopher<br>
<br>
<br>
On 10/3/11 8:31 AM, J. Marc Edwards wrote:
<blockquote cite="mid:4E89D558.3090307@nimbisservices.com"
type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
All:<br>
<br>
I am new to Kepler, so please forgive my immaturity in developing
Kepler workflows.<br>
<br>
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. <br>
<br>
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.<br>
<br>
First, my application description...<br>
<ul>
<li>The application is developing cloud-based workflows for
semiconductor design methodology.<br>
</li>
<li>I am working with multiple, standalone external applications
that are traditionally invoked with shell scripts, e.g.
C-shell, Perl, bash, etc.</li>
<li>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.</li>
<li>The external applications all have MANY (as in dozens) user
parameters that configure the application upon invocation.</li>
<ul>
<li>The user parameters range from simple "-gui" type
parameters, to "-file filename1.txt filename2.txt", to
parameters that are embedded macros.</li>
</ul>
<li><font color="#3366ff">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.</font></li>
<ul>
<li>I have identified the "External Application" actor as the
appropriate actor to begin this application.</li>
</ul>
<li><font color="#3366ff">My main question lies in the best way
to assemble the various user parameters for each external
application, i.e.</font></li>
<ol>
<li>As each application assemblage of user parameters is
simply a string, should string actors be used to complete
the final concatenation?</li>
<li>What would be the best way to present the various user
parameter options to the person using the workflow?</li>
<ul>
<li>In some situations the user will invoke the application
in a interactive mode, in other scenarios, in a batch
execution.</li>
</ul>
<li>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.</li>
<li>But, out of 20 users, each with their 4 or 5 common
configurations, this may add up to hundreds of commonly used
parameter configurations.</li>
<li>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?</li>
</ol>
</ul>
Your advice would be greatly appreciated.<br>
<br>
Regards, Marc<br>
<div class="moz-signature">-- <br>
<meta http-equiv="CONTENT-TYPE" content="text/html;
charset=ISO-8859-1">
<title></title>
<meta name="GENERATOR" content="LibreOffice 3.3 (Unix)">
<meta name="CREATED" content="0;0">
<meta name="CHANGEDBY" content="J. Edwards">
<meta name="CHANGED" content="20110727;17373400">
<meta name="CHANGEDBY" content="J. Edwards">
<style type="text/css">
<!--
P { color: #000000 }
-->
</style>
<p><font color="#800080"><font face="Comic Sans MS, cursive"><font
style="font-size: 13pt" size="3"><span
style="font-weight: normal">J. Marc Edwards</span></font></font></font><font
face="Comic Sans MS, cursive"><br>
Lead Architect - Semiconductor Design Portals</font><br>
<font color="#3333ff"><font face="Nimbus Sans L, sans-serif"><font
size="4">Nimbis Services, Inc.</font></font></font><br>
<font face="Courier New">Skype: (919) 747-3775<br>
Cell: (919) 345-1021<br>
Fax: (919) 882-8602</font><br>
<font face="Ubuntu"><a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:marc.edwards@nimbisservices.com">marc.edwards@nimbisservices.com</a><br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="http://www.nimbisservices.com">www.nimbisservices.com</a></font></p>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Kepler-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Kepler-users@kepler-project.org">Kepler-users@kepler-project.org</a>
<a class="moz-txt-link-freetext" href="http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users">http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Christopher Brooks, PMP University of California
CHESS Executive Director US Mail: 337 Cory Hall
Programmer/Analyst CHESS/Ptolemy/Trust Berkeley, CA 94720-1774
ph: 510.643.9841 (Office: 545Q Cory)
home: (F-Tu) 707.665.0131 cell: 707.332.0670 </pre>
</body>
</html>