[kepler-users] When workflow's execution is finished, can actors' states be reported?

Christopher Brooks cxh at eecs.berkeley.edu
Wed Mar 24 12:32:35 PDT 2010


Hi Tomasz,
I submitted a bug about the attribute render problem.  This
problem occurs with other Attributes that contain text.  The
problem appears in the Kepler graph editor, but not in a vanilla
Ptolemy graph editor.  The bug is:
http://bugzilla.ecoinformatics.org/show_bug.cgi?id=4903

_Christopher


On 3/22/10 6:19 AM, Tomasz Żok wrote:
> Hi,
>
> Thank you for pointing me how to find and use MonitorReceiverContents.
> It is a great tool to debug workflows and I find it very helpful. It has
> already done great things for me and for sure will do more in my further
> works :)
>
> @Christopher: Btw. the attribute renders strangely in my Kepler instance
> as well.
>
> Thank you, best regards,
> Tomek
>
> On 17-03-2010 at 23:26:38 Christopher Brooks <cxh at eecs.berkeley.edu> wrote:
>> Hi Tomasz,
>>
>> MonitorReceiverContents is an Attribute, not an actor, and it is in
>> the Kepler svn devel tree.
>>
>>
>> http://ptolemy.berkeley.edu/ptolemyII/ptIIfaq.htm#kepler says:
>> --start--
>> Concerning using Ptolemy actors within Kepler, Norbert Podhorszki writes:
>>
>> If you find a Ptolemy actor useful, just remember its class name (e.g.
>> ptolemy.actor.lib.Ramp). In Kepler, "Tools/Instantiate Component" menu
>> allows you to type in the class name, which will put an actor instance
>> on your canvas just as dragging one from the actor tree.
>>
>> The ptolemy jar is stored in the kepler.jar, so you have access to any
>> Ptolemy actors and directors.
>>
>> If you want to use a director not in Kepler tree, you have to use the
>> "Tools/Instantiate Attribute" menu. I use it to get a DDF director
>> frequently (class ptolemy.domains.ddf.kernel.DDFDirector).
>>
>> I suppose, you can create a kar file for any ptolemy actor just as for
>> kepler actors, if you want to add some of them into the Kepler actor
>> tree.
>> --end--
>>
>> In a version of Kepler checked out from the svn tree, I did:
>> Tools->Instantiate Attribute
>> and entered
>> ptolemy.vergil.actor.lib.MonitorReceiverContents
>> and that created an attribute.
>>
>> I then ran the model and the ports had information displayed on them.
>>
>> Note that the attribute was rendered strangely, it looked kind of
>> squashed.
>> I'm not sure why.
>>
>> _Christopher
>>
>> On 3/17/10 2:49 PM, Tomasz Żok wrote:
>>> Hi Edward and Bertram,
>>>
>>> Thank you for pointing out the possible approaches.
>>>
>>> I have tried the "Listen to director" method some time ago. As far as I
>>> can remember, the output I got was totally unreadable and unmanagable (I
>>> am creating a big workflow, being executed for as long as few hours... I
>>> was overloaded with information from the director). And I think there
>>> were just information about calling fire() or postfire(), etc. but not a
>>> thing about tokens being received on ports. But I tried this approach in
>>> the past, maybe I'll try again soon.
>>>
>>> As for MonitorReceiverContents, I cannot find it in my Kepler-1.0.0
>>> installation. But as Bertram pointed out, there is no such actor in the
>>> recent checkout.
>>>
>>> And I am using DDF director.
>>>
>>> Thank you, best regards,
>>> Tomek
>>>
>>> On 16-03-2010 at 17:03:52 Bertram Ludaescher <ludaesch at ucdavis.edu>
>>> wrote:
>>>> Yes, I'm a fan of MonitorReceiverContents (thanks for implementing it
>>>> Edward! :)
>>>> It nicely shows the queue contents during execution. It also should
>>>> show
>>>> "left over queue content".
>>>>
>>>> Edward:
>>>> What is the set of domain for which this will (mostly) likely work?
>>>> (I'm primarily interested in SDF, DDF, and PN.)
>>>>
>>>> Also, is it correct to assume that runs that have "left over tokens"
>>>> are
>>>> still "valid" w.r.t. the Kahn semantics?
>>>> It would be interesting to define a declarative query or integrity
>>>> constraint (to use database parlance) that checks queue contents after
>>>> execution. One could then declare certain runs as "incomplete", i.e.,
>>>> if not
>>>> all queues have been emptied.
>>>>
>>>> On a related note:
>>>> When I do a search for "monitor" in a recent check-out of Kepler, I
>>>> don't
>>>> see 'MonitorReceiverContents'.
>>>>
>>>> Can we still add it? Maybe as part of a suitable module? Chad, David?
>>>>
>>>> Bertram
>>>>
>>>> On Tue, Mar 16, 2010 at 8:49 AM, Edward A. Lee
>>>> <eal at eecs.berkeley.edu>wrote:
>>>>
>>>>>
>>>>> I'm not sure about Kepler, but in Ptolemy the Debug menu includes
>>>>> Listen to Director, which will give you this information. It's
>>>>> in the friendliest form, however...
>>>>>
>>>>> Also, in the Utilities->Analysis menu there is a component
>>>>> called MonitorReceiverContents. Dragging this into the model will
>>>>> enable display of data in buffers. This only works for certain
>>>>> domains, however. I'm not sure which director you are using...
>>>>>
>>>>> Edward
>>>>>
>>>>>
>>>>>
>>>>> On 3/16/10 3:26 AM, Tomasz Żok wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I have some workflow, I run it and after some time it stops -
>>>>>> "execution
>>>>>> finished". At this exact moment I would like to know, which actors
>>>>>> had
>>>>>> tokens on some port, but were unable to fire.
>>>>>>
>>>>>> For instance, an actor named "A" has five input ports. During
>>>>>> execution
>>>>>> tokens are fired to four out of these five. The director decides
>>>>>> there
>>>>>> is nothing else to be fired and finishes the execution. When this
>>>>>> happens I would just like to know, that: Actor "A" did not fire, but
>>>>>> some of its ports received tokens.
>>>>>>
>>>>>> Is this possible in Kepler? It would greatly enhance the debugging
>>>>>> experience of really big and complicated workflows :)
>>>>>>
>>>>>> Best regards,
>>>>>> Tomek
>

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



More information about the Kepler-users mailing list