[kepler-dev] Kepler 2.0.0 and director development

Mon Jun 28 08:50:46 PDT 2010

Hi Colin,
In Ptolemy, a PN model that is a Ramp with firingCountLimit 5
connected to a Display works as expected.

One way to track this down would be the brute force method
of trying different development versions of Kepler from the
past and see when the change occurred.  It might be easier
to check out different versions of Ptolemy, since your code
is really director based.

To checkout and build a Ptolemy II tree from 2010, use:

svn -r {2010-01-01} https://source.eecs.berkeley.edu/svn/chess/ptII/trunk ptII2010-01-01
cd ptII2010-01-01
./configure
make >& make.out
$PTII/bin/vergil

The tricky part is that you will need to have your Nimrod/K code
compile with just Ptolemy.  Ideally, you would recompile it with
the version of Ptolemy under test.

The idea here is that you try to find a version that works and then
split the difference in dates with a version that does not and repeat.
Kepler-1.0.0 was released in May, 2008.  We split the tree earlier
than that, I would start with Ptolemy II from January 15, 2008.  The
process sounds more labor intensive than it is, I usually do these
build as a background process while I'm doing other things.

Another way is to look at the ChangeLogs, see
http://chess.eecs.berkeley.edu/ptexternal/nightly/ChangeLog.txt
I would look in pn/kernel, actor and actor/process

You can also get the logs just for a directory with:
   cd $PTII/ptolemy/domains/pn/kernel
   svn log

One other thing to try is to not use Display because it interacts with
the Java Swing thread.  Try writing your output to a file.
Also, watch out for Ramp's iterate() method.  Ramp is surprisingly
complex and I've been debugging SDF code and "forgotten" that
Ramp's iterate() method is being called instead of prefire(), fire()
postfire().

_Christopher

On 6/28/10 5:13 AM, Colin Enticott wrote:
> 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
>>>>
>>>
>>>
>>>
>>
>
>
>

-- 
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