initialize() is called multiple times during a run if you use modal models with reset transitions. Modal models are documented here:
http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-151.html Edward Rick Moore wrote: > Tom, > some additional comments are in line > Rick > > Tom Parris wrote: >> Rick, >> >> Thanks! This is very helpful. I'll read the Ptolemy document more >> thoroughly and try again. >> >> The basic challenge I'm having is translating from java examples to >> python. I've been experimenting with the optional methods. In the >> Java examples I've been looking at (e.g., Repeat, DownSample) the >> constructor method is used to: create and set parameters, and sets the >> input_tokenConsumptionRate and output_tokenConsumptionRate. The same >> is true for SDFTranformer (from which these examples are subclassed). >> That is what led me to try the same in Python (with the __init__ >> method). >> > the initialize(0 and preinitialize() methods provide support for what > you would normally do in __init__(). preinitialize() is called just once > in each run, however, there are circumstances where initialize() may be > called more than once ... I don;t understand what those circumstances > are. In practice, I use preinitialize() to read true parameters (those > defined in "Configure Actor") and store them into Python instance > attributes. >> The other challenge I'm having is reading n elements from an input >> port, but only consuming m elements (where 0<=m<=n) in order to >> implement sliding window actors. Given the code for IOPort.java, I'm >> not convinced this is even possible. It looks (to the untrained eye) >> that every call to get implicitly pops tokens off the channel. > You must read all tokens from a port on each fire. My suggestion is to > read the all of the tokens and either store the extras in a Python > attribute or just ignore them. >> >> I'll work both challenges some more and get back to you offline if I >> still need help. >> >> -- Tom >> >> On Tue, Nov 24, 2009 at 11:04 AM, Rick Moore <rem63 at cornell.edu >> <mailto:rem63 at cornell.edu>> wrote: >> >> Tom, >> >> I ran your workflow and both ports had the correct values ... but >> your script doesn't currently do anything with the blocksize >> except print it to stdout (which in kepler is the console). And >> that works as well. >> >> A PythonActor doesn't communicate with it's scripts through the >> standard Python __init__ method. Rather it expects the Python >> scripts to implement the same methods that a Java actor might >> implement. Of course, you already use fire(), but there are >> several other optional methods available : >> >> def preinitialize(self) ... set port types and/or scheduling >> information ... >> def initialize(self) ... initialize local variables ... >> def prefire(self) ... determine whether firing should proceed ... >> a good place to check whether the execution environment is valid >> if you use it, it must return True to proceed, False if >> there is some problem ... no return value is the same as False >> the fire(0 method will be called only if prefire() returns True >> def postfire(self) ... update persistent state and/or determine >> whether firing should continue to next iteration >> if you use it, it must return True to proceed, False if >> there is some problem ... no return value is the same as False >> returning False will terminate the workflow >> def wrapup(self) ... cleanup and display final results ... >> I use this to reset to the initial state after the last iteration >> >> Designing actors is discussed in detail in chapter 5 of the >> document at >> http://www.eecs.berkeley.edu/Pubs/TechRpts/2008/EECS-2008-28.pdf >> >> If you want, I can help you in more detail off list. >> >> Rick Moore >> Information Science >> Cornell University >> >> "Once in a while you will be shown the light in the strangest of >> places, if you look at it right" >> from Scarlet Begonias by the Grateful Dead >> >> Tom Parris wrote: >>> Dear Keplerites: >>> >>> I have been making steady progress understanding how to write >>> actors for Kepler using the PythonScript actor. However, I have >>> hit a stumbling block in my attempts to set >>> input_tokenConsumptionRate. >>> >>> To illustrate my problem, I have attached a simple workflow with >>> an actor titled "IntTokenSum" written with the PythonScript >>> actor. This actor is designed to add some number of integer >>> tokens from it's "input" port. The number of tokens is defined >>> by the "windowsize" port. The number of tokens to consume with >>> each "fire" is defined with the "blocksize" port. The current >>> version works as desired with the exception of the blocksize >>> input prot (it always takes on the value of the windowsize input >>> port). >>> >>> Q1: As the script is currently configured, the windowsize >>> parameter works as advertised. However, I can't seem to get the >>> blocksize parameter to work. I've tried a number of approaches >>> to setting the input_tokenConsumptionRate per the java code for >>> several actors (e.g., DownSample). But now I'm wondering if that >>> is the correct approach. Perhaps its the call to self.input.get >>> that needs to be changed. Correct output on Display2 should be >>> the sequence: 1, 3, 5, 7, 9, 11, 13, 15, 17. >>> >>> Q2: I'd also like to use an actor along these lines under the SDF >>> director with portparameters for windowsize and blocksize. But >>> can't figure out how to to this with the PythonScript actor. Is >>> this possible? If so, I would welcome guidance. >>> >>> Q3: Finally, it should be fairly easy to make this actor >>> polymorphic. I think this can be done by changing the line: >>> >>> val = val + it.intValue() >>> >>> to >>> >>> val = it.add(val) >>> >>> But I am not sure how to initialize val to the additive identity >>> (generalized notion of zero). >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Kepler-users mailing list >>> Kepler-users at kepler-project.org <mailto:Kepler-users at >>> kepler-project.org> >>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-user >> > > ------------------------------------------------------------------------ > > _______________________________________________ > Kepler-users mailing list > Kepler-users at kepler-project.org > http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users -------------- next part -------------- A non-text attachment was scrubbed... Name: eal.vcf Type: text/x-vcard Size: 351 bytes Desc: not available URL: <http://mercury.nceas.ucsb.edu/kepler/pipermail/kepler-users/attachments/20091124/ec4ac26d/attachment.vcf>
