Kepler

fixed the mac problem by adding a plugins symlink to the working dir.

this workflow crashes on windows almost immediately after beginning execution. on ubuntu, it doesn't crash until almost all the way through execution.

workflow completes successfully on OSX

got this to work on windows and mostly on linux. it wasn't working due to the setting of the .kepler directory as the R working dir. I'm not sure why this was causing a problem, but I've mapped a property to change the working directory for the R actor that feeds into the GarpPresampleLayers actor.

The windows workflow fully executes. On linux, however, it gets to the end, then displays an exception that says "Port should produce 1 tokens, but there were 0 tokens available." I thought that Christopher had fixed a similar bug earlier. I'm not sure what's causing it. I don't see the error on windows or OSX.

Here's the full stack trace:
ptolemy.kernel.util.IllegalActionException: Port should produce 1 tokens, but there were only 0 tokens available.
in .GARP_MultipleSpecies-V.Single Species GARP Model.Calculate Best Rulesets.Calculate Omission/Commission.SDF Director and .GARP_MultipleSpecies-V.Single Species GARP Model.Calculate Best Rulesets.Calculate Omission/Commission.omission
at ptolemy.domains.sdf.kernel.SDFDirector.transferOutputs(SDFDirector.java:742)
at ptolemy.actor.CompositeActor.fire(CompositeActor.java:411)
at ptolemy.actor.CompositeActor.iterate(CompositeActor.java:787)
at ptolemy.actor.sched.StaticSchedulingDirector.fire(StaticSchedulingDirector.java:170)
at ptolemy.actor.CompositeActor.fire(CompositeActor.java:400)
at ptolemy.actor.CompositeActor.iterate(CompositeActor.java:787)
at ptolemy.actor.sched.StaticSchedulingDirector.fire(StaticSchedulingDirector.java:170)
at ptolemy.actor.lib.hoc.LifeCycleManager._fireInsideModel(LifeCycleManager.java:334)
at ptolemy.actor.lib.hoc.LifeCycleManager._executeInsideModel(LifeCycleManager.java:289)
at ptolemy.actor.lib.hoc.RunCompositeActor.fire(RunCompositeActor.java:204)
at ptolemy.actor.CompositeActor.iterate(CompositeActor.java:787)
at ptolemy.actor.sched.StaticSchedulingDirector.fire(StaticSchedulingDirector.java:170)
at ptolemy.actor.CompositeActor.fire(CompositeActor.java:400)
at ptolemy.actor.Manager.iterate(Manager.java:688)
at ptolemy.actor.Manager.execute(Manager.java:332)
at ptolemy.actor.Manager.run(Manager.java:1071)
at ptolemy.actor.Manager$3.run(Manager.java:1112)

added a note in the workflow and in the README about scew and expat on linux.

running this workflow on my linux box (ubuntu 7.10) crashes Kepler with no error shown nor logged to the log file.

In ubuntu, it crashed keper twice:
*done with main garp algorithm**
DONE Calling RunGarpAlgorithm in CPP Code.
Finished with GarpAlgorithm JNI code
firing GarpPrediction
Starting GarpPrediction JNI Code
Calling DoGarpPrediction in CPP Code.
*in DoGarpPrediction cpp code*
Aborted (core dumped)

In windows v3 installer, runs for several minutes, generates several maps and then gives

ptolemy.kernel.util.IllegalActionException: Expression invalid.
in .GARP_MultipleSpecies-V.Get Species/Location information.LocationFilename
Because:
The index '1' is out of bounds on the array '{""}'.
at ptolemy.actor.lib.Expression.fire(Expression.java:232)
at ptolemy.actor.AtomicActor.iterate(AtomicActor.java:398)
at ptolemy.actor.sched.StaticSchedulingDirector.fire(StaticSchedulingDirector.java:170)
at ptolemy.actor.CompositeActor.fire(CompositeActor.java:400)
at ptolemy.actor.Manager.iterate(Manager.java:688)
at ptolemy.actor.Manager.execute(Manager.java:332)
at ptolemy.actor.Manager.run(Manager.java:1071)
at ptolemy.actor.Manager$3.run(Manager.java:1112)
Caused by: ptolemy.kernel.util.IllegalActionException: The index '1' is out of bounds on the array '{""}'.
at ptolemy.data.expr.ParseTreeEvaluator._evaluateArrayIndex(ParseTreeEvaluator.java:1161)
at ptolemy.data.expr.ParseTreeEvaluator.visitFunctionApplicationNode(ParseTreeEvaluator.java:310)
at ptolemy.data.expr.ASTPtFunctionApplicationNode.visit(ASTPtFunctionApplicationNode.java:96)
at ptolemy.data.expr.ParseTreeEvaluator.evaluateParseTree(ParseTreeEvaluator.java:93)
at ptolemy.actor.lib.Expression.fire(Expression.java:227)
... 7 more
Caused by: ptolemy.kernel.util.IllegalActionException: The index '1' is out of bounds on the array '{""}'.
at ptolemy.data.expr.ParseTreeEvaluator._evaluateArrayIndex(ParseTreeEvaluator.java:1161)
at ptolemy.data.expr.ParseTreeEvaluator.visitFunctionApplicationNode(ParseTreeEvaluator.java:310)
at ptolemy.data.expr.ASTPtFunctionApplicationNode.visit(ASTPtFunctionApplicationNode.java:96)
at ptolemy.data.expr.ParseTreeEvaluator.evaluateParseTree(ParseTreeEvaluator.java:93)
at ptolemy.actor.lib.Expression.fire(Expression.java:227)
at ptolemy.actor.AtomicActor.iterate(AtomicActor.java:398)
at ptolemy.actor.sched.StaticSchedulingDirector.fire(StaticSchedulingDirector.java:170)
at ptolemy.actor.CompositeActor.fire(CompositeActor.java:400)
at ptolemy.actor.Manager.iterate(Manager.java:688)
at ptolemy.actor.Manager.execute(Manager.java:332)
at ptolemy.actor.Manager.run(Manager.java:1071)
at ptolemy.actor.Manager$3.run(Manager.java:1112)

jing and ben - did you get ubuntu crashes after following the expat and scew instructions?
chad - i followed those but it still crashed on me ala the core dump jing posted. however i went through the instructions quickly yesterday,, so it's possible i missed something (btw the last instructions is to run ant, but that won't work with the installer version obviously). i won't be able to test on my ubuntu box until monday

This complex workflow depends on a lot of external dependencies. If any one of them fail, the workflow fails. I've been playing with it all day trying to narrow down what we could do to make it more stable. short of redesigning it to run only in java and not using external file sources, I'm not sure there is anything we can do. 90% of the time on windows and OSX, it runs fine. Why it chooses to fail sometimes, I'm not completely sure. I've played with filename variables, R script working directories, file sources, etc. Everytime I think it's fixed, it eventually will lock up, crash or somehow break.

My thinking on this right now is we should not hold up the kepler release because of this (and the other GARP-SingleSpecies_BestRuleSet) workflow. I'm aware that GARP is a key part of SEEK and I would really like it to work flawlessly, but at this point, I don't think it's going to without a lot of work. I move to push these bugs to 1.1 and release Kepler as it is. We could add a caveat to the GARP workflows letting people know we know about problems and giving some basic solutions. I think if we try to solve all of these problems with GARP, Kepler is not going to be released for at least a month or probably more.

Any comments? Please say whether you think the GARP workflows working perfectly should be a pre-requisite for releasing kepler. I've marked this as "major" so that it stands out in the search results until we resolve this.

Chad - As the creator of this workflow, I should have great insights into what is wrong - but I don't!
I would guess that there is some thread problem somewhere. I am assuming the the single species GARP workflow is running OK?

I don't think anyone is using this wf for any active research, so it would seem OK to me to not let intermittent problems stop the release of Kepler 1.0

Dan Higgins

Matt and I have decided to go ahead an release these workflows with the
following annotation attached:

ATTENTION ENM USERS:
As of Kepler release 1.0 we have worked hard to make the ENM workflows as
stable as possible.
Due to several complexities involving the implementation of GARP in the
workfows,
there are some known bugs that may cause the workflow to not function
correctly, terminate
early or crash Kepler altogether. We will continue working on these problems
after release 1.0.
Please see bug 3266 at http://bugzilla.ecoinformatics.org for a full
description of these problems.

Original Bugzilla ID was 3266