[kepler-users] Monitoring Workflow

Christopher Brooks cxh at eecs.berkeley.edu
Wed May 17 15:22:43 PDT 2006


Hi Mohana,

In the past, the Ptolemy project has referred to this as
Design Flow Managemenent (DFM).  It sounds like in your system, each
actor is a standalone subprocess.  The connections between actors are
much like Unix style pipes.  Ptolemy II does not have the
functionality you are looking for.  I was working on getting
a simple shell working, where one typed subcommands into a window
which were executed in a shell process and the results printed.
It turns out that this can be difficult since the commands are
really subcommands executed in a single process so it is difficult
to determine exactly when the subcommand is over.  Error handling
makes this even worse.  The way to go about it is to use PN (I think).

Anyway, a DFM domain would not be that difficult to implement,
but we have no plans to do it.  I'm not sure about restarting a
simulation that has failed though.  This requires quite a bit of
state. 

Yes, parameters in a parent container are accessible in the
subcontainer.
See 2.5.1 in 
http://ptolemy/ptolemyII/ptII5.0/ptII5.0.1/doc/design/ptIIdesign1-intro.pdf

_Christopehr

 



--------

    Hi Christopher,
    
    Lets say that I design a workflow in which a sequence of a steps(each 
    step is an executable) are carried out.  The  workflow can be designed 
    such that  the returncode of the each of the exceutables is tested  and 
    then a decision is made whether to stop or not. This becomes cumbersome 
    design. As a workflow system, it is highly desirable that "something"  
    keeps track of this. If the executables are launched via the External 
    Execution Environment actors then the actors could be set to halt the 
    flow if the command fails. These actors could notify using email. Email 
    id to notify to could be set at the actor level (preferable at the 
    workflow level so that each execution actor need not be supplied the 
    email). That brings me to my next question: is it possible to set a 
    parameters  in workflow A and access it within a sub-workflow in A?
    
    By retsart I mean: If there were ten steps and step 5 failed. Is it 
    possible to  restart the  workflow  from step  5?
    
    Thanks for the links to the ptolemy and I will look at them
    
    Mohana
    
    
    
    Christopher Brooks wrote:
    
    >Hi Mohana,
    >
    >How would you notify the user of the failure?  By sending email?
    >
    >How would an actor restart from the step that failed?  Do you mean
    >restarting a simulation from the global state just before the failure?
    >In general, this is hard and not supported.  Ptolemy II does have some new
    >experimental backtracking code, but it does not checkpoint the entire
    >simulation.
    >
    >In Ptolemy we call this lifecycle management.  The Ptolemy II 5.0 
    >release notes say:
    >--start--
    ># Higher Order Components: ExecDemos (see also IterateOverArray).
    >(http://ptolemy/ptolemyII/ptII5.0/ptII5.0.1/ptolemy/actor/lib/hoc/demo/Ite
   rateOverArray/IterateOverArray.htm
    >or $PTII/ptolemy/actor/lib/hoc/demo/IterateOverArray/IterateOverArray.htm)
    >
    >The higher-order component capabilities of Ptolemy II continue to
    >evolve. The ExecDemos model, when executed, starts a new Java virtual
    >machine that then executes the RunDemos model, which runs all demos in
    >a specified directory using full-screen mode. This illustrates how to
    >use higher-order actors to control the lifecylcle of other Ptolemy II
    >models. This example can be set up to automatically and repeatedly run
    >demos unattended by following the instructions in the README.txt
    >file. The new higher-order actors include:
    >
    >    * ApplyFilterOverArray
    >    * ApplyFunction
    >    * ApplyFunctionOverSequence
    >    * IterateOverArray 
    >--end--
    >
    >You could also look ptolemy/actor/lib/ThrowModelError.java, which
    >throws an exception that can then be caught by a container.
    >
    >_Christopher
    >
    >Christopher Brooks (cxh at eecs berkeley edu) University of California
    >Programmer/Analyst Chess/Ptolemy/Trust        US Mail: 558 Cory Hall #1770
    >ph: 510.643.9841 fax:510.642.2739	      Berkeley, CA 94720-1770
    >home: (F-Tu) 707.665.0131 (W-F) 510.655.5480  (office: 400A Cory)
    >
    >
    >
    >Dan writes:
    >--------
    >
    >    Hi,
    >        The 'Listen to Director' menu item under the 'Tools' menu is  
    >    sometimes useful for obtaining information about where a workflow fail
   s. 
    >    Currently there is no restart mode that I know of (although we have 
    >    discussed the need for such a thing).
    >    
    >    Dan
    >    
    >    Mohana Ramaratnam wrote:
    >    > Hello,
    >    >
    >    > Is there a workflow monitor that already exists. What I mean by that
    is:
    >    >
    >    > I have designed a workflow and for some reason a step in that flow 
    >    > fails. Is kepler/director capable of notifying that the workflow fai
   led 
    >    > and also is there a recovery mode where kepler/actor can restart fro
   m 
    >    > the step which failed.
    >    >
    >    > Mohana
    >    > _______________________________________________
    >    > Kepler-users mailing list
    >    > Kepler-users at ecoinformatics.org
    >    > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler
   -user
    >   s
    >    >   
    >    
    >    
    >    -- 
    >    *******************************************************************
    >    Dan Higgins                                  higgins at nceas.ucsb.edu
    >    http://www.nceas.ucsb.edu/    Ph: 805-893-5127
    >    National Center for Ecological Analysis and Synthesis (NCEAS) Marine S
   cienc
    >   e Building - Room 3405
    >    Santa Barbara, CA 93195
    >    *******************************************************************
    >    
    >    
    >    _______________________________________________
    >    Kepler-users mailing list
    >    Kepler-users at ecoinformatics.org
    >    http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-u
   sers
    >--------
    >
    >  
    >
--------



More information about the Kepler-users mailing list