VeraGrid: power systems planning with a desktop GUI in Python

A grid modelling environment that started as a library

VeraGrid describes itself as a top tier power systems planning and simulation software, and the origin story in the README explains the shape it took. It started in 2015 with a clear objective: create a solid programming library and a user-friendly interface. The README says this straightforward approach sparked many innovations, some driven by the necessity of commercial use and others fuelled by curiosity and research, and the audience it names is broad: a professional who needs free tools, a researcher who wants a real-world tested platform, a teacher sharing commercial-grade software insights, and a student diving into practical algorithms. It is a Python project, so it needs a Python interpreter, and it is cross-platform with a graphical interface rather than being a library alone. The licence is MPL-2.0, the file type for the software is a .veragrid or .gridcal file, and the project is hosted with a Zenodo DOI badge, a readthedocs documentation site, and a Matrix chat room, which places it somewhere between a research code drop and a supported product.

Three packages, and you install only the one you need

The project is split into three packages, and the split tells you how it is meant to be consumed. VeraGridEngine is the package with the database and the calculation logic. VeraGridServer serves a REST API so that VeraGridEngine can be used remotely. VeraGrid is the package that contains the graphical user interface and works with the engine and the server without extra setup. To get everything you install the VeraGrid package and the other two arrive as dependencies, which is the simplest route for a desktop user. The reverse is also supported. Some users only need the engine as a library for batch calculations, AI training or simple scripting, and for them the engine is installed on its own, which is the package to choose if the interface is dead weight. That three-way split has an architectural consequence: the calculations are reachable without the GUI, so a study can be scripted end to end, and a cluster of workers can talk to one engine through the REST server rather than embedding it in each process.

The one-line installer builds a venv and claims file extensions

For people who do not want to manage Python, the project ships terminal installers for the three desktop platforms. On Linux and macOS it is a single piped command:

curl -sSL https://raw.githubusercontent.com/SanPen/VeraGrid/master/src/install_on_linux.sh | bash

The Windows equivalent runs from Command Prompt or PowerShell and downloads the script before executing it:

curl -sSL https://raw.githubusercontent.com/SanPen/VeraGrid/master/src/install_on_windows.cmd -o install_veragrid.cmd && install_veragrid.cmd && del install_veragrid.cmd

The README lists what the installer does automatically, and the list deserves reading before running it. It creates a dedicated Python virtual environment in the user directory, installs the latest VeraGrid package and all dependencies through pip, sets up desktop and application menu shortcuts using the VeraGrid icon, and associates the .veragrid and .gridcal file formats so that double-clicking a file opens it in the application. That last point is the one to be aware of: the installer registers file associations with the operating system. For a shared workstation, that is a change to the machine, not just to a project, and it pays to check who else uses the machine. There is also a standalone Windows installer for people who do not want Python involved at all, which installs VeraGrid as a normal Windows program.

The pip path, a virtual environment, and two ways to start the GUI

The conventional route is pip, and the README recommends installing the latest Python first:

pip install VeraGrid

On Linux and macOS you may need pip3, since both come with Python pre-installed. To keep the installation isolated, the same section shows a virtual environment workflow:

python3 -m venv gc5venv
source gc5venv/bin/activate
pip install VeraGrid
veragrid

Once the package is in the local Python distribution, the interface starts with the veragrid command, and the README gives a fallback for when that entry point is not on the path:

python -c "from VeraGrid.ExecuteVeraGrid import runVeraGrid; runVeraGrid()"

That fallback is also the answer to the shortcut question the README raises, since it can be saved into a shortcut for easy access later. The engine alone is installed the same way with pip install VeraGridEngine, which brings in the package that the GUI package already depends on. Nothing in the documentation requires a database server or a container to run a study, which is one of the practical differences from the commercial grid tools this project positions itself against.

The study catalogue is the reason to look at VeraGrid

The feature list is long, and it is organised by analysis type, which is the clearest statement of what the software does. On the grid modelling side there is a large collection of devices to model electricity grids, AC and DC multi-grid power flow, three-phase unbalanced power flow and short circuit, and AC and DC multi-grid linear optimal power flow. The linear analysis family includes PTDF and LODF, AC linear net transfer capacity, and AC plus HVDC optimal net transfer capacity. The dynamic and probabilistic studies are RMS simulation in positive sequence, EMT simulation in unbalanced ABC formulation, stochastic power flow, continuation power flow, contingency analysis in power flow and LODF variants, and Sigma analysis for one-shot stability. On top of that sit investments analysis, a bus-branch schematic, a substation-line map diagram, time series and snapshot output for most simulations, an overhead tower designer, inputs analysis, and a model bug report and repair feature. The README describes the algorithms as industry tested, and the release history includes a version adding a new HELM implementation, which is the kind of feature that signals active development in the optimisation side.

Import and export coverage decides whether VeraGrid fits your data

The interoperability list is where a grid tool either becomes usable in a workflow or stays an island. VeraGrid imports many formats, namely PSSe .raw and .rawx, epc, dgs, matpower, pypsa, json, cim and cgmes, and it exports in a smaller but still practical set, covering the .xlsx, .veragrid and .json native formats, matpower, cgmes and PSSe .raw and .rawx. The topics attached to the repository include the comon-information-model and cim, and the interoperability with cgmes and CIM is what connects it to the standards-based side of the industry, while matpower and pypsa cover the research side. The asymmetry between the import and export lists deserves a note: you can bring in more than you can push out, so a workflow that ends in a PSSe raw file is straightforward while one that needs an epc export is not covered. The repository also ships example models and scripts under examples/, including TYNDP 2030 and 2040 veragrid files, so the file format has reference data rather than only documentation.

Security tooling and dependency discipline are visible in the tree

The repository carries a set of signals that matter for a dependency-heavy scientific package. There is an OpenSSF Best Practices badge, a Scorecard supply-chain security workflow, a CodeQL code scanning workflow, a Dependabot dependency graph workflow, and an osv-scanner configuration with an osv-report.md alongside it. The requirements file pins a long list of libraries, from numpy 2.2.0 and scipy 1.10.0 through networkx, pandas, PySide6 6.10, highspy, pulp, pymoo, fastapi and uvicorn, and out to mcp, numba, scikit-learn, pvlib and windpowerlib, which is a heavy but coherent set for optimisation, time series and solar and wind modelling. The root setup.py is described in its own header as a packaging shim, because the real distributable packages live under src/VeraGrid, src/VeraGridEngine and src/VeraGridServer, and because the documentation build installs doc/requirements.txt directly, so the root must not advertise a stale runtime dependency set. It still declares python_requires of 3.8 or newer, which is well below what the pinned dependencies need, so the effective floor is much higher. There is a fuzz/ directory, a benchmarks/ directory, and a dependency_map_of_veragrid.txt that maps the dependency tree. On the release side, 6.7.0 from 2026-09-23 removed Matplotlib, 6.5.30 from 2026-09-11 carried stability and bug fixes, and 6.5.0 from 2026-08-21 added the new HELM and DPR work, with the last push to the repository on 2026-10-15.

Editorial conclusion

VeraGrid suits academic and industrial users who want a full grid modelling environment without a commercial licence, especially where the study catalogue matters more than a polished interface. It is a poor fit for a small script that only needs one power flow, since installing the GUI package pulls in PySide6 and a long dependency list, and the engine-only package is the smaller option. Before adopting it, check the Python version, because setup.py declares python_requires of 3.8 or newer while the pinned dependencies such as numpy 2.2 and PySide6 6.10 are considerably newer than that floor, and confirm the recent removal of Matplotlib does not break an existing plotting workflow.

Frequently asked questions

Official sources

1. License: MPL-2.0
2. Project website
3. README
4. Releases
5. SanPen/VeraGrid on GitHub