[kepler-dev] 1st and 2nd run of the same workflow give different outputs

[Bertram Ludaescher]

Gongjing:

Just to make sure I understand what behavior you *want* to see, i.e., deem
the "right" behavior in your case.
But first, let me see whether I understand PortParameter right:
I thought one use case for PortParameter is as a "hybrid" between a
conventional (static) parameter, and a (dynamic) data port:

(1) When the PortParameter is *not* connected to an upstream port, then it
acts as a conventional parameter. In particular, parameter values are not
"consumed"  -- they are available for actor firings as often as desired.
(2) On the other hand, when the PortParameter *is* connected to an upstream
port, it behaves as a "regular" port, i.e., parameter values are  "consumed"
similar to (data) tokens on any other port. Possibly with the caveat that
there is a default value (akin to a Delay actor).

First, it would be good to confirm how close to reality (or the desired
reality ;-) the above conceptualization (1) and (2) is.

Back to the desired behavior:  Gongjing, it seems you want the PortParameter
to ignore the default value and take all values always from the upstream
actor even on the first run. Is that so? Wouldn't then a "conventional"
(data) port the better choice?

Bertram

On Fri, Apr 16, 2010 at 2:23 PM, Edward A. Lee <eal at eecs.berkeley.edu>wrote:

>
> This is how PortParameter works.
>
> When an input arrives on the port during a run, its value
> is stored in the corresponding parameter, overwriting the
> previous value. Thus, by the end of the run, there is no
> longer any record of the initial value.
>
> It is arguable whether it should actually work this way,
> but the fact is, this is how it works.
>
> Edward
>
>
>
> On 4/16/10 10:34 AM, Gongjing Cao wrote:
>
>> Hi,
>>
>> I came to an interesting workflow when I try to use PortParameter. It
>> generates different outputs at the 1st run and the 2nd (and after) run.
>>
>> Seems the PortParameter only take the default value in the 1st run,
>> instead of taking the value which is passed from the previous actor.
>>
>> Does anybody know why? How can I let this workflow always give the right
>> output as in 2nd run.
>>
>> Thanks!
>>
>> Gongjing
>>
>>
>>
>> _______________________________________________
>> Kepler-dev mailing list
>> Kepler-dev at kepler-project.org
>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>>
>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at kepler-project.org
> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mercury.nceas.ucsb.edu/kepler/pipermail/kepler-dev/attachments/20100419/ce0f7b58/attachment.html>