From 2649c3890003d69d0395e177d7ecc6639294c9af Mon Sep 17 00:00:00 2001 From: Matthew Evans Date: Mon, 18 Dec 2023 10:59:55 +0000 Subject: [PATCH] Add reference for jobflow-remote --- paper/paper.md | 2 +- paper/refs.bib | 6 ++++++ 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/paper/paper.md b/paper/paper.md index 844062d9..3596d6a0 100644 --- a/paper/paper.md +++ b/paper/paper.md @@ -183,7 +183,7 @@ One of the major benefits of Jobflow is that it decouples the details related to When deploying production calculations, workflows often need to be dispatched to large supercomputers through a remote execution engine. Jobflow has an interface with the FireWorks package [@fireworks] via a one-line command to convert a `Flow` and its underlying `Job` objects into the analogous FireWorks `Workflow` and `Firework` objects that enable execution on high-performance computing machines. The logic behind the `Job` and `Flow` objects are not tied to FireWorks in any direct way, such that the two packages are fully decoupled. -Additionally, a remote mode of execution built solely around Jobflow is currently under active development. With this approach, workflows can be executed across multiple "workers" (e.g., a simple computer, a supercomputer, or a cloud-based service) and managed through a modern command-line interface without relying on an external workflow execution engine. The forthcoming Jobflow remote mode of execution has been designed such that no inbound connection from the workers to the database of jobs and results is needed, thus ensuring data and network security for professional usage. +Additionally, a remote mode of execution built solely around Jobflow is currently under active development [@jobflowremote]. With this approach, workflows can be executed across multiple "workers" (e.g., a simple computer, a supercomputer, or a cloud-based service) and managed through a modern command-line interface without relying on an external workflow execution engine. The forthcoming Jobflow remote mode of execution has been designed such that no inbound connection from the workers to the database of jobs and results is needed, thus ensuring data and network security for professional usage. More generally, it is possible for users to develop custom "adapter" interfaces to their personal workflow execution engine of choice. As a result, Jobflow fills a niche in the broader workflow community and can help make the same workflow definition interoperable across multiple workflow execution engines. diff --git a/paper/refs.bib b/paper/refs.bib index fc7030d3..5b4f2977 100644 --- a/paper/refs.bib +++ b/paper/refs.bib @@ -159,3 +159,9 @@ @misc{montydb year = {2023}, url={https://github.com/davidlatwe/montydb} } + +@misc{jobflowremote, + title={Jobflow Remote}, + year={2023}, + url={https://github.com/Matgenix/jobflow-remote} +}