Wannier90 has traditionally been used as a standalone post-processing program in electronic-structure workflows. In the conventional approach, a first-principles code generates the quantities required for Wannierization—Bloch-state eigenvalues, overlaps between neighboring Bloch states, and projections onto localized trial orbitals—and writes them to intermediate files such as .eig, .mmn, and .amn. Wannier90 then reads these files, performs disentanglement and localization, and produces the Wannier representation required for interpolation and downstream property calculations.
This file-based architecture has been extremely successful because it provides a clean separation between the electronic-structure code and Wannier90. It remains fully supported and is still widely used. However, modern computational workflows increasingly require tighter software integration, reduced disk I/O, automated error recovery, and direct programmatic control over the Wannierization procedure.
Wannier90 version 4 introduces a major architectural development in this direction: Wannier90 can now be used not only as a standalone executable, but also as a reusable parallel software library embedded directly into larger electronic-structure and workflow codes.
Traditional File-Based Wannier90 Workflow
In the conventional workflow, the electronic-structure code and Wannier90 communicate through files.
Electronic-structure calculation
|
| Bloch eigenvalues
| overlap matrices
| projections
v
.eig / .mmn / .amn
|
v
wannier90.x
|
| Wannierization
| interpolation data
v
Wannier Hamiltonian
and other matrix elements
|
v
Downstream property codes
This workflow has several important advantages:
- it is simple and transparent;
- it is largely independent of the parent electronic-structure code;
- the intermediate files can be inspected and archived;
- the same Wannier90 workflow can be reused with many different first-principles packages;
- downstream codes can consume standard Wannier90 output without needing direct access to the electronic-structure program.
However, for large systems the intermediate overlap and projection files can become large, and repeated read/write operations may introduce substantial I/O overhead. More importantly, a file-based workflow is less convenient when Wannierization must be executed repeatedly inside an automated calculation.
Wannier90 as a Reusable Library
Wannier90 v4 extends the traditional model by allowing the main stages of Wannierization to be called directly from another program.
The resulting architecture can be represented schematically as:
Electronic-structure code
or workflow manager
|
v
Wannier90 library
|
+--> subspace selection
|
+--> disentanglement
|
+--> localization
|
+--> Wannier interpolation data
|
v
Wannier representation
|
+--> band interpolation
+--> topology
+--> transport
+--> optics
+--> electron-phonon physics
+--> many-body models
Instead of writing all Bloch-space quantities to disk and launching wannier90.x as a separate process, the host application can pass the relevant arrays directly to the Wannier90 library in memory.
Conceptually, the transition is:
File-based coupling: Program A | v intermediate files | v wannier90.x Library-based coupling: Program A | v Wannier90 library calls | v Wannier representation
This makes Wannier90 much more suitable as an internal computational component of a larger code.
In-Memory Data Exchange
One of the most important advantages of the library architecture is the possibility of exchanging large arrays directly in memory.
The central quantities required for Wannierization include:
- Bloch eigenvalues $E_{n\mathbf{k}}$;
- neighbor-overlap matrices $M_{mn}^{(\mathbf{k},\mathbf{b})}$;
- projection matrices $A_{mn}^{(\mathbf{k})}$;
- k-point coordinates and lattice information;
- information about the target Wannier subspace.
The overlap matrices are conventionally defined as
$$ M_{mn}^{(\mathbf{k},\mathbf{b})} = \left\langle u_{m\mathbf{k}} \middle| u_{n,\mathbf{k}+\mathbf{b}} \right\rangle , $$
while the projection matrices are typically of the form
$$ A_{mn}^{(\mathbf{k})} = \left\langle \psi_{m\mathbf{k}} \middle| g_n \right\rangle , $$
where $|g_n\rangle$ are localized trial orbitals.
In the traditional workflow, these quantities are serialized into files before Wannier90 can access them. In a library workflow, they can be passed directly from the parent application.
This can significantly reduce unnecessary disk traffic in large calculations and simplifies the repeated invocation of Wannierization during an automated optimization or validation loop.
Parallel Library Interface
The Wannier90 v4 library architecture is designed for parallel execution.
Modern first-principles calculations frequently distribute Bloch states and k-points over many MPI processes. A useful Wannier library must therefore integrate naturally with an MPI-parallel host program rather than forcing all relevant data onto a single process.
The parallel interface enables Wannier90 to participate directly in such distributed workflows.
A simplified parallel architecture can be represented as:
MPI electronic-structure calculation
|
v
distributed Bloch-state data
|
v
parallel Wannier90 library
|
v
distributed / collective
Wannierization operations
|
v
Wannier representation
This is especially important for large supercells, dense k-point meshes, and automated high-throughput calculations where the serial transfer and storage of all overlap matrices can become inefficient.
Programmatic Control of Wannierization
When Wannier90 is used as a library, the calling program can control the Wannierization procedure directly.
A workflow engine can therefore implement logic such as:
Run electronic-structure calculation
|
v
Generate projections and overlaps
|
v
Call Wannier90
|
v
Inspect localization quality
|
+--> acceptable
| |
| v
| continue calculation
|
+--> unacceptable
|
v
modify parameters
|
v
rerun Wannierization
This makes possible a level of automation that is much harder to achieve with a purely manual file-based workflow.
Error Handling and Workflow Recovery
Library integration is particularly important for robust automated calculations because the parent program can retain control when the Wannierization step is unsuccessful.
In a traditional shell-based workflow, failure of wannier90.x may simply terminate that stage of the calculation. A workflow manager must then parse log files, determine what failed, modify the inputs, and relaunch the executable.
With a library interface, errors can instead be propagated programmatically to the calling application.
This allows workflows of the form:
Call Wannier90
|
v
check return status
|
+--> success
| |
| v
| continue
|
+--> failure
|
+--> modify projections
+--> modify energy windows
+--> modify localization parameters
+--> retry
This capability is highly relevant for autonomous electronic-structure workflows, where the goal is not merely to detect failure but to attempt physically sensible corrections automatically.
Interfaces for Different Programming Environments
The modern Wannier90 library can be incorporated into different programming environments.
The most important interfaces include:
- Fortran — particularly natural for integration with electronic-structure codes that are themselves written primarily in Fortran;
- C/C++ — useful for high-performance applications and interoperability with broader scientific-software ecosystems;
- Python — useful for workflow management, prototyping, automation, testing, and coupling Wannier90 to data-analysis or machine-learning tools.
This is an important architectural development because many modern computational-materials frameworks are no longer monolithic codes. Instead, they combine low-level high-performance kernels with higher-level workflow and analysis layers.
A typical architecture can therefore be:
Python workflow layer
|
+--> input generation
+--> database interaction
+--> validation
+--> optimization logic
|
v
C / C++ / Fortran scientific kernels
|
+--> DFT
+--> Wannier90
+--> transport / optics / many-body modules
Reduced I/O and Large-Scale Calculations
Wannier calculations may generate substantial intermediate data, particularly the overlap matrices connecting neighboring k-points.
For $N_b$ Bloch bands, $N_k$ k-points, and $N_{\mathrm{nb}}$ neighboring k-point vectors, the amount of overlap data scales approximately as
$$ N_k N_{\mathrm{nb}} N_b^2. $$
For large $N_b$, this can become significant.
In conventional workflows the data must often be:
- computed by the electronic-structure code;
- written to disk;
- read by Wannier90;
- possibly written again in processed form.
Direct in-memory coupling can remove some of these steps.
This becomes increasingly attractive for:
- large supercells;
- dense Brillouin-zone sampling;
- high-throughput screening;
- large spinor calculations;
- automated parameter optimization requiring many Wannierization attempts.
Wannier90 as an Intermediate Representation
The library architecture also changes the conceptual role of Wannier90.
Wannier90 should no longer be viewed only as a program that produces maximally localized Wannier functions. It can also be regarded as a software layer that transforms delocalized Bloch-space electronic structure into a compact localized representation suitable for many different physical calculations.
The basic transformation is
$$ \left\{ |\psi_{n\mathbf{k}}\rangle, E_{n\mathbf{k}} \right\} \longrightarrow \left\{ |w_{n\mathbf{R}}\rangle, H_{mn}(\mathbf{R}) \right\}. $$
The real-space Hamiltonian matrix elements are
$$ H_{mn}(\mathbf{R}) = \left\langle w_{m\mathbf{0}} \middle| \hat H \middle| w_{n\mathbf{R}} \right\rangle . $$
Once these localized matrix elements are available, they can be interpolated efficiently throughout the Brillouin zone.
In reciprocal space, the Wannier-interpolated Hamiltonian is reconstructed as
$$ H_{mn}(\mathbf{k}) = \sum_{\mathbf{R}} e^{i\mathbf{k}\cdot\mathbf{R}} H_{mn}(\mathbf{R}). $$
The same principle applies to many other operators.
This turns the Wannier representation into a general intermediate representation between expensive first-principles calculations and computationally efficient property calculations.
Wannier90 as a Common Infrastructure Layer
A modern Wannier-based software stack can therefore be represented as:
First-principles electronic structure
|
| QE / VASP / ABINIT / SIESTA /
| exciting / other codes
v
Wannier90
|
| localized electronic representation
v
+----------------+----------------+----------------+
| | | |
Topology Transport Optics Electron-phonon
| | | |
WannierTools Boltzmann BSE / EPW
WannierBerri methods nonlinear Perturbo
Z2Pack quantum optics
transport
|
+-------------------------------+
|
v
Effective Hamiltonians
and many-body models
In this architecture, Wannier90 acts as a common interface between many different electronic-structure codes and many different downstream physical-property packages.
This is one reason why the Wannier90 ecosystem has grown rapidly: once a code can consume a standard Wannier representation, it does not need to implement a separate direct interface to every first-principles package.
Implications for Automated and High-Throughput Workflows
The library interface becomes especially powerful when combined with automatic validation.
A robust workflow can measure:
- the total and individual Wannier spreads;
- the agreement between first-principles and Wannier-interpolated bands;
- the orbital character of the Wannier functions;
- the smoothness of the interpolated bands;
- symmetry properties;
- projectability of the selected Bloch states;
- the stability of derived physical observables.
For example, a band-interpolation error can be defined schematically as
$$ \Delta_{\mathrm{band}} = \sqrt{ \frac{1}{N} \sum_{n,\mathbf{k}} \left[ E^{\mathrm{DFT}}_{n\mathbf{k}} - E^{\mathrm{W}}_{n\mathbf{k}} \right]^2 }. $$
A workflow can compare this quantity with a predefined tolerance and automatically reject an inaccurate Wannierization.
This leads naturally to adaptive workflows:
Initial projections
|
v
Wannierization
|
v
validation
|
+--> good representation
| |
| v
| continue
|
+--> poor representation
|
+--> change projections
+--> change disentanglement windows
+--> change number of bands
+--> change localization settings
|
v
repeat automatically
Such a procedure can be combined with optimization algorithms or machine-learning methods to reduce the amount of manual intervention required in Wannier-based calculations.
Integration with Quantum ESPRESSO Workflows
Quantum ESPRESSO has historically been one of the most important first-principles codes interfaced with Wannier90.
The conventional workflow is typically:
pw.x | v SCF / NSCF wavefunctions | v pw2wannier90.x | v .amn / .mmn / .eig | v wannier90.x
This architecture remains useful and widely employed.
However, the library approach makes a more tightly integrated architecture possible in future workflow systems:
Quantum ESPRESSO calculation
|
v
Bloch-space information
|
v
Wannier90 library
|
v
Wannier representation
|
+--> EPW
+--> WannierBerri
+--> WannierTools
+--> BSE / optical workflows
+--> model-Hamiltonian construction
For workflow frameworks centered on Quantum ESPRESSO, this opens the possibility of treating Wannierization as an internal computational stage rather than as an externally launched post-processing task.
Integration with Property Codes
The Wannier representation provides compact access to quantities needed by many specialized codes.
Typical downstream applications include:
- band interpolation on very dense k-point meshes;
- Berry curvature and related geometric quantities;
- anomalous Hall and spin Hall conductivity;
- topological invariants and surface-state calculations;
- Boltzmann transport;
- electron-phonon interpolation;
- optical matrix elements;
- excitonic Hamiltonians;
- effective tight-binding and many-body models.
The broader architecture can be summarized as
$$ \text{first-principles calculation} \rightarrow \text{Wannier representation} \rightarrow \text{specialized physics}. $$
The importance of Wannier90 therefore lies not only in localization, but also in its role as a standardized bridge between different levels of electronic-structure theory.
Backward Compatibility and Coexistence of Both Workflows
The library architecture does not make the conventional executable obsolete.
The two approaches serve different purposes.
| Approach | Advantages | Typical use |
|---|---|---|
Standalone wannier90.x | Simple, transparent, portable, easy to debug manually | Teaching, individual calculations, conventional workflows |
| Wannier90 library | Direct integration, reduced I/O, programmatic control, automation | Large workflows, high-throughput calculations, integrated software frameworks |
In practice, both approaches are likely to coexist for a long time.
The file-based interface remains particularly valuable because it provides a stable exchange format between independent codes. The library interface becomes most advantageous when tight coupling, repeated execution, or automated decision making is required.
Role in Future Computational Materials Platforms
The development of Wannier90 as a library reflects a broader trend in computational materials science.
Modern simulation environments increasingly combine several layers:
Workflow / AI layer
|
v
Electronic-structure engines
|
v
Intermediate physical representations
|
v
Specialized property solvers
|
v
Databases / validation / analysis
The Wannier representation is particularly well suited to serve as one of these intermediate physical representations because it combines:
- first-principles accuracy;
- compact real-space localization;
- efficient interpolation;
- direct physical interpretability;
- compatibility with many downstream methods.
This makes Wannier90 increasingly relevant not only as a scientific code, but as a reusable component of computational-materials software infrastructure.
Summary
Wannier90 v4 marks an important evolution of the package.
The traditional workflow
$$ \text{electronic-structure code} \rightarrow \text{files} \rightarrow \texttt{wannier90.x} $$
is now complemented by a tightly integrated model
$$ \text{electronic-structure code} \rightarrow \text{Wannier90 library} \rightarrow \text{Wannier representation}. $$
The library architecture provides several important advantages:
- direct in-memory exchange of electronic-structure data;
- parallel integration with MPI-based applications;
- reduced intermediate I/O;
- programmatic control of Wannierization;
- improved error handling;
- support for automated parameter optimization and recovery;
- closer integration with transport, optical, topological, electron-phonon, and many-body workflows.
As a result, Wannier90 is evolving from a standalone post-processing application into a general-purpose software infrastructure for localized electronic representations.
This architectural development is particularly important for future automated, high-throughput, and AI-assisted electronic-structure workflows, where Wannierization must operate as an adaptive component inside a larger computational pipeline rather than as an isolated manual step.
Next: Afterword