[Feature] Integration with CatGo — visual editing & monitoring of quacc workflows

[Hello-QM]

What new feature would you like to see?

Our group recently developed CatGo, an AI-agent-driven platform for computational chemistry with a focus on computational catalysis. It combines an interactive 3D structure builder/viewer, a visual DAG
workflow editor, HPC job submission/monitoring, and a natural-language assistant in a single tool.

• Source: https://github.com/Hello-QM/catgo-LRG
• Web app (no install): https://app.catgo-ucsd.org
• Docs: https://docs.catgo-ucsd.org
• Preprint: https://doi.org/10.26434/chemrxiv.15002984/v1

A recurring pain point for catalysis researchers is the gap between authoring a workflow in code and interactively building/inspecting the structures and monitoring the jobs it runs on. quacc's recipe/flow
design is an excellent fit for the execution side, and we'd like to explore making it a first-class backend engine for CatGo so the two halves connect.

Describe the solution you'd like

Integrate quacc with CatGo so that:

1. quacc as a backend execution engine — CatGo workflows (or quacc flows) execute through quacc recipes, with CatGo handling structure editing, HPC submission, and live job monitoring in its UI.
2. Bidirectional workflow exchange — a quacc @flow can be visualized and edited as a DAG in the CatGo frontend, and a graph edited in CatGo can be exported back to a runnable quacc flow.
3. Catalysis-oriented UX — researchers edit slabs/adsorbates and surface models visually in CatGo, dispatch the run via quacc, and watch progress in the CatGo job UI — without hand-writing or re-deriving the
   flow.

Describe alternatives you've considered / what already exists on our side

We've already built a one-directional prototype to validate feasibility:

• An import endpoint that statically parses a quacc @flow-decorated function (AST) — or a declarative job list — and converts it into an editable CatGo workflow DAG.
• A recipe-path mapping layer (quacc.recipes... → CatGo node types with sensible default parameters), currently covering VASP core recipes and others.
• A set of importable quacc workflow templates.

This proves the visualization/editing direction works. The natural next steps — and where guidance from the quacc side would help — are (a) running through quacc as the execution backend rather than
re-mapping to our own engines, and (b) a stable, round-trippable serialization so edits in CatGo regenerate a valid quacc flow.

Questions for the maintainers

1. Is there interest in (or prior art for) a GUI front-end driving quacc, and would you be open to collaborating / accepting upstream hooks that make this cleaner?
2. What is the recommended stable interface to (de)serialize a flow and its job DAG (e.g. for round-tripping through an external editor)?
3. For live monitoring, what's the best supported way to stream per-job status from a running flow (recommended workflow engine, results store, or API) so an external UI can subscribe?
4. Any pitfalls you'd flag for treating quacc recipes as nodes that a non-quacc scheduler/UI submits and tracks?

We'd be glad to share the prototype, demo it, and contribute upstream where it makes sense. Thanks for quacc — its recipe design made the prototype straightforward to build.

[Andrew-S-Rosen]

Thanks for reaching out, @Hello-QM!

Is there interest in (or prior art for) a GUI front-end driving quacc, and would you be open to collaborating / accepting upstream hooks that make this cleaner?

I think this would be of interest. There is no prior art and no plans to build a GUI front-end. Since I am currently the sole maintainer of the repository, I can't commit to collaborating but would be open to reviewing and merging relevant PRs provided that they are: a) thoroughly tested and follow the contribution guidelines; b) do not drastically alter the functionality of quacc; c) the GUI components live in your external repo.

What is the recommended stable interface to (de)serialize a flow and its job DAG (e.g. for round-tripping through an external editor)?

The DAG logic is all handled by the user's chosen workflow orchestration tool. By default, this is none and there is, therefore, no DAG tracking. Users can select from one of several workflow orchestration backends as described in the documentation, and how one can obtain that information is entirely dependent on the underlying workflow tool. Quacc itself does not have any logic for tracking the workflow DAG and outsources it entirely to whatever engine is chosen.

For live monitoring, what's the best supported way to stream per-job status from a running flow (recommended workflow engine, results store, or API) so an external UI can subscribe?

This also depends on the workflow engine. We use jobflow w/ jobflow-remote here, but that requires the user to have access to a MongoDB instance, which is rare. The Prefect engine is very nice and already comes with a nice UI/API for tracking jobs, but its interface with Slurm clusters is not great.

Any pitfalls you'd flag for treating quacc recipes as nodes that a non-quacc scheduler/UI submits and tracks?

Since all the workflow logic is based on the underlying engine, that's going to be the most important thing to specify.

As for alternatives, you may also wish to consider atomate2, which is similar and based around jobflow. These are the two major workflow libraries.

[Hello-QM]

Thanks @Andrew-S-Rosen — the key takeaway is that quacc is recipe-level and delegates the DAG/monitoring to the orchestration backend.

That actually simplifies things on our end: CatGo already has its own execution engines and job monitoring, so we'll keep the integration one-directional — import a quacc @flow into an editable CatGo DAG and run it on our engines — rather than depending on Prefect/jobflow for execution.

Fully aligned with your terms: GUI stays in our repo, and any upstream proposal would be a small, tested, non-disruptive hook. Thanks for the atomate2 pointer too — we have a parallel prototype there.