[kepler-users] New Kepler 2.2 user would like some methodology advice for my application...
Christopher Brooks
cxh at eecs.berkeley.edu
Mon Oct 3 12:47:03 PDT 2011
Hi Marc,
Edward might have some input here, but below are my thoughts.
Marc writes:
> I have identified the "External Application" actor as the appropriate
> actor to begin this application.
Hmm, I don't have an "External Application" actor in Kepler-2.2, but I
do have an "External Execution" actor that
uses ptolemy.actor.lib.Exec.
>
> 1. As each application assemblage of user parameters is simply a
> string, should string actors be used to complete the final
> concatenation?
>
You could use String actors to concatenate the command string but you
could also use the expression language.
The ExternalExecution actor has a command PortParameter that is a
StringParameter. StringParameters are
Variables that are in "string mode", which means you can access a model
parameter named "id" via $id, $(id) or ${id}.
See
http://ptolemy.eecs.berkeley.edu/ptolemyII/ptII8.0/ptII/doc/codeDoc/ptolemy/data/expr/Variable.html
So, you could build up your command line by setting model parameters and
then having an Expression actor
connected to the command input of an External Execution actor.
The ParameterSet actor could be of use to you, see
http://chess.eecs.berkeley.edu/ptexternal/src/ptII/doc/codeDoc/ptolemy/actor/parameters/ParameterSet.html
The ParameterSet actor puts parameters into a file.
I've attached a Kepler model that uses ParameterSet and the External
Execution actor.
Another idea would be to place parameters in a file and use the
Expression Reader actor or the
File to Array Converter actor.
> 1. What would be the best way to present the various user parameter
> options to the person using the workflow?
> * In some situations the user will invoke the application in a
> interactive mode, in other scenarios, in a batch execution.
>
In Ptolemy, parameters may container subparameters. When the user
configures an actor, the edit
parameter dialog is displayed.
The ScopeExtendingAttribute makes the subparameters visible in the
current scope, its documentation says:
" An attribute that extends its container's scope. Any parameter
contained by such an attribute has the same visibility
as parameters of the container of the attribute. They are shadowed,
however, by parameters of the container.
That is, if the container has a parameter with the same name as one in
the parameter set, the one in the container
provides the value to any observer."
To create a parameter that contains subparameters:
1) In the "Search Components" field, type in
ScopeExtendingAttribute
2) Drag in a ScopeExtendingAttribute
3) Double click on the ScopeExtendingAttribute
4) In the Edit Parameter Dialog, click on Add
5) In the "Add a new parameter to ...ScopeExtendingAttribute":
Name: foo
Default value: "bar"
6) Hit OK
7) The foo parameter appears in the edit parameters dialog.
8) To hide the other fields, use the Preferences button
I've attached ScopeExtendingAttributeExec.xml, which uses a
ScopeExtendingAttribute.
You could change the name from ScopeExtendingAttribute to something that
makes more sense.
If you used ScopeExtendingAttributes, then the user would drag in
parameters from a library.
The Unit system has parameters that describe the units, try searching
for "unit", dragging in
BasicUnit and double clicking on it.
Another approach would be to pass ordered records or arrays of records
around that define the command
line arguments and their values.
The External Execution actor has an input named "command" that expects
the command name and the
command arguments. It would not be that hard to modify the External
Execution actor so that it took
an optional array of arguments, much like the environment parameter.
The argument parameter could
be a PortParameter so that it was possible to more easily change the
parameters.
> 1. 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.
>
The user could drag in ScopeExtendingAttributes from the library or from
another model.
>
> 1. But, out of 20 users, each with their 4 or 5 common
> configurations, this may add up to hundreds of commonly used
> parameter configurations.
>
This is a classic configuration management issue. Using the file
system to define the different sets of parameter configurations
is one method. It might be nice if there was an actor that would refer
to another model that contained all the parameters.
This would be sort of a combination of ScopeExtendingAttributes and
ParameterSets. The idea is that when I double click
on this actor, it would have a fileOrURL that referred to another model
that defined the parameters to be used.
It would be nice if it were possible to edit those parameters, either by
editing the remote model itself or by using
Actor Oriented Classes to edit a local version of those parameters.
Actor Oriented Classes are a way of using object-oriented design with
actors. The idea is that there is an actor
class definition that defines a collection of actors. Then, there are
instances of the actor definition that share
the actor class definition. The Sinewave actor is actually a actor
class definition in the library and actor class
instances in the model. There is also the notion of subclasses. A
subclass can make only certain changes
to the class definition. Perhaps you could use Actor Oriented Classes
to define groups of parameters
that could then be subclassed. Actor Oriented Classes is a bit of a
mind bender, see
http://ptolemy.eecs.berkeley.edu/publications/papers/07/classesandInheritance/index.htm
> 1. 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?
>
It depends on how you see users running the models. The method you
describe makes sense if you want to create a ParameterSet
with the configuration workflow and later run it.
BTW -
Ptolemy Classic had a Design Flow Management model of computation that
was part of
Asawaree Kalavade and Jose Pino's work, see
http://ptolemy.eecs.berkeley.edu/publications/papers/95/managing_complexity/
The Ptolemy Classic DFM work never really made it into a release.
Ptolemy II had not done much with Design Flow Management, though there
is a research abstract from 1999 at
http://ptolemy.berkeley.edu/projects/summaries/99/wbwu99b.html
_Christopher
On 10/3/11 8:31 AM, J. Marc Edwards wrote:
> 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
>
>
>
> _______________________________________________
> Kepler-users mailing list
> Kepler-users at kepler-project.org
> http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users
--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-users/attachments/20111003/74871fe5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ParameterSetExec.xml
Type: text/xml
Size: 37808 bytes
Desc: not available
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-users/attachments/20111003/74871fe5/attachment.xml>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: myProperties.properties
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-users/attachments/20111003/74871fe5/attachment.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ScopeExtendingAttributeExec.xml
Type: text/xml
Size: 51191 bytes
Desc: not available
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-users/attachments/20111003/74871fe5/attachment-0001.xml>
More information about the Kepler-users
mailing list