Apparently it works fine when I replace all the “begin -- Skip(task, cond)” patterns by simply “task”, i.e., an unconditional execution of the tasks.
Note that without this change, it would not even install the runtime in the sharedDirectory of the CondorEnvironment, indicating that it (wrongly) doesn’t expect to run any task on this environment. > On 15 May 2015, at 14:59, Andreas Schuh <[email protected]> wrote: > > Hi, > > my workflow was working fine on Monday/Tuesday. Then I had to stop it to move > the output directory as the disk space was getting low. After restarting the > workflow, I noticed that output files were for mysterious reasons no longer > written by OpenMOLE to the destination even though the processes finished > successfully. But that’s another topic… I was going to investigate this > further with the latest OpenMOLE master branch. Unfortunately my workflow > didn’t run anymore with this new built. Going back to a previous commit > didn’t help me either. > > To help debug the issue, I put all my workflow in a single OpenMOLE batch > script and replaced the code of the ScalaTask’s by some dummy code that just > writes text files instead and not execute my actual binary executables. It > will also generate the input files if not present in the current working > directory yet during setup. > > The workflow executes fine using the LocalEnvironment, but not in the > CondorEnvironment with storageSharedLocally and a custom sharedDirectory. For > some reason it does not execute the task in the Skip and therefore the output > file needed by the following task is not generated, raising errors such as: > > May 15, 2015 2:59:00 PM org.openmole.core.batch.refresh.JobManager $bang > FINE: Error in job refresh > java.io.FileNotFoundException: > /vol/bitbucket/as12312/OpenMOLEStrainerCapsuleTest/dofs/reg_f3d-aff/1,2.txt > (No such file or directory) > at java.io.FileInputStream.open(Native Method) > at java.io.FileInputStream.<init>(FileInputStream.java:146) > at org.openmole.tool.hash.package$.computeHash(package.scala:39) > at > org.openmole.core.fileservice.FileService$$anonfun$hash$1.apply(FileService.scala:51) > at > org.openmole.core.fileservice.FileService$$anonfun$hash$1.apply(FileService.scala:51) > at > scala.collection.mutable.MapLike$class.getOrElseUpdate(MapLike.scala:194) > at > org.openmole.core.tools.cache.AssociativeCache$$anonfun$cacheMap$1$$anon$2.scala$collection$mutable$SynchronizedMap$$super$getOrElseUpdate(AssociativeCache.scala:46) > at > scala.collection.mutable.SynchronizedMap$class.getOrElseUpdate(SynchronizedMap.scala:40) > at > org.openmole.core.tools.cache.AssociativeCache$$anonfun$cacheMap$1$$anon$2.getOrElseUpdate(AssociativeCache.scala:46) > at > org.openmole.core.tools.cache.AssociativeCache.cache(AssociativeCache.scala:42) > at org.openmole.core.fileservice.FileService$.hash(FileService.scala:48) > at > org.openmole.core.batch.refresh.UploadActor$$anonfun$org$openmole$core$batch$refresh$UploadActor$$initCommunication$1$$anonfun$1.apply(UploadActor.scala:75) > at > org.openmole.core.batch.refresh.UploadActor$$anonfun$org$openmole$core$batch$refresh$UploadActor$$initCommunication$1$$anonfun$1.apply(UploadActor.scala:75) > at > scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:245) > at > scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:245) > at > scala.collection.immutable.RedBlackTree$._foreachKey(RedBlackTree.scala:109) > at > scala.collection.immutable.RedBlackTree$._foreachKey(RedBlackTree.scala:108) > at > scala.collection.immutable.RedBlackTree$.foreachKey(RedBlackTree.scala:105) > at scala.collection.immutable.TreeSet.foreach(TreeSet.scala:154) > at scala.collection.TraversableLike$class.map(TraversableLike.scala:245) > at > scala.collection.immutable.TreeSet.scala$collection$SetLike$$super$map(TreeSet.scala:53) > at scala.collection.SetLike$class.map(SetLike.scala:92) > at scala.collection.immutable.TreeSet.map(TreeSet.scala:53) > at > org.openmole.core.batch.refresh.UploadActor$$anonfun$org$openmole$core$batch$refresh$UploadActor$$initCommunication$1.apply(UploadActor.scala:75) > at > org.openmole.core.batch.refresh.UploadActor$$anonfun$org$openmole$core$batch$refresh$UploadActor$$initCommunication$1.apply(UploadActor.scala:65) > at > org.openmole.core.workspace.Workspace.withTmpFile(Workspace.scala:211) > at > org.openmole.core.batch.refresh.UploadActor.org$openmole$core$batch$refresh$UploadActor$$initCommunication(UploadActor.scala:65) > at > org.openmole.core.batch.refresh.UploadActor$$anonfun$receive$1.apply$mcV$sp(UploadActor.scala:54) > at > org.openmole.core.batch.refresh.UploadActor$$anonfun$receive$1.apply(UploadActor.scala:50) > at > org.openmole.core.batch.refresh.UploadActor$$anonfun$receive$1.apply(UploadActor.scala:50) > at > org.openmole.core.batch.refresh.package$.withRunFinalization(package.scala:23) > at > org.openmole.core.batch.refresh.UploadActor.receive(UploadActor.scala:50) > at > org.openmole.core.batch.refresh.JobManager$DispatcherActor$.receive(JobManager.scala:81) > at > org.openmole.core.batch.refresh.JobManager$$anonfun$1$$anon$1.run(JobManager.scala:63) > > > Andreas > > <RepeatStrainerCapsuleTest.scala> > >> On 11 May 2015, at 02:09, Andreas Schuh <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi Romain, >> >> that is of course right. I tried this morning with some dummy workflow but >> everything worked just fine, which indicates this is really rather some >> mistake in my specific workflow. Since then, I’ve rewritten and extended >> this workflow and have not encountered any further issue with the strainer >> capsules. >> >> Andreas >> >>> On 8 May 2015, at 11:13, Romain Reuillon <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hi Andreas, >>> >>> it is hard to diagnose with such a massive workflow. Could you reproduce >>> this behaviour with a minimalist one? >>> >>> Romain >>> >>> >>> >>> Le 07/05/2015 20:26, Andreas Schuh a écrit : >>>> Hi, >>>> >>>> I have the following linked workflow in my REPEAT plugin, where the puzzle >>>> of interest at the moment is “RegisterImages” which is part of the “run” >>>> sub-workflow in the RunRegistration.scala file. In the apply function of >>>> the RegisterImages object, I create this puzzle piece using strainer >>>> capsules such that I don’t have to know/pass all Prototype variables as >>>> arguments. The problem with this is that the registration task is never >>>> executed and either the output file handling of OpenMOLE, the CopyFileHook >>>> or a following task produces a FileNotFoundException for the phiDof output >>>> File which was never produced by the task. >>>> >>>> When I don’t use a strainer capsule for the tasks named >>>> “RegisterImagesBegin” and “RegisterImages” in RegisterImages.scala >>>> everything works fine. >>>> >>>> I am curious why I cannot get it to work with strainer capsules and what >>>> is wrong with below code ? >>>> >>>> Workflow: RunRegistration.scala >>>> <https://github.com/schuhschuh/REPEAT/blob/2f53c2fab2393596aec71d8446a850602ceb61cc/src/main/scala/com/andreasschuh/repeat/workflow/RunRegistration.scala> >>>> Puzzle: RegisterImages.scala >>>> <https://github.com/schuhschuh/REPEAT/blob/2f53c2fab2393596aec71d8446a850602ceb61cc/src/main/scala/com/andreasschuh/repeat/puzzle/RegisterImages.scala#L116> >>>> >>>> Thanks, >>>> Andreas >>>> >>>> >>>> _______________________________________________ >>>> OpenMOLE-users mailing list >>>> [email protected] <mailto:[email protected]> >>>> http://fedex.iscpif.fr/mailman/listinfo/openmole-users >>>> <http://fedex.iscpif.fr/mailman/listinfo/openmole-users> >>> >>> _______________________________________________ >>> OpenMOLE-users mailing list >>> [email protected] <mailto:[email protected]> >>> http://fedex.iscpif.fr/mailman/listinfo/openmole-users >>> <http://fedex.iscpif.fr/mailman/listinfo/openmole-users> >> >
_______________________________________________ OpenMOLE-users mailing list [email protected] http://fedex.iscpif.fr/mailman/listinfo/openmole-users
