PyPSA-Eur is an open model of the whole European energy system

A model dataset, not a simulator

PyPSA-Eur is described as an open model dataset of the European energy system at the transmission network level, covering the full ENTSO-E area and all energy sectors, including transport, heating, biomass, industry and agriculture. Besides the power grid, pipeline networks for gas, hydrogen, carbon dioxide and liquid fuels are included.

The word dataset is the important part of that description. This repository does not contain a program that simulates a European energy system. It contains the assembled inputs, the processing rules that turn those inputs into a network model, and the configuration that a modelling framework consumes. The model itself is designed to be imported into PyPSA, the open-source energy system modelling framework, and the optimisation is run from there.

The scope is also stated in one line: it is suitable both for planning studies and operational studies. That is an unusual claim for a model of this size, and it follows from the data being a transmission network model rather than a distribution one. At the level of countries and NUTS2 regions, the same network can be optimised for a future year with capacity expansion or dispatched hour by hour for an existing year.

For the audience, this is a research and policy infrastructure project rather than a tool. The outputs are not reports but data releases, which is why the Zenodo deposits and the citation file are as prominent in the README as the model description.

What the dataset is made of

The README lists the components, and the list is the clearest statement of scope in the project.

The power grid model is based on OpenStreetMap for voltage levels above 220 kV, with an optional resolution above 60 kV. The power plant fleet comes from the open powerplantmatching database. Electrical demand time series come from the ENTSO-E Transparency Platform. Renewable time series are based on ERA5 and SARAH-3, assembled with atlite, and the geographical potentials for wind and solar generators come from a land eligibility analysis in atlite as well. Energy balances are compiled from Eurostat and JRC-IDEES datasets.

Two things stand out. The first is that every input is a public dataset, and the project assembles them rather than hosting a proprietary dataset, which is what makes the pipeline reproducible by someone else. The second is the scale of the geography: the grid is European, and the demand, generation and balance data are European too.

The unclustered model is shown in a map in the README, dated as of 1 January 2026, which tells you the vintage of the underlying data and also implies that this is a dated cut of the data that gets rebuilt.

For a user, the practical implication is that the network and the plant fleet are the parts you inherit, while the sector structure, the technology costs and the policy assumptions are the parts you configure. The configuration lives in the config directory, and the shipped configurations live in the profiles directory.

Snakemake is the build system you interact with

The model is built from open data using a Snakemake workflow, and the repository layout is the Snakemake layout.

At the top level there is a Snakefile, which is the entry point for the workflow, and a rules directory holding the pipeline rules. There are separate directories for scripts, resources, data, configuration and profiles, and an envs directory for the environments the workflow can create. The docker directory holds container definitions, and there is a benchmarks directory, a test directory and a utils directory.

The environment management is worth noting because it affects how you reproduce a run. There is a pixi directory alongside pixi.toml and a lock file, so the environment can be resolved and locked with pixi, and there is a Conda flavour with envs. The repository also ships a ruff.toml for linting, an .pre-commit-config.yaml, a .git-blame-ignore-revs file, and a .lychee.toml, which is the configuration for a link checker, a sensible thing to have in a repository full of data source URLs.

There is a Docker path as well, so the whole pipeline can run in a container. For a project whose inputs come from many external services, the combination of a pinned environment, a locked dependency set and a container option is what makes a run repeatable on a different machine, and that is the main practical reason to adopt the repository as it is rather than to copy the data out of it.

The clustering warning is the most important paragraph

The README is unusually direct about the model not working at full resolution, and this is the part to read before running anything.

For computational reasons the model is usually clustered down to 50 to 250 nodes, and the README shows the electricity network and power plants clustered to NUTS2 regions. The warning explains why. At high granularity, the assignment of loads and generators to the nearest network node may not be a correct assumption, depending on the topology of the underlying distribution grid. The consequence is that local grid bottlenecks may cause unrealistic load-shedding or generator curtailment. The recommendation is to cluster the network to a couple of hundred nodes to remove those local inconsistencies, and the README points to Section 3.4 on model validation in the published paper for the discussion.

There is a further point: the project does not recommend using the full resolution network model for simulations.

This is a real limitation and not a rounding error. The artefact that makes PyPSA-Eur tractable, a transmission network divided into a couple of hundred regions, is also the artefact that produces the artefacts, because a transmission-level model has no representation of the distribution constraints that would actually bind in a particular town. The result is a model whose congestion signals are only as good as the clustering, and a paper that reports results has to justify that choice.

The README also flags that PyPSA-Eur is under active development, has several limitations documented on its limitations page, and that the documentation remains somewhat patchy. The known issues are collected in the GitHub issue tracker.

MIT for the code, separate terms for every data source

The licence arrangement is two-layered, and the README is explicit about it. The code in PyPSA-Eur is released as free software under the MIT License, with the details in doc/licenses.md. However, different licences and terms of use may apply to the various input data, and those are documented in doc/data_sources.md.

That is the honest way to describe a project that assembles a dozen upstream datasets, and it has a direct consequence. A user who redistributes the processed dataset, as opposed to running the pipeline, has to check the terms of every input, because the pipeline output inherits them. The MIT licence covers the workflow that assembles the data, not the data itself.

The project takes software heritage compliance seriously enough to carry a REUSE status badge, a REUSE.toml file and a LICENSES directory, and it uses SPDX headers, with the README's own header carrying an SPDX licence identifier. Every source file in the tree is expected to declare its own licence, and the LICENSES directory holds the texts. For an organisation that has to answer a provenance question about where a number came from, that convention is worth more than the licence identifier itself.

The data releases are archived separately on Zenodo, with one DOI for PyPSA-Eur and another for the security-of-supply variant, so a specific run can be cited as a versioned artefact rather than as a moving branch. CITATION.cff is present for the same reason, and the release tags are dated, v2026.09.0, v2026.08.0 and v2026.02.0, so a paper can point at the exact model version that produced its numbers.

Who maintains it, and what to read first

Maintenance is currently led by the Department of Digital Transformation in Energy Systems at the Technical University of Berlin, and the README notes that previous versions were developed at the Karlsruhe Institute of Technology funded by the Helmholtz Association. That handover is worth knowing, because it tells you where the institutional backing sits now and which release series came out of which institution.

The project says it has many contributors, and the README points to several sources for what the model can do. The Joule paper on the potential role of a hydrogen network in Europe, a second Joule paper describing the industry sector, and a 2021 presentation at EMP-E.

For support there are two channels. The Discord server is for discussion with other PyPSA users, organising projects and sharing news, while the GitHub issues page is for bugs and feature requests. That division is sensible, because a modelling question about the European energy system and a bug in a Snakemake rule need different kinds of answer.

One more detail from the badges: the Snakemake requirement is version 9 or later. A project that keeps a locked environment and a large rule set cannot run on an old workflow engine, and the engine version is one of the first things to check when an existing environment fails to run the pipeline.

Editorial conclusion

PyPSA-Eur fits a modeller or policy analyst who needs a reproducible, openly licensed European energy system model they can run and modify, and who accepts that the network model has to be clustered before its results mean anything. It is the wrong choice if you need a single country's distribution-level view, since the data above 220 kV is not a substitute for a local grid model, and it is the wrong choice if you need the input data under one licence, because each source keeps its own terms. Before running it, read the limitations page and the warnings, decide the clustering level, and set up the environment with the pixi and conda environment files rather than installing packages by hand.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. PyPSA/pypsa-eur on GitHub
4. README
5. Releases