[kepler-dev] Kepler 2.0.0 and director development

Colin Enticott Colin.Enticott at csse.monash.edu.au
Sun Jun 27 19:44:14 PDT 2010


Thanks again Edward. I guess my first email was a little rushed as I
wrote it at the end of the day, trying to take advantage of the
different time zones.

The background, I have been developing a director for Kepler that
allows concurrent firing of actors (like the PN director) and
dynamically create new copies of actors to increase parallelism. (See:
http://messagelab.monash.edu.au/NimrodK/Publications).

The test workflow consists of two standard PtolemyII actors, “Ramp”
and “Display” connected with one relation from the Ramp’s output port
to the Display’s input port. The only option changed is the
firingCountLimit on the Ramp actor which is now set to “5”. When I run
with the Nimrod/K director, I do not dynamically make any copies of
the actors. So, Nimrod/K is acting like PN (but without the blocking).

This workflow works without fault with all directors in Kepler (that
supports this workflow). The Display’s output looks like:
0
1
2
3
4

This is also the output with the Nimrod/K director with Kepler 1.0.0.

The first symptom with the Nimrod/K director in Kepler 2 is the output
is different (this is where I suspect the ParameterPort is not working
properly):
0
0
0
0
0

The second symptom is the Display’s display window doesn’t have a
title. This one has me confused and that is why I checked that
preinitialize() and initialize() are being called. I even added
getWriteAccess() on those methods in case something else has changed
in the environment. Another thing to note is I call those two methods
with the actor’s assigned thread. I don’t call them concurrently
across all actors, but one at a time.

Once again, I am still stumped by this problem and the only way I know
how to continue will be very slow. That is, slowly pull the director
apart until it is single threaded and if the problem is still there,
continue to pull it apart to see when the symptoms change.

Any other tips on what I can try?

Thanks,
Colin


On 24 June 2010 22:14, Colin Enticott <Colin.Enticott at csse.monash.edu.au> wrote:
> Hi Edward,
>
> Yes, I am using an unmodified Ramp actor. The postfire method calls
> update() and then adds getToken() to the current output token for the
> next fire call. My best guess is getToken() is returning a nil/null or
> a number token of value 0. I have tried setting the step value to
> something else and also passed in a value to the port with no change.
>
> Regards,
> Colin
>
> On 24 June 2010 21:50, Edward A. Lee <eal at eecs.berkeley.edu> wrote:
>>
>> Are you calling update() on the PortParameter in your fire() method?
>>
>> Edward
>>
>>
>> On 6/24/10 1:56 AM, Colin Enticott wrote:
>>>
>>> Hi,
>>>
>>> I've finally started to test the Nimrod/K director with Keper 2.0 and
>>> besides some small changes in the Ptolemy API with method definitions
>>> and workflow locks, I've been able to get it mostly working. The
>>> problem that I am seeing now is that ParameterPort's getToken()
>>> doesn't return the correct value. It works under the other directors
>>> and it also works with the Nimrod/K director under Kepler 1.0. For
>>> example, two actors, Ramp and Display with the Ramp actor set to
>>> iterate 5 times will show 0,1,2,3,4. Under Nimrod/K, it shows
>>> 0,0,0,0,0. Another possible symptom is the Display actor will not show
>>> its name in the title bar with Nimrod/K. I've checked that I am call
>>> preinitialize and initialize before firing the actors, but this has me
>>> confused. Has there been any changes with the environment that
>>> requires changes to a director? If not, is there something else common
>>> between these two symptoms? And if not, then they could be two
>>> unrelated issues. :-(
>>>
>>> Thanks,
>>> Colin
>>> _______________________________________________
>>> Kepler-dev mailing list
>>> Kepler-dev at kepler-project.org
>>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>>
>
>
>
> --
> Colin
>



-- 
Colin


More information about the Kepler-dev mailing list