From: John Kitchin <email@example.com>
To: Christoph Groth <firstname.lastname@example.org>
Cc: "email@example.com" <firstname.lastname@example.org>
Subject: Re: babel and long-running computations
Date: Sun, 20 Apr 2014 09:29:33 -0400 [thread overview]
Message-ID: <CAJ51ETqAUdey5tuE62fAQ0hNPH+kD_0CfOYKmd_5tbpkk5p-ZA@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2014 bytes --]
You are describing what I see as a need to run processes asynchronously.
We use the Torque queue system for this. It takes care of scheduling and
running jobs on a cluster.
On Thu, Apr 17, 2014 at 6:52 AM, Christoph Groth
> Hi Julian,
> > Generally, org-babel is suited for long running computations. Its
> > caching can help you avoid rerunning code chunks. And long runtime does
> > not conflict with the idea of reproducible research, it just may be not
> > very comfortable for the user.
> I agree of course that it’s generally a good idea to structure the
> analysis in small logical steps and to save intermediate results. Let
> me narrow down my question then: does org-babel support working with
> tasks that take several minutes to execute? By this I mean (most
> important first):
> - Not freezing the editor during the execution of a task
You code-block should exit if a job is submitted, and record the job-id so
that you can check it later. Alternatively, you could do this in ipython
notebooks if you have python functions that return jobids.
> - Being able to execute multiple independent tasks in parallel
No problem. this is what queue systems were designed for.
> - Being able to interrupt a running task
you do this with the queue commands, e.g. qdel jobid
> - Being able to inspect the incomplete output of a running task
This is just checking the output files in the running jobs directories.
> I’d love to hear about any frameworks or workflows that fulfill these
> I’m using ipython notebooks but I’m not happy with them because of the
> freezing problem and the complete lack of isolation of tasks within a
> single notebook (they live in a common mutable namespace). I think a
> useful framework must be “functional” at the highest level for caching
> and dependencies to be useful.
[-- Attachment #2: Type: text/html, Size: 3092 bytes --]
next prev parent reply other threads:[~2014-04-20 13:29 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-17 8:45 babel and long-running computations Christoph Groth
2014-04-17 9:47 ` Julian Gehring
2014-04-17 10:52 ` Christoph Groth
2014-04-17 12:06 ` Thorsten Jolitz
2014-04-17 12:45 ` Christoph Groth
2014-04-17 14:58 ` Waldemar Quevedo
2014-04-17 15:29 ` Eric Schulte
2014-04-17 16:29 ` Christoph Groth
2014-04-17 16:44 ` Nick Dokos
2014-04-17 15:33 ` Eric S Fraga
2014-04-20 13:29 ` John Kitchin [this message]
2014-04-18 13:20 ` John Kitchin
2014-04-19 21:49 ` Christoph Groth
2014-04-20 13:21 ` John Kitchin
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).