AiiDAlab: Web Platform for Scientific Workflows

• AiiDAlab is a web platform that integrates containerized environments, provenance tracking, and interactive Jupyter notebooks to simplify complex workflows.
• It enables diverse scientific applications from materials science to quantum chemistry by automating workflow execution and data management.
• The platform’s architecture combines AiiDA’s plugin-based execution with containerized user environments, easing access to HPC resources and enhancing collaboration.

Searching arXiv for recent and foundational AiiDAlab papers. AiiDAlab is a web platform, described also as a web-based “laboratory,” for developing, executing, and sharing scientific workflows through a browser, with the AiiDA workflow manager supplying provenance tracking and plugin-based workflow execution, and Jupyter technology supplying the user-interface layer (Yakutovich et al., 2020, Yakutovich et al., 18 Dec 2025). It was introduced to lower entry barriers created by software installation, input preparation, high-performance computing setup, and output analysis, and it packages workflows together with computational environments and graphical interfaces that can be distributed through an app store (Yakutovich et al., 2020). Within this ecosystem, the Quantum ESPRESSO app provides a concrete implementation for atomistic materials calculations, combining predefined computational protocols, automated error handling, and interactive results visualization on top of AiiDAlab (Wang et al., 25 Jul 2025).

1. Historical development and conceptual scope

The 2020 platform description defined AiiDAlab as an ecosystem that enables computational scientists to package scientific workflows and computational environments and share them with collaborators and peers (Yakutovich et al., 2020). In that formulation, the key enabling idea was not merely browser-based access, but the combination of containerized execution, app distribution, workflow automation, and automatic provenance tracking through AiiDA. The same account emphasized compatibility with open-science principles and the fact that incorporating new capabilities is intended to require only Python knowledge (Yakutovich et al., 2020).

A later platform overview by Yakutovich et al. reports that AiiDAlab “has matured over the past few years,” shifting its focus from computational materials science to a platform used across multiple disciplines, including quantum chemistry, atmospheric modeling, battery research, experimental data analysis at large-scale facilities, and education (Yakutovich et al., 18 Dec 2025). A recurrent misconception is therefore that AiiDAlab is solely a materials-science frontend. The documented application portfolio contradicts that narrow reading: the platform is presented as domain-expanding rather than domain-fixed (Yakutovich et al., 18 Dec 2025).

The Quantum ESPRESSO app exemplifies the original materials-science trajectory while also illustrating the broader platform logic. Its stated aim is to make density functional theory calculations accessible despite the operational complexity of input preparation, remote execution, and output interpretation, and it is explicitly framed as a general template to interface with other first-principles calculation codes (Wang et al., 25 Jul 2025). This suggests that the QE app is both a specialized application and a reference architecture for other code families.

2. System architecture and execution model

At the deployment level, AiiDAlab is organized around personal containerized user environments accessed from a web browser (Yakutovich et al., 2020). Users log in through JupyterHub, which delegates authentication to an external OAuth/OpenID Connect identity provider, and each authenticated user is assigned a personal AiiDAlab Docker container (Yakutovich et al., 2020). The 2020 architecture description states that such a container runs a Jupyter Server extended with Appmode to hide code and expose only widgets, the AiiDA daemon via RabbitMQ for task queuing, and a local PostgreSQL database holding the provenance graph and user data (Yakutovich et al., 2020).

The later architecture account preserves the same basic structure while describing the platform in terms of layers. Its AiiDAlab core image is a Docker image based on the jupyter/minimal-notebook, bundling the AiiDA engine, an AiiDA database server based on PostgreSQL, a repository folder, JupyterLab, ipywidgets, the aiidalab-widgets-base library, and pre-installed simulation codes and pseudopotentials such as Quantum ESPRESSO on the demo server (Yakutovich et al., 18 Dec 2025). Apps are independent Python packages that define notebooks with rich-widget GUIs and business logic for workflow builders, data parsing, and visualization, and they are discovered at runtime via an entry-point registry (Yakutovich et al., 18 Dec 2025).

App distribution is mediated by a central Git-based registry and an App Store interface (Yakutovich et al., 2020). Apps can be installed or updated on-the-fly, with installation implemented as a git clone into the user container followed by Jupyter relaunch (Yakutovich et al., 2020). For multi-user operation, Kubernetes is described as a common orchestration layer, while Ansible roles automate on-premise or single-node setups; the later overview additionally mentions Docker for single-user setups and Kubernetes or MicroK8s for multi-user servers (Yakutovich et al., 2020, Yakutovich et al., 18 Dec 2025).

On the public and institutional sides, the deployment model extends to cloud and laboratory infrastructure. The public demo server is described as running on Azure in Docker containers, while the PSI deployment uses MicroK8s with institutional AAI and a dynamic NFS mounting service (Yakutovich et al., 18 Dec 2025). In the latter case, experimental data such as raw CAMEA neutron files are streamed into shared NFS and appear live in the user container without manual download (Yakutovich et al., 18 Dec 2025).

3. Workflow abstraction, app composition, and plugin architecture

AiiDAlab inherits AiiDA’s plugin model and workflow abstractions (Yakutovich et al., 2020). In the 2020 description, every simulation code is wrapped by an AiiDA CalcJob or CalcFunction plugin, and multi-step protocols are implemented in Python by subclassing aiida.orm.Workflow (Yakutovich et al., 2020). A typical app consists of app metadata in setup.json, package installation and entry points in setup.py, notebooks forming the GUI, and AiiDA plugin code for calculations and workflows (Yakutovich et al., 2020). This architecture places GUI composition and workflow execution within a single packaging unit, but keeps them technically separable.

The Quantum ESPRESSO app makes that separability explicit through a classical Input–Process–Output model (Wang et al., 25 Jul 2025). In this pattern, each task or plugin implements structured inputs such as crystal structure, pseudopotential family, and numerical parameters; a process layer consisting of one or more AiiDA workflows or calculations that launch Quantum ESPRESSO or other codes on HPC, handle errors, and produce intermediate data; and an output layer consisting of parsed results and interactive visualizations (Wang et al., 25 Jul 2025). The stated consequence is that every step is reproducible, parameterized, and locally testable (Wang et al., 25 Jul 2025).

The QE app core provides a wizard UI that orchestrates the IPO steps and a registry of plugins, each conforming to the IPO interface (Wang et al., 25 Jul 2025). Plugins can reside in the main repository or in stand-alone Python packages, including aiidalab-qe-vibroscopy, aiidalab-qe-muon, aiidalab-qe-hp, aiidalab-qe-wannier90, aiida-qe-xspec, aiidalab-qe-pp, and aiida-bader (Wang et al., 25 Jul 2025). Integration is defined procedurally: a plugin declares an AiiDAlab entry point in setup.py under aiidalab.app.plugins, provides input panels for the wizard, AiiDA workflows for the process stage, and result panels for output, after which the core app auto-discovers the entry point and mounts the associated UI components into the global IPO wizard (Wang et al., 25 Jul 2025).

AiiDAlab’s generalization strategy extends beyond Quantum ESPRESSO. The QE overview describes the architecture as code-agnostic at the IPO level and states that supporting another quantum engine requires an AiiDA plugin implementing Calculation and Parser classes, a set of WorkChains conforming to a common DFT workflow interface, and AiiDAlab entry points for the UI panels (Wang et al., 25 Jul 2025). The same source points to the PREMISE project and an experimental CP2K app, aiidalab-empa-surfaces, as demonstrations of this reuse, while also noting that AiiDA’s “common workflows” package provides concrete classes implementing a protocol-like interface across multiple codes (Wang et al., 25 Jul 2025). This suggests that AiiDAlab’s app model is organized around stable workflow interfaces rather than around any single simulation engine.

4. Provenance, FAIRness, and data management

AiiDAlab’s reproducibility model is inherited directly from AiiDA’s directed-acyclic-graph provenance engine (Yakutovich et al., 2020, Yakutovich et al., 18 Dec 2025). The 2025 overview gives the formal representation

$$G = (V, E),\quad V = V_{\rm Data}\cup V_{\rm Process},\quad E\subseteq (V_{\rm Data}\times V_{\rm Process}) \,\cup\, (V_{\rm Process}\times V_{\rm Data}),$$

while the earlier account describes the graph in terms of data nodes, calculation nodes, and workflow nodes connected by input, output, and call edges (Yakutovich et al., 2020, Yakutovich et al., 18 Dec 2025). The relational schema is reported to include DbNode, DbLink, DbAttribute, and DbLog, and AiiDAlab apps query this graph through the AiiDA Python ORM (Yakutovich et al., 18 Dec 2025).

The provenance scope is extensive. All inputs, including structures, parameters, code versions, and scheduler options, and all outputs, including energies, trajectories, and logs, are stored unedited, while workflow sub-steps appear as subgraphs that can be inspected from the UI (Yakutovich et al., 18 Dec 2025). The Quantum ESPRESSO app extends this logic to the entire simulation lifecycle by recording inputs, processes, parameter adjustments, and outputs in the provenance graph, and even storing widget state such as plot ranges and color maps in nodes so that figures can be reproduced with “one-click” (Wang et al., 25 Jul 2025).

The platform’s FAIR framing is explicit. For the QE app, “Findable” includes storage of every calculation in the AiiDA provenance graph, export of full AiiDA archives that can be assigned DOIs via Materials Cloud, and registration of workflows and plugins with unique entry-point names; “Accessible” includes cloud SaaS at demo.aiidalab.io, local Docker installation via aiidalab-launch, OAuth2 authentication, and JupyterHub multi-user support; “Interoperable” includes common AiiDA workflow interfaces, OPTIMADE-compliant structure import, and decoupled plugin UI widgets reusable in standalone Jupyter notebooks or other platforms; and “Reusable/Reproducible” includes full recording of workflow execution and open-source code under permissive licenses (Wang et al., 25 Jul 2025). The broader 2025 overview adds shared ontologies, RDF/JSON-LD, and the AiiDA Resource Registry to the interoperability layer, particularly in the context of ELN/LIMS integration and Open Research Data generation (Yakutovich et al., 18 Dec 2025).

Data-management capabilities extend beyond provenance bookkeeping. Documented export formats include JSON/YAML, NetCDF, and HDF5, and large datasets can be handled through on-the-fly aggregation, as in AiiDAlab-FLEXPART, which concatenates hourly footprints into monthly netcdf files (Yakutovich et al., 18 Dec 2025). Additional features include cubehandler for pre-computing multi-resolution cube files for live 3D grid visualization, firecrest and aiidalab-mfa-cscs for staging large trajectories between scratch and permanent storage on HPC, and the YADG parser for ingesting battery cycling time-series into a FAIR-compliant datagram (Yakutovich et al., 18 Dec 2025).

5. The Quantum ESPRESSO app as a canonical AiiDAlab implementation

The Quantum ESPRESSO app is presented as an intuitive, web-based platform built on AiiDAlab for automated DFT workflows (Wang et al., 25 Jul 2025). Its GUI is built on Jupyter notebooks together with the Appmode plugin and implements the IPO model as a four-step wizard: structure selection and editing, including upload of CIF or XYZ files, fetching via OPTIMADE, examples, or local sources; workflow configuration, including geometry optimization and property selection through basic and advanced panels; computational resource selection, including AiiDA Code, transport, walltime, and machines; and monitoring and results, including real-time status, interactive plots, and download of the AiiDA archive (Wang et al., 25 Jul 2025).

A central usability mechanism is the predefined protocol selector (Wang et al., 25 Jul 2025). It abstracts hundreds of Quantum ESPRESSO parameters into three levels, exemplified as “fast,” “balanced,” and “accurate,” and under the hood sets recommended values for k-point density, energy cutoff, and convergence thresholds (Wang et al., 25 Jul 2025). Pseudopotential families such as SSSP and PseudoDojo are exposed through drop-down menus, while an advanced panel exposes raw JSON/YAML for power users (Wang et al., 25 Jul 2025). In the later platform overview, the QE app is further described as having inline helpers, parameter presets, and dynamic validation (Yakutovich et al., 18 Dec 2025).

Workflow execution relies on the aiida-quantumespresso plugin for automated management (Wang et al., 25 Jul 2025). The documented recovery logic includes automatic restarts on walltime interrupts while preserving the latest density and structure, electronic convergence recovery by reducing mixing or switching algorithm when SCF fails, and caching so that identical inputs reuse previous results (Wang et al., 25 Jul 2025). The pseudocode given in the QE overview captures the operational intent: completed jobs return their outputs, jobs that do not converge are retried with smaller mixing, and jobs killed by walltime are resumed from the last checkpoint (Wang et al., 25 Jul 2025).

The app’s demonstrated plugin space is broad (Wang et al., 25 Jul 2025). It includes electronic structure in the form of band structure and projected density of states; vibrational spectroscopies, including phonons, IR, Raman, and INS; X-ray absorption through XANES and XSpectra; X-ray photoelectron spectroscopy through XPS and $\Delta KS$; muon spectroscopy for $\mu$SR sites and local fields; Hubbard parameters through DFT+$U$+$V$ via hp.x; Wannier functions and Fermi surfaces through Wannier90 workflows; post-processing of charge density, spin density, wavefunctions, Critic2, and STM; and Bader charge analysis (Wang et al., 25 Jul 2025).

The electronic-structure plugin is given as a concrete workflow example (Wang et al., 25 Jul 2025). A BandStructureWorkChain runs an SCF calculation, computes a non-SCF step along a high-symmetry $\mathbf{k}$-path using seekpath under the hood, parses the band energies, and constructs a BandData node (Wang et al., 25 Jul 2025). The Hubbard plugin interfaces with aiida-hubbard DFPT workflows, with on-site and inter-site parameters defined as

$$U_{I}=\frac{\partial^2 E}{\partial n_{I}^2}, \qquad V_{I,J}=\frac{\partial^2 E}{\partial n_{I}\,\partial n_{J}},$$

where $n_I$ is the occupation of site $I$ (Wang et al., 25 Jul 2025). The documented YAML-style input includes a self_consistent mode, explicit site pairs such as (Co, O) and (Co, Co), and a threshold of 1e-4 (Wang et al., 25 Jul 2025).

6. Scientific domains, operational adoption, and current limitations

AiiDAlab’s documented application space now extends well beyond electronic-structure workflows (Yakutovich et al., 18 Dec 2025). In quantum chemistry, AiiDAlab-AtmoSpec uses a SmilesWidget to generate conformers from SMILES codes, then runs DFT optimizations and nuclear ensemble UV/Vis cross-section calculations via aiida-orca, with a SpectrumWidget displaying a Boltzmann-weighted sum of individual conformer spectra (Yakutovich et al., 18 Dec 2025). In atmospheric modeling, AiiDAlab-FLEXPART launches FLEXPART footprint simulations for $O(10^5)$ hourly observations, concatenates footprints into a standard NetCDF footprint format, and triggers ELRIS for country-scale flux inference used in UNFCCC reporting (Yakutovich et al., 18 Dec 2025). In battery research, AiiDAlab-Aurora integrates the Chemspeed/Aurora robotic cell assembler through the tomato package and periodically parses results into FAIR-compliant YADG datagrams stored in the AiiDA database (Yakutovich et al., 18 Dec 2025). At large-scale facilities, the LNS-app for CAMEA encloses the MJOLNIR analysis suite and lets users browse proposal IDs and launch pre-configured notebooks on live data streams (Yakutovich et al., 18 Dec 2025).

Educational deployment is also explicitly documented (Yakutovich et al., 18 Dec 2025). At the PSI “Electronic-structure simulations for user communities” school in April 2025, the format was hybrid, with 35% in-person participation, 65% remote participation, and 60% novices; a dedicated AiiDAlab QE-app Kubernetes cluster on Azure was used, and participants ran DFT band structures together with neutron, Muon, XPS, and XAS simulations “with a few clicks” (Yakutovich et al., 18 Dec 2025). The reported overall feedback score was 8.5/10 (Yakutovich et al., 18 Dec 2025).

Earlier production-grade use cases were developed at the nanotech@surfaces lab at Empa (Yakutovich et al., 2020). The Nanoribbon App implemented a workflow of DFT cell or geometry optimization, band-structure calculation, density of states, and export, with a typical throughput of approximately 5–10 ribbons per hour on 16-core HPC nodes, and more than 4,000 calculations for 10 ribbon types recorded in a single provenance database (Yakutovich et al., 2020). The On-Surface Chemistry App used CP2K-based geometry optimizations, NEB, and a chain-of-constraints routine, with benchmarked 32-image NEB runs across 128 cores in approximately 6 hours (Yakutovich et al., 2020). The Scanning Probe Microscopy App combined Tersoff–Hamann STM simulation with PDOS and hybridization analysis via Quantum ESPRESSO and CP2K; a single 10×10 slab with a 20 k-point grid and an STM stack of 10 biases required approximately 2 hours on 32 cores (Yakutovich et al., 2020). On CSCS Piz Daint nodes, the corresponding empirical performance table reported average run times of 1 h 15 m, 3 h 40 m, and 2 h 10 m; success rates of 98%, 95%, and 97%; and provenance node counts per calculation of 12, 30, and 18 for the Nanoribbon, On-Surface Chemistry, and Scanning Probe Microscopy apps, respectively (Yakutovich et al., 2020).

The documented limitations are primarily architectural rather than scientific (Yakutovich et al., 2020). UI flexibility is “currently limited to Jupyter+ipywidgets,” with future React or Angular front ends via REST API described as planned (Yakutovich et al., 2020). Inter-app communication standards beyond the AiiDA database are under discussion, and while AiiDA 1.0 is reported to handle approximately 10,000 tasks per hour, multi-tenant deployment at the scale of hundreds of simultaneous users is said to require advanced autoscaling policies and resource quotas (Yakutovich et al., 2020). Proposed future directions include provenance-analytics dashboards based on Neo4j or ARANGO DB and an embedded peer-review and rating system in the App Store (Yakutovich et al., 2020). These limitations clarify that AiiDAlab’s central problem is not the absence of workflow abstractions, but the continued engineering challenge of scaling those abstractions across interfaces, users, and data-intensive workloads.