Replies: 3 comments 5 replies
-
I also thought about this possibility for lstosa some time ago. Here is another workflow management system: https://snakemake.readthedocs.io/ which also integrates the possibility of working with job schedulers like SLURM. |
Beta Was this translation helpful? Give feedback.
-
Maybe this idea is a good start to merge with lstosa (or maybe I am being too ambitious here). |
Beta Was this translation helpful? Give feedback.
-
There are many alternatives here, e.g. luigi / sciluigi: I evaluated some of them for the my monte carlo production / processing during my phd thesis and in the end used none of them because I wanted to have a database of jobs where I can track state and settings and none of the tools could work with that. In the end, I used peewee for the orm abstraction (probably would use sqlalchemy + alembic today) and a custom abstraction layer for submitting jobs to clusters (I implemented a slurm and a local worker cluster). https://github.com/fact-project/mopro3 The custom database first approach has some pretty great advantages, it allows debugging the workflows much more easily since you can e.g. ask for the log files of all failed runs like this:
|
Beta Was this translation helpful? Give feedback.
-
Seeing PR #111 and @LukasNickel comments, I am thinking that if we want to make something more generic and robust, maybe we should move to a proper workflow management system.
To consider:
Beta Was this translation helpful? Give feedback.
All reactions