[kepler-dev] ptexecute problems?

Tue Dec 6 18:41:31 PST 2005

Hi Dan,
Well, the short answer is to definitely avoid using
PtExecuteApplication if the model does not need a ui.

I hacked up ptolemy.actor.gui.PtExecuteApplication and its parent
class MoMLApplication so that they are both more friendly about
printing stack traces.

The problem with these classes is that the use the MessageHandler
mechanism to display the stack trace.  If the error is in the
configuration mechanism, then we might have a chicken and egg problem
and the error might not be displayed in a separate window before the
Java process exits.

So, now the main() methods in these two classes catch exceptions
and print the stack trace to stderr.

Another issue is that these classes both create separate threads
to run the models.  If a model throws an exception, then
executionError() is called.  I modified executionError() so it calls
MessageHandler.error().  However, the problem here is that
if there is only one model, then the graphical message handler window
pops up and then quickly closes because the Java process is exiting.
So, I now print the stack trace to standard error and also
delay the exit process by two seconds so that the poor user
has a chance of seeing what went wrong.

I think this is a horrible hack, but I don't have any good ideas on
how to handle this for users running without a console.  To be honest,
if the model has a gui, then it probably expects user interaction,
so starting up a graphical model and then running it is a little
strange.

Edward will probably have input on my hacks here, we can probably
come up with a better solution.

_Christopher

--------

    Hi Dan,
    It looks like a bug with ptolemy.actor.gui.PtExecuteApplication.

    I usually use ptolemy.actor.gui.MoMLSimpleApplication instead of
    PtExecuteApplication because MoMLSimpleApplication does not
    extend MoMLApplication.

    MoMLApplication unfortunately sets the UI look and feel, which forces
    the process to try to connect to the X Server, which causes problems.

    I'll look in to fixing PtExecuteApplication.  Sorry for the delay
    on this, I did not realize that the ant ptexecute target used the
    same class as the Ptolemy $PTII/bin/ptexecute script.

    The problem can be replicated inside Ptolemy, without Kepler with:

    bash-3.00$ cd $PTII/ptolemy/domains/sdf/kernel/test/auto/knownFailedTests
    bash-3.00$ $PTII/bin/ptinvoke ptolemy.actor.gui.MoMLApplication tunneling2.
   xml 
    Loaded file:/C:/cxh/ptII/lib/ptII.properties
    bash-3.00$ $PTII/bin/ptinvoke ptolemy.actor.gui.MoMLSimpleApplication tunne
   ling2.xml 
    Command failed: ptolemy.kernel.util.IllegalActionException: Failed to compu
   te schedule:
      in .tunneling2.SDF6
    Because: No solution exists for the balance equations.
    Graph is not consistent under the SDF domain detected on external port .tun
   neling2.typed composite actor0.port
    ptolemy.kernel.util.IllegalActionException: Failed to compute schedule:
      in .tunneling2.SDF6
    Because: No solution exists for the balance equations.
    Graph is not consistent under the SDF domain detected on external port .tun
   neling2.typed composite actor0.port
          at ptolemy.domains.sdf.kernel.SDFDirector.preinitialize(SDFDirector.j
   ava:511)
          at ptolemy.actor.CompositeActor.preinitialize(CompositeActor.java:857
   )
          at ptolemy.actor.Manager.preinitializeAndResolveTypes(Manager.java:81
   0)
          at ptolemy.actor.Manager.initialize(Manager.java:513)
          at ptolemy.actor.Manager.execute(Manager.java:311)

    _Christopher
    --------

        Hi All,

            I have been looking at the 'ptexecute' target in ant (more 
        accurately, I have been using 'ptexecute-dev' which, like 'run-dev' 
        avoids the long jar process in running the target.) I have been getting

        some strange results.

            First of all, I created a test workflow called 'NonstrictTest.xml' 
        (in $KEPLER/workflows/test/). As configured, this trivial workflow has 
   a 
        NonstrictTest actor that expects a result of '4'. It is connected to an

        Expression actor that gives it a token equal to '5'. Thus, if you run 
        the workflow in Kepler, it throws an exception. However, if I execute

        ant ptexecute-dev -Dworkflow=C:/work/kepler/workflows/test/NonstrictTes
   t.xm
       l

        this ant task runs and gives no indication of any problem!

        However, if I change the test workflow to execute OK (by changing the 
        input to the NonstrictTest actor), the ptexecute-dev task gives the res
   ult

             [java] 47 ms. Memory: 3136K Free: 491K (16%)

        (which is what one sees in the terminal window if the workflow executes

        completely).

        So, my first problem is that ptexecute does not seem to generate any 
        error when the workflow fails!

            The next problem is with workflows that contain eml-datasources. Al
   l 
        of these immediately return with no indication of errors. However, ther
   e 
        are no messages from actors in the workflows subsequent to the 
        datasource. It looks like the datasource is just terminating the 
        execution of the workflow. I suspect that this is just due to ptexecute

        not waiting for the initialization thread of the datasource to complete
   !

        So, it looks to me like we cannot use ptexecute to test workflow 
        operation (since there are not errors when there are exceptions), and 
        ptexecute cannot be used with datasources that use threads in 
        initialization!  (Of course, maybe I am missing something here; I 
        haven't really looked into the ptexecute code.)

        Dan

        -- 
        *******************************************************************
        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 Sc
   ienc
       e Building - Room 3405
        Santa Barbara, CA 93195
        *******************************************************************

        _______________________________________________
        Kepler-dev mailing list
        Kepler-dev at ecoinformatics.org
        http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-de
   v
    --------
    _______________________________________________
    Kepler-dev mailing list
    Kepler-dev at ecoinformatics.org
    http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
--------