pandapower, a power system model that lives in pandas dataframes

The model is a set of dataframes, not an object graph

pandapower is described as an easy to use network calculation program aimed to automate the analysis and optimization of power systems, and it uses the data analysis library pandas.

That choice is the design. A power network in pandapower is expressed as tabular data, one table per element type, held in the pandas structures the rest of the Python ecosystem already knows how to read. The consequence runs in both directions. Analysis code that already speaks dataframes can read a network without a translation layer, and the model itself can be inspected, filtered and diffed the way any other dataset is.

The description also makes the compatibility claim that matters for migration. pandapower is compatible with the commonly used MATPOWER and PYPOWER case format, which is the standard exchange shape for network data in this field. A case file that came out of a MATPOWER workflow is not a foreign object to pandapower, which makes it a reasonable first step for a team whose existing scripts and case data are in that format.

The scope is wide rather than narrow. The topic tags cover power flow, short circuit calculation, state estimation and optimization, and the project site splits its description into two pages, one for power system modeling and one for power system analysis. The audience is stated through the classifiers rather than the prose, listing developers, education and science and research, and the classification carries a Development Status of 5, Production/Stable.

The audience is therefore people who already know power systems and want to script them.

The solver menu is the reason to choose it

The description spends most of its length on which solvers pandapower can drive, and that list is the differentiator.

There is an improved Newton-Raphson power flow implementation, which is the default path for fast iterative solution of the network equations. There are all the PYPOWER solvers, so anything you can do with the reference implementation in Python is available. There are the C++ library solvers for fast steady-state distribution power system analysis, provided by the PowerGridModel project. There are the Newton-Raphson power flow solvers in the C++ library lightsim2grid. And there is the PowerModels.jl library, which is a Julia package.

That last one is unusual enough to deserve a note. A Python tool that can hand a network to a Julia optimisation library means a formulation written in Julia, with its own modelling abstraction, can be applied to a pandapower network. The repository carries a juliapkg.json at the top level, which is the file that describes the Julia package dependency, so the integration is a tracked part of the project rather than a user side workaround.

The practical effect of the list is that the same model can be run through a pure Python solver for clarity, a C++ solver for speed on large distribution networks, and a Julia formulation for optimisation problems where the modelling matters more than the raw throughput.

That choice is a real decision with a real cost, because each backend has its own capabilities and its own failure modes. A model that solves under one may not solve under another, and a user who switches solvers for speed is changing the numerical behaviour of their analysis, not just the runtime.

Where the documentation lives, and what a first run looks like

The README is a pointer to the published documentation, and the pointers are well chosen.

There is a documentation site at pandapower.org, with a start section that contains the installation notes, a minimal example and interactive tutorials, and a readthedocs documentation build at pandapower.readthedocs.io. The getting started links go straight to those three things, in that order, which is roughly the order a new user needs them.

The minimal example is the piece to look at first. Because pandapower's model is a set of pandas tables, the shortest useful program is not a constructor call but a set of table constructions followed by a run call, and the value of seeing the official minimal example is that you see the exact table structure the version you installed expects, which is the part that changes between major versions.

The interactive tutorials are the other half of the answer. Since the model is dataframes, a tutorial can be run in a notebook, and the project links a Binder badge, which means the tutorials can be launched in a browser without a local Python environment. For a domain like power systems, where a new user has a lot of notation to learn before they can ask a useful question, being able to poke at a working example without installing anything is worth a lot.

The install path itself is conventional: a PyPI package, with the badge linking to the package index, and the project requires Python 3.11 or newer.

Realistic data comes from SimBench, and pipes come from pandapipes

Two neighbouring projects are recommended from the project description, and they solve the two problems that most often stop a new user.

The first is SimBench, a separate project for realistic load profile data and grid models across all voltage levels, ready to be used in pandapower. The link goes both to a project website and to a GitHub repository. The point of it is that a synthetic test network in a tutorial is a single radial feeder with a handful of loads, and a real distribution network is a much harder thing to solve. Benchmark cases with realistic load profiles are how you find out whether your analysis survives contact with actual data.

The second is pandapipes, described as pandapower's sibling project, for modelling pipe networks for heat, gas or water. The recommendation is explicit: if you want to model pipe networks as well, use pandapipes rather than trying to force them into the electrical model.

That recommendation is worth taking seriously rather than reading as a footnote. A combined electricity and heat network has couplings between the two domains, and the sibling project is the place where that modelling is done properly, with its own documentation site and its own repository. The split keeps each codebase's data model coherent.

Taken together, these two pointers tell you what a realistic adoption looks like: build models with pandapower, calibrate them against benchmark data from SimBench, and keep the hydraulic side in pandapipes.

A research tool with a stable release cadence and a permissive licence

pandapower is a joint development of the research group of the Department for Sustainable Electrical Energy Systems at the University of Kassel and the Department for Distribution System Operation at the Fraunhofer Institute for Energy Economics and Energy System Technology in Kassel. That provenance is visible in the artefacts, not just the names.

The repository carries a CITATION.bib, a CHANGELOG.rst, an AUTHORS file and a CONTRIBUTING.md, and the packaging configuration lists both the LICENSE and the AUTHORS file as licence files. The build backend is setuptools with a dynamic version, and there is a mypy.ini, so type checking is part of the development setup rather than an afterthought. A .test_durations file at the top level records how long the test suite's individual tests take, which is how a project keeps a slow suite usable.

The licence picture has a wrinkle that an adopter should resolve by reading the file. The badge in the project description says BSD 3-Clause, and the packaging classifier says BSD License, but the licence recorded for the repository is a custom one that GitHub cannot classify. Those are compatible readings only if the custom text is the BSD 3-Clause text, and that is exactly the kind of thing you verify rather than assume. For a research tool used in published work, the AUTHORS and CITATION files also matter, since they are how attribution is recorded.

The release history is healthy and regular. The recent versions are v3.5.6 on 2026-10-07, v3.5.5 on 2026-09-22 and v3.5.4 on 2026-07-08, the default branch is develop, and the last push was on 2026-10-15. The version is dynamic in the packaging metadata, and there is a mailing list for people who want to follow developments.

Python 3.11 to 3.14, and what the dependency list implies

The packaging metadata is a good place to see what the project actually needs, and it is more demanding than the prose suggests.

The project requires Python 3.11 or newer, and the classifiers list support for 3.11, 3.12, 3.13 and 3.14. The classifiers also carry a reminder comment telling maintainers to update all GitHub pipelines when a version is added or removed, and to keep the mypy configuration in step with the lowest supported version. That is a small sign of how seriously the version matrix is maintained, and it is a good sign for a library that has to keep working across four interpreter versions.

The dependency list is the heavier part. pandas is pinned to a 3.0 series, networkx to a 3.6 series, numpy is bounded above and below, and scipy is conditioned on the interpreter version, with a 1.18 series for Python 3.12 and above and a version below 1.17 for older interpreters. There are also packaging, tqdm and colorama.

Two things follow. First, this is a scientific stack dependency, and the version bounds are tight enough that a conflicting pin elsewhere in your environment is a realistic problem rather than a theoretical one. Second, the scipy split by interpreter version means the resolution of your environment depends on which Python you run, so a lock file made on one interpreter is not automatically valid on another.

The numpy bound, at a 2.5 upper limit with a 1.26 floor, is worth reading as the project's position on the numpy 2.x transition, and the pandas 3.0 pin tells you which generation of the dataframe API the code is written against.

Editorial conclusion

Adopt pandapower if you need to model, analyse or optimise distribution and transmission networks in Python, especially if you are migrating from a MATPOWER or PYPOWER workflow and want the case data to live in dataframes you can manipulate directly. Do not adopt it as a production grid operation tool, and do not expect it to replace a validated tool for protection or metering decisions, because it is a research and planning tool maintained by university and institute groups. Before you commit, read the LICENSE file yourself, since the badge says BSD 3-Clause while the repository licence field is recorded as custom, and check that your Python version is covered, since the project requires 3.11 or newer and declares support through 3.14.

Frequently asked questions

Official sources

1. e2nIEE/pandapower on GitHub
2. Issues
3. Project website
4. README
5. Releases