[kepler-users] String Feedback Loop
Christopher Brooks
cxh at eecs.berkeley.edu
Thu Oct 8 14:53:27 PDT 2009
Hi Jim,
[This is a summary to kepler-users]
Edward and I looked at your sample code, and the short summary is that
your LoopActor is not SDF because the LoopActor reads data and then
depending on the value of the token produces data on one or the other
ports.
To use DDF, you would need to write the actors so that they set the
appropriate parameters. The DDF design doc DDF chapter in
http://www.eecs.berkeley.edu/Pubs/TechRpts/2008/EECS-2008-37.html
says:
--start--
In SDF, the scheduling algorithm relies on the actors in the model to declare the data rate of each port with up to three parameters named tokenConsumptionRate, tokenProductionRate, and
tokenInitProduction. The production parameters are valid only for output ports, while the consumption parameter is valid only for input ports. If a valid parameter is not specified when the scheduler
runs, then default values of the parameters corresponding to a homogeneous actor will be assumed: input ports are assumed to have a consumption rate of one, output ports are assumed to have a
production rate of one, and no tokens produced during initialization. If there are multiple channels connected to a multiport, all channels are assumed to have the same rate given by the parameter.
In DDF, the director also relies on the tokenConsumptionRate parameter of each input port to determine whether an actor is enabled/deferrable. However, unlike an SDF actor, the dynamic nature of a DDF
actor dictates that this parameter will have a possible new value after each firing and thus must be updated if needed. The tokenProductionRate parameter has no use in DDF because for a general DDF
actor this information is not available before the actor gets fired. The tokenInitProduction parameter serves the same purpose as in SDF.
--end--
So, you would need to rewrite your actors to set tokenProductionRate
Edward suggested that you look at the DDF Loop demo at
ptolemy/domains/ddf/demo/Loop/Loop.xml which does something
like what you want to do.
In particular, look at ptolemy/domains/ddf/lib/DDFBooleanSelect.java,
which sets the consumption and production rates depending on the
value determinted in fire():
/** Update rate parameters for the next iteration.
* Then return whatever the superclass returns.
* @return True if execution can continue into the next iteration.
* @exception IllegalActionException If setToken() throws it.
*/
public boolean postfire() throws IllegalActionException {
if (_isControlRead) {
if (_control) {
trueInput_tokenConsumptionRate.setToken(_one);
falseInput_tokenConsumptionRate.setToken(_zero);
control_tokenConsumptionRate.setToken(_zero);
} else {
trueInput_tokenConsumptionRate.setToken(_zero);
falseInput_tokenConsumptionRate.setToken(_one);
control_tokenConsumptionRate.setToken(_zero);
}
} else {
trueInput_tokenConsumptionRate.setToken(_zero);
falseInput_tokenConsumptionRate.setToken(_zero);
control_tokenConsumptionRate.setToken(_one);
}
return super.postfire();
}
I checked your model into ptolemy/actor/lib/test/YOTCtest1.xml
When I replace the SDF Director with a PN Director, the model
runs, the output says:
No data yet
No data yet
No data yet
No data yet
No data yet
No data yet
No data yet
Results Found
and then I get an exception
ptolemy.kernel.util.IllegalActionException: Queue size 131072 exceeds the maximum capacity in port .YOTCtest1.LoopTest2.counter. Perhaps you have an unbounded queue?
in .YOTCtest1.PN Director
However, I get this after it runs and finds a result.
I think it needs to gracefully halt or starve.
The PN demo ptolemy/domains/pn/demo/RemoveNilTokens/RemoveNilTokens.xml
calls the Stop actor when the model sees 5 outputs.
I adapted your model to use a similar way to stop, see
the attached model.
Another way is to starve the model, see
ptolemy/domains/pn/demo/OrderedMerge/OrderedMerge.xml
_Christopher
Jim Amrhein wrote:
> Hi,
> I'm trying to get a "string feedback loop" that involves multiple
> actors, instead of normal single actor.
> The test I'm trying to do is have a Loop Actor build a search string
> based on Spatial region that gets executed in the Search Actor until we
> either find results or the search region grows to be +-90,+-180. Any
> results get sent back to the Loop Actor via an input String for
> confirmation, before being forwarded to other actors for processing.
> The Spatial region grows by 1 degree every iteration.
>
> The search Actor will aways return a String back to the Loop Actor's
> input.
> Which can either be "Found result" when a search is successful , or
> "No Data" when a search fails.
>
> But, I'm running into a various set of problems based on which Director
> I try to use:
>
> When using a SDF Director I get the normal Error "Actors remain cannot
> be scheduled!". I tried modify the SampleDelay actor to send "No Data",
> but that didn't work and I'm not planning to use numerical values.
> Eventually the "Found data" will be replaced with the actual Results found.
> ... PN Director , I see the Ramp executed once (with a value of
> "1"), then execution finishes, without any further output.
> ... DDF Director , The code executes without any output (none
> of the STDOUT messages I have get printed, even tho the loop completes)
>
> Any suggestions would be appreciated.
>
> Thanks,
> JSA
>
> _______________________________________________
> Kepler-users mailing list
> Kepler-users at kepler-project.org
> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users
--
Christopher Brooks (cxh at eecs berkeley edu) 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 (W-F) 510.655.5480
-------------- next part --------------
A non-text attachment was scrubbed...
Name: YOTCtest1PN.xml
Type: text/xml
Size: 28475 bytes
Desc: not available
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-users/attachments/20091008/50fca082/attachment.xml>
More information about the Kepler-users
mailing list