[kepler-dev] Kepler 2.0.0 and director development

[Colin Enticott]

Hi Edward,

Yes, I've been through the struggle of getting the threaded system
working nicely within another system. I pretty much threw myself into
the deep end but got something nice going under Kepler 1.0.

I've also tried connecting a constant to the ParameterPort and
received the same output. With the Display actor's display not having
a title, I think something is very odd going on.

Any insights to what might of changed between Kepler 1.0 and 2.0 that
could exhibit that behaviour? E.g. different initialization process
for some internal objects? Changes to the token passing process that
might not remove a token from the queue?

Thanks for the tip that it might be the same token. Tomorrow, I'll
start to follow the tokens and their references.

Thanks,
Colin

On 28 June 2010 20:43, Edward A. Lee <eal at eecs.berkeley.edu> wrote:
>
> Hi Colin,
>
> ParameterPort is pretty simply and fairly well vetted, so
> I really doubt that is the problem. In any case, the
> ParameterPort isn't connected in your example, so it will
> function exactly like a Parameter. If your director is like
> PN without blocking, then its behavior would be nondeterminate,
> so the output you are seeing might not be surprising. I suspect
> that your Display actor is simply re-reading the same input
> token with value 0, rather than that the Ramp actor is not
> incrementing the value.
>
> So it sounds to me like the standard struggles trying to
> get multithreaded code to work... This paper won't offer
> solutions, but at least it will explain why this is so hard:
>
> http://ptolemy.eecs.berkeley.edu/publications/papers/06/problemwithThreads/
>
> Edward
>
>
>
> On 6/27/10 7:44 PM, Colin Enticott wrote:
>>
>> 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