[kepler-dev] Bug 4549: String Replace actor "remembers" previous execution values
Oliver Soong
soong at nceas.ucsb.edu
Thu Jan 14 13:15:42 PST 2010
Ok, so from the sounds of it, my guess is it's not an RExpression
thing. In one execution, the actor puts a token on the port. We then
modify actor parameters to not put a token on the port. SDF should
still be valid, since we're structurally changing the workflow.
I believe if I saved the workflow, restarted Kepler, and reloaded,
things would behave as expected.
Oliver
On Thu, Jan 14, 2010 at 12:28 PM, Christopher Brooks
<cxh at eecs.berkeley.edu> wrote:
> My understanding is that the value from the parameter should be
> read if there is no input token arrives.
>
> Attached ports are not always guaranteed to receive a token under
> some models of computation during a firing.
>
> Under Synchronous Dataflow (SDF), the schedule for firing actors
> is predetermined. If you have an actor produces tokens in a
> non-deterministic manner, then there will be problems under SDF
> and it would be better to use DDF.
>
> More specifically, if whether an actor produces a token is
> dependent on the input of that actor, then it would be wise to
> not use SDF.
>
> There could be a bug with PortParameters in non-SDF models
> of computation such as SR. However, I'm not sure how to construct
> such a model. I tried a couple of things in DDF and could not
> get a failure.
>
> Below is the documentation for actor.parameters.PortParameter
> --start--
> /**
> <p>This parameter creates an associated port that can be used to update
> the current value of the parameter. This parameter has two values,
> which may not be equal, a <i>current value</i> and a <i>persistent
> value</i>.
> The persistent value is returned by
> getExpression() and is set by any of three different mechanisms:</p>
> <ul>
> <li> calling setExpression();</li>
> <li> calling setToken(); and </li>
> <li> specifying a value as a constructor argument.</li>
> </ul>
> <p>
> All three of these will also set the current value, which is then
> equal to the persistent value.
> The current value is returned by get getToken()
> and is set by any of two different mechanisms:</p>
> <ul>
> <li> calling setCurrentValue();</li>
> <li> calling update() sets the current value if there is an associated
> port, and that port has a token to consume; and</li>
> </ul>
> These two techniques do not change the persistent value, so after
> these are used, the persistent value and current value may be different.
> <p>
> When using this parameter in an actor, care must be exercised
> to call update() exactly once per firing prior to calling getToken().
> Each time update() is called, a new token will be consumed from
> the associated port (if the port is connected and has a token).
> If this is called multiple times in an iteration, it may result in
> consuming tokens that were intended for subsequent iterations.
> Thus, for example, update() should not be called in fire() and then
> again in postfire(). Moreover, in some domains (such as DE),
> it is essential that if a token is provided on a port, that it
> is consumed. In DE, the actor will be repeatedly fired until
> the token is consumed. Thus, it is an error to not call update()
> once per iteration. For an example of an actor that uses this
> mechanism, see Ramp.</p>
> <p>
> If this actor is placed in a container that does not implement
> the TypedActor interface, then no associated port is created,
> and it functions as an ordinary parameter. This is useful,
> for example, if this is put in a library, where one would not
> want the associated port to appear.</p>
>
> <p>There are a few situations where PortParameter might not do what
> you expect:</p>
>
> <ol>
> <li> If it is used in a transparent composite actor, then a token provided
> to a PortParameter will never be read. A transparent composite actor
> is one without a director.
> <br>Workaround: Put a director in the composite.</br>
> </li>
>
> <li> Certain actors (such as the Integrator in CT) read parameter
> values only during initialization. During initialization, a
> PortParameter can only have a value set via the parameter (it
> can't have yet received a token). So if the initial value of the
> Integrator is set to the value of the PortParameter, then it will
> see only the parameter value, never the value provided via the
> port.
> <br>Workaround: Use a RunCompositeActor to contain the model with the
> Integrator.</br>
> </li>
> --end--
>
> Edward, feel free to chime in.
>
> _Christopher
>
> On 1/14/10 11:21 AM, Oliver Soong wrote:
>>
>> When PortParameters are attached on the port, but no token arrives,
>> what are they supposed to send? I'm under the impression that
>> attached ports aren't always guaranteed to receive a token, but I may
>> be mistaken.
>>
>> Oliver
>>
>>
>> On Thu, Jan 14, 2010 at 10:12 AM, ben leinfelder
>> <leinfelder at nceas.ucsb.edu> wrote:
>>>
>>> Christopher -
>>> You're right that the problem arises because RExpression does not always
>>> produce a token on the graphicsFileName output port. Should it?
>>> If that's the case then we can forget about any changes to StringReplace.
>>> I'd rather not be mucking around in there anyway.
>>> -ben
>>>
>>> On Jan 14, 2010, at 10:03 AM, Christopher Brooks wrote:
>>>
>>>> Hi Ben,
>>>> On http://bugzilla.ecoinformatics.org/show_bug.cgi?id=4549
>>>> I think the problem might be that RExpression is not producing
>>>> data every time it is fired? This would make it
>>>> difficult to use RExpression in SDF. I'm not sure about this
>>>> though.
>>>>
>>>> The issue is that StringReplace has port parameters, so
>>>> it can be used as a source with no inputs.
>>>>
>>>> Try running $PTII/ptolemy/actor/lib/string/test/auto/StringReplace2.xml
>>>> with your changes.
>>>>
>>>> I just backed out your changes because they break that test.
>>>> Sorry about that, but I'm in the process of building test releases
>>>> and don't want regressions right now.
>>>>
>>>> I believe that there is this generic issue with RExpression and
>>>> any actor that has PortParameters.
>>>>
>>>> I'm focussing on other things right now, but if you could create
>>>> a simple demo that illustrates the problem that does not use
>>>> RExpression, then we might get some traction here.
>>>>
>>>> _Christopher
>>>> --
>>>> 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 fax:510.642.2718 (Office: 545Q Cory)
>>>> home: (F-Tu) 707.665.0131 cell: 707.332.0670
>>>
>>> _______________________________________________
>>> Kepler-dev mailing list
>>> Kepler-dev at kepler-project.org
>>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>>>
>>
>>
>>
>
> --
> 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 fax:510.642.2718 (Office: 545Q Cory)
> home: (F-Tu) 707.665.0131 cell: 707.332.0670
>
--
Oliver Soong
Donald Bren School of Environmental Science & Management
University of California, Santa Barbara
Santa Barbara, CA 93106-5131
805-893-7044 (office)
610-291-9706 (cell)
More information about the Kepler-dev
mailing list