---
title: 'AiiDAlab: Web Platform for Scientific Workflows'
url: https://www.emergentmind.com/topics/aiidalab
type: topic
---

# AiiDAlab: Web Platform for Scientific Workflows

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 [2010.02731, 2512.22173]. 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 [2010.02731]. 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 [2507.19670].

## 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 [2010.02731]. 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 [2010.02731].

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 [2512.22173]. 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 [2512.22173].

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 [2507.19670]. 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 [2010.02731]. 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 [2010.02731]. 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 [2010.02731].

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 [2512.22173]. 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 [2512.22173].

App distribution is mediated by a central Git-based registry and an App Store interface [2010.02731]. Apps can be installed or updated on-the-fly, with installation implemented as a `git clone` into the user container followed by Jupyter relaunch [2010.02731]. 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 [2010.02731, 2512.22173].

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 [2512.22173]. 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 [2512.22173].

## 3. Workflow abstraction, app composition, and plugin architecture

AiiDAlab inherits AiiDA’s plugin model and workflow abstractions [2010.02731]. 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` [2010.02731]. 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 [2010.02731]. 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 [2507.19670]. 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 [2507.19670]. The stated consequence is that every step is reproducible, parameterized, and locally testable [2507.19670].

The QE app core provides a wizard UI that orchestrates the IPO steps and a registry of plugins, each conforming to the IPO interface [2507.19670]. 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` [2507.19670]. 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 [2507.19670].

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 `WorkChain`s conforming to a common DFT workflow interface, and AiiDAlab entry points for the UI panels [2507.19670]. 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 [2507.19670]. 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 [2010.02731, 2512.22173]. 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 [2010.02731, 2512.22173]. The relational schema is reported to include `DbNode`, `DbLink`, `DbAttribute`, and `DbLog`, and AiiDAlab apps query this graph through the AiiDA Python ORM [2512.22173].

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 [2512.22173]. 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” [2507.19670].

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 [2507.19670]. 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 [2512.22173].

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 [2512.22173]. 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 [2512.22173].

## 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 [2507.19670]. 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 [2507.19670].

A central usability mechanism is the predefined protocol selector [2507.19670]. 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 [2507.19670]. Pseudopotential families such as SSSP and PseudoDojo are exposed through drop-down menus, while an advanced panel exposes raw JSON/YAML for power users [2507.19670]. In the later platform overview, the QE app is further described as having inline helpers, parameter presets, and dynamic validation [2512.22173].

Workflow execution relies on the `aiida-quantumespresso` plugin for automated management [2507.19670]. 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 [2507.19670]. 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 [2507.19670].

The app’s demonstrated plugin space is broad [2507.19670]. 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 [2507.19670].

The electronic-structure plugin is given as a concrete workflow example [2507.19670]. 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 [2507.19670]. 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$ [2507.19670]. 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` [2507.19670].

## 6. Scientific domains, operational adoption, and current limitations

AiiDAlab’s documented application space now extends well beyond electronic-structure workflows [2512.22173]. 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 [2512.22173]. 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 [2512.22173]. 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 [2512.22173]. 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 [2512.22173].

Educational deployment is also explicitly documented [2512.22173]. 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” [2512.22173]. The reported overall feedback score was 8.5/10 [2512.22173].

Earlier production-grade use cases were developed at the nanotech@surfaces lab at Empa [2010.02731]. 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 [2010.02731]. 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 [2010.02731]. 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 [2010.02731]. 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 [2010.02731].

The documented limitations are primarily architectural rather than scientific [2010.02731]. UI flexibility is “currently limited to Jupyter+ipywidgets,” with future React or Angular front ends via REST API described as planned [2010.02731]. 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 [2010.02731]. 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 [2010.02731]. 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.

Source: https://www.emergentmind.com/topics/aiidalab