[kepler-dev] Bug 4549: String Replace actor "remembers" previous execution values
Christopher Brooks
cxh at eecs.berkeley.edu
Thu Jan 14 12:28:07 PST 2010
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: StringReplace2.xml
Type: text/xml
Size: 6489 bytes
Desc: not available
URL: <http://mercury.nceas.ucsb.edu/kepler/pipermail/kepler-dev/attachments/20100114/42cb66b9/attachment.xml>
More information about the Kepler-dev
mailing list