[kepler-dev] ParameterSet

[Dan Higgins]

Hi Bertram (and others),
    Since you asked for comments , here is my $0.02 ----

    First of all, ParameterSet is not included in the actors shipped 
with Kepler (i.e. the ones that automatically appear in the actor tree), 
so I doubt if most Kepler users even know it exists.
    I have written several Kepler workflows that include LineReaders for 
reading inputs (parameters) as part of the workflow execution to do 
essentially the same thing as ParameterSets. So I have never seen the 
problem of in workflow Parameters interfering with ParameterSet values.
    It seems like PortParameters can be used to overcome Norbert's 
original problem. I have used PortParameters with default values for 
building/debugging a workflow. You can then put that workflow inside a 
Composite (e.g a RunCompositeActor HOC) and carry out a parameter sweep 
by feeding the varying parameters through the ports.

Dan

Bertram Ludaescher wrote:
> 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
> desired feature.
> I would like to encourage silent by-standers to comment now, if they
> think they might need a similar feature in the forseeable future.
>
> Edward: 
> 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
> model is): 
>
> As a first cut, a workflow W can be seen as a function 
>   W :: <params>, <data-in> --> <data-out>
> where 
> - <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
> target.
>
> 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 
>   W2(p) 
>
> 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.
>
> Bertram
>
>
>
>
>   
>>>> On Mon, 30 Oct 2006 03:00:23 -0800
>>>> "Edward A. Lee" <eal at eecs.berkeley.edu> wrote: 
>>>>         
> EAL> 
> 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> 
> 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> 
> 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> 
> EAL> Edward
> EAL> 
> EAL> At 10:36 AM 10/29/2006, Bertram Ludaescher wrote:
> EAL> 
>   
>>> 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
> EAL> 
> EAL> ------------
> 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  
>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>   


-- 
*******************************************************************
Dan Higgins                                  higgins at nceas.ucsb.edu
http://www.nceas.ucsb.edu/    Ph: 805-893-5127
National Center for Ecological Analysis and Synthesis (NCEAS) Marine Science Building - Room 3405
Santa Barbara, CA 93195
*******************************************************************