ludaesch at ucdavis.edu
Fri Nov 3 09:36:27 PST 2006
Hi Edward, Norbert, and all:
Seems there is consensus on the parameter vs variable distinction.
Other than Norbert, nobody else seems to have currently use for his
I would like to encourage silent by-standers to comment now, if they
think they might need a similar feature in the forseeable future.
Your comment about silently discarding user data is an
interesting one. It reminded me that we have a need for clarifying the
"signature" of a workflow. Here is a rough idea how I currently look
at this (note that this might differ from the Ptolemy view of what a
As a first cut, a workflow W can be seen as a function
W :: <params>, <data-in> --> <data-out>
- <params> is the list of globally visible parameters; parameters have
to be parameters in the Ptolemy sense; they should be considered
immutable during wf execution (else use variables);
whether parameters in subworkflows are part of <params> is subject to
discussion (requirement: it should be CLEAR to the wf designer whether
a param is globally visible or not)
- <data-in> are "special" data input parameters (somehow
distinguised). This is useful for scientific wf applications where
frequently the same wf has to be run w/ different data sets.
- <data-out> are similarly, special parameters that define data sinks
(intermediate or final). Again, it should be easy to run the same wf
and just configure <data-out> differently in order to change the
Some more thoughts:
Why do we want such a signature and how should we go about declaring
it (say within MOML) and/or inferring it (say from MOML)?
First, as indicated above, once a wf has been carefully designed, it
should be a simple matter of changing a few params so that
(a) its behavior changes, based on the params
(b) its global sources or targets change, based on data-params
A workflow signature is also the basis for *deploying* a workflow, say
as a web service.
Moreover, Ptolemy already has various mechanisms for invoking a
wf/model from within another wf/model: composite actors, higher-order
actors, etc. The above wf signature stuff should go hand-in-hand with
this. For example, I should be able to compose to workflows W1, W2 by
simply saying sth like
LET W3 = W1(W2)
Then then W2.output would be fed into the input of W1.
(details to be discussed, specifically the passing of parameters..)
Or I might want to a parameter sweep along the lines of
FOR p = 1 TO 100 STEP 0.1
This would define 1000 wf runs with fixed <data-in> and <data-out>
(there might be a problem here ;-) but with values of p ranging from 1
to 100 in .1 increments.
>>> On Mon, 30 Oct 2006 03:00:23 -0800
>>> "Edward A. Lee" <eal at eecs.berkeley.edu> wrote:
EAL> I like the idea of distinguishing parameters from variables,
EAL> and in fact we used to do this in Ptolemy Classic. It's an extremely
EAL> useful distinction in code generation, since parameter generate to
EAL> literal constants while variables generate to, well, variables.
EAL> However, this doesn't by itself solve Norbert's problem.
EAL> I don't think we have a solution yet. Making the precedence rules
EAL> configurable is possible... I would do it by adding a parameter
EAL> to the ParameterSet parameter called, say, "overwriteContainerParameters"
EAL> that by default is false. However, I still believe this is not
EAL> good behavior because it silently discards user data (it does,
EAL> Norbert... the parameter value before the overwrite is user
EAL> data... when you save the model, it's gone, and the user never
EAL> directly erased the data). I guess if it's clearly documented
EAL> with plenty of warnings, then I can live with it. Would Norbert
EAL> be the only one to use it?
EAL> With the parameter/variable distinction, the user data need not
EAL> be lost, since presumably if the container's parameter is a
EAL> "variable" then its initial value would be preserved. However,
EAL> this is really subtle... User data is overwritten if you use
EAL> a Parameter, not overwritten if you use a Variable... Seems to
EAL> me like this really borders on mysterious inexplicable behavior...
EAL> At 10:36 AM 10/29/2006, Bertram Ludaescher wrote:
>> Edward, Norbert:
>> I only now get to throw in my own 2 cents on this.
>> This is a very interesting and important issue (i.e., how to deal with
>> on-screen params vs. config-param settings).
>> Clearly, part of the issue arises due to the different use cases and
>> ways of using Ptolemy/Kepler:
>> - as an interactive modeling or wf *design* (and testing) tool
>> - vs in 'non-interactive' mode, i.e., after the design+testing is
>> essentially finished.
>> I have two suggestions:
>> 1. Allow to define a "parameter handling policy", e.g. as a command
>> line option. I know that making things configurable is an old trick,
>> and that is sometimes pulled too often out of the cylinder ...
>> Specifically it adds to the complexity of understanding the overall
>> system when one has to take into account this new param handling
>> policy parameter.
>> 2. Norbert's comment on distinguishing *params* from *variables* is an
>> interesting one and could be used to think about a more fundamental /
>> modeling kind of solution.
>> I guess it's in the nature of a model/workflow parameter to be quite
>> static, even fixed throughout an execution (making a parameter really
>> a user-definable *constant*).
>> On the other hand, I can see uses such as parameter sweep techniques,
>> where one wants to be able to run a workflow with different param
>> I'd like to suggest to try and find a common understanding of these
>> notions. Here is an attempt:
>> Kepler workflows/Ptolemy models have a well-defined signature/API,
>> consisting of
>> (p) immutable parameters (which can be instantiated at the beginning,
>> but cannot be changed during execution)
>> (d) "data bindings" (for Kepler, maybe not needed for Ptolemy), in a
>> sense a set of "special parameters" which act as "data inputs" (data
>> streams from databases) and/or "data outputs" (special, distinguished
>> data(base) sinks into which the global wf output is dumped)
>> (v) mutable parameters or 'static *v*ariables' which get their default
>> values at invocation time, but which can change dynamically during
>> execution (hey, I didn't come up with the notion of 'static variable'
>> for a dynamically changing entity..)
>> Equipped with these (or similar) basic notions, we might be able to
>> define a solution to the param-handling-policy problem that is more
>> satisfying to the different needs!?
>> For example, by def. (p) stuff cannot be changed during exec, but only
>> at invocation time (that still allows param sweeps via higher-order
>> actors which invoke the same wf/model multiple times w/ different
>> (v) can be changed during runtime. This might be a good modeling
>> primitive for user-interactive wfs where the user during execution
>> needs to inspect some values, then dynamically changes a parameter
>> setting -- oops, excuse-moi, a mutable param/variable (v)
>> [Aside: of course, a procedural way to do param sweeps could be to use
>> (v) instead of (p)+higher-order actors. But the latter seems
>> cleaner/more statically analysable and thus preferable.]
>> >>> On Fri, 20 Oct 2006 16:52:13 -0700 (PDT)
>> >>> Norbert Podhorszki <npodhorszki at ucdavis.edu> wrote:
NP> On Fri, 20 Oct 2006, Edward A. Lee wrote:
>> >> 1) As a general rule, one should not discard user data as a
>> >> side effect of some action that might seem unrelated.
>> >> Changing the value of an on-screen parameter as a side effect
>> >> of editing a configuration file would violate this rule.
NP> I do not see this. Why is it a violation? I open a workflow, the
NP> parameters values are set according to the config file. Then I can decide
NP> about changing them before executing the workflow. Why is this different
NP> from opening a workflow which has no config file, just some parameters.
NP> Their values are stored in the xml file and then I can change them before
NP> executing the workflow.
NP> I do not consider the config file as user data. This is not data processed
NP> by the workflow. This is just a convenient storage of parameters in a
NP> separate, plain text file. Otherwise, before command-line execution, the
NP> user should change the parameters inside the xml. Do not worry, physicist
NP> are not afraid from doing that!
NP> Another option is to create a new actor, that takes a config file as input
NP> and creates such parameters or sets the values of existing ones. And this
NP> actor would be put into my workflows to the beginning. This resembles the
NP> textual programming where main() first calls processArgs().
>> >> 2) It seems very complex. Do you really want to change parameter
>> >> values when you save a file? This means that you can run,
>> >> save, close, open, re-run, and get different results...
>> >> This sort of inexplicable behavior is what Microsoft Word does ;-)
NP> Now here comes out the difference in our views. Here you refer to
NP> parameters that may be changed by the workflow during execution. I
NP> would like to name such entities as 'variables', not 'parameters'.
NP> I was thinking only about parameters, i.e. read-only entities (for the
NP> workflow execution). But you are right, with current Ptolemy parameters
NP> this is possible.
NP> However, I just suggested this save option only because I thought you
NP> would have asked first: what about the annoying situation that the user
NP> changes the parameter on screen and then next time opens the workflow and
NP> the old value pops up there from the config file. I do not need that
NP> save-back feature, so we can eliminate this point.
>> >> There is actually a mechanism already that does much of what you
>> >> propose:
>> >> - Create a ParameterSet with a variable "foo" with value "20" (say).
>> >> - Create an on-screen parameter with name "foo" and value "foo".
>> >> Now, the value of foo used within the model is 20. If I change
>> >> the value of the on-screen parameter to "5" (say), then the value
>> >> of foo in the model becomes 5.
>> >> Would this satisfy the need?
NP> No, for the same two reason, as for I need the discussed behaviour:
NP> - no default values
NP> - only annoying screenshots as documentation
NP> So rather, I just delete all on-screen parameters :-(
NP> Norbert Podhorszki
NP> University of California, Davis
NP> Department of Computer Science
NP> 1 Shields Ave, 2236 Kemper Hall
NP> Davis, CA 95616
NP> (530) 754-8188
NP> pnorbert at cs.ucdavis.edu
NP> Kepler-dev mailing list
NP> Kepler-dev at ecoinformatics.org
EAL> Edward A. Lee
EAL> Chair of EECS and Robert S. Pepper Distinguished Professor
EAL> 231 Cory Hall, UC Berkeley, Berkeley, CA 94720-1770
EAL> phone: 510-642-0253, fax: 510-642-2845
EAL> eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal
More information about the Kepler-dev