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

Wed Mar 17 15:47:52 PDT 2010

Hi Christopher, Tomasz:

I since learned that the MonitorReceiverContents is actually part of the
current Kepler trunk.
It only wasn't searchable. Now that's also solved (thanks Sean!)

Tomasz:
It sounds what you really need though is a way to query a database that
keeps track of state.
Maybe the provenance recorder could help you...

Bertram

On Wed, Mar 17, 2010 at 3:26 PM, 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
>
> _______________________________________________
> Kepler-users mailing list
> Kepler-users at kepler-project.org
> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-users/attachments/20100317/260caeaa/attachment.html>