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

[Tomasz Żok]

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

-- 
Tomasz Zok
Poznan Supercomputing and Networking Center
ul. Noskowskiego 10, 61-704 Poznan, POLAND
http://www.man.poznan.pl