[kepler-dev] ParameterSet

Sun Oct 29 10:36:11 PST 2006

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
settings. 

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
p-settings. 

(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.]

Comments?

Bertram

>>> On Fri, 20 Oct 2006 16:52:13 -0700 (PDT)
>>> Norbert Podhorszki <npodhorszki at ucdavis.edu> wrote: 
NP> 
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> 
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> 
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> 
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().
NP> 
>> 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> 
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> 
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.
NP> 
>> 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> 
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> 
NP> Norbert
NP> 
NP> 
NP>       Norbert Podhorszki
NP>     ------------------------------------
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>       ----------------------------------
NP> _______________________________________________
NP> Kepler-dev mailing list
NP> Kepler-dev at ecoinformatics.org
NP> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev