Skip to main content

PESLite

PESLite is a Python time-domain simulator for networks of power-electronic converters. It provides:

  • YAML simulation files with buses, lines, sources, loads, converters and timed events;
  • grid-following and grid-forming control in sampled or continuous form;
  • switching, PWM-period-averaged and ideal averaged bridge models, selectable per converter;
  • fixed-step, adaptive and multirate integration;
  • ADC/PWM timing, converter-owned protection, energy accounting and restart from saved states;
  • export of a configured simulation as a standalone C++17 simulator.

The power circuit uses SI units (V, A, H, F and ohm), controller quantities ending in _pu are per-unit values, time is in seconds and angles are in radians.

Installation

pip install peslite

Python 3.10 or newer is required.

Running simulations

Run a simulation file, a bundled *-example, or the first bundled example when no name is given:

peslite case.pes
peslite gfl-example
peslite

Simulation files are YAML text; the .pes extension is conventional but not required. Results are written to output/<name>/ by default. Dotted paths override individual parameters:

peslite case.pes --set simulation.t_end=1.0 --out output/test

--switching, --pwm-averaging and --averaging select a bridge/solver preset for every unit. An explicit --set has higher priority than a preset, which has higher priority than the file. Progress can be printed with --progress SECONDS and extended with repeatable --watch NAME. Use peslite --help for the complete command-line interface; --resolved, --list-states and --ph-report provide configuration and model diagnostics.

The same workflow is available from Python:

import peslite

p = peslite.load("case.pes", **{"simulation.t_end": 1.0})
r = peslite.Simulation(p).run()       # output/run

r.states["vsc.dclink.u_C"]
r.plant["vsc.i_conv_a"]
r.ctrl["vsc.id_pu"]
r.final_states()
r.summary

Histories are read from the final CSV files only when requested; they are not retained in memory during the simulation.

Exporting a C++ simulator

peslite-convert exports one self-contained peslite.cpp. Parameters following the simulation file remain variable in the compiled simulator; all selects every parameter supported by that configuration and backend:

peslite-convert case.pes simulation.t_end units.vsc.ctrl.references.p_ref_pu
# or: peslite-convert case.pes all

The default destination is export/<name>/peslite.cpp. Compile it with any C++17 compiler:

c++ -O3 -DNDEBUG -std=c++17 export/case/peslite.cpp -o export/case/peslite

The executable follows the normal PESLite command conventions for configuration overrides and output selection:

export/case/peslite --list-params
export/case/peslite --config another.pes \
  --set simulation.t_end=5.0 --out output/test

--list-params reports the parameters retained by this particular export. At run time, compiled defaults have the lowest priority, --config overrides them, and --set has the highest priority. Values in a supplied configuration that were not exported as variables are warned about and ignored. Attempting to set such a path reports that the parameter is not variable.

The generated source uses only the C++17 standard library; it does not need Python, NumPy, SciPy or a YAML library. The compiled simulator writes the same states.csv, signal files, summary.json and resolved simulation.pes as the Python command. Exporting is also available through peslite.export(..., "cpp", variables=[...]) or Simulation.export().

Simulation files and events

A simulation file has model sections (base, buses, branches, sources, units and optional elements), an events mapping, simulation settings and optional meta text. Initial values, solver settings and output settings live under simulation. Switches are written as 0 or 1.

--resolved prints the complete parameter tree after defaults and overrides. Every run saves that same resolved tree as simulation.pes, which can be loaded to repeat the run.

Events share one mapping and may connect or disconnect an entity, or change validated run-time parameters:

events:
  connect_vsc: {type: connect, target: vsc, t: 0.2, ramp: 1.0}
  p_step: {type: set, t: 2.0, set: {units.vsc.ctrl.references.p_ref_pu: 0.8}}
  line_trip: {type: disconnect, target: line, t: 4.0}

Every event time is an exact integration boundary: the interval ending there uses the old model and the following interval uses the updated model. Units, sources, branches and registered elements use their own connect, disconnect and retune operations. A tripped converter remains disconnected.

Bridge, control and solver models

Each converter selects its bridge independently with units.<name>.bridge.model:

Model Behaviour
switching Ideal switches evaluated at exact carrier-comparison instants.
pwm_averaging Active duty ratios drive a continuous bridge between PWM register loads.
averaging Ideal controlled voltage source with controller states integrated continuously.

pwm_averaging is the file default. It preserves the sampled controller, ADC window, PWM timer, active/shadow registers and computation timing of switching while omitting carrier ripple. Ideal averaging removes the ADC/PWM schedule and integrates controller equations with the plant; sampled-only settings may remain in a shared configuration and are silently ignored in this mode.

Fixed and adaptive single-rate solvers are available, along with multirate subsystem steps. Ideal averaging normally uses adaptive DP45, while the two sampled bridge presets use fixed-step RK4. Instantaneous feedback loops are detected from port dependencies and solved internally, including feedback between custom continuous control loops; users do not configure manual loop breaks.

Controllers receive SI measurements and return duty ratios or continuous voltage commands. Startup controls gate release and reference ramping, while all fast and sampled protection belongs to the converter Unit. A trip blocks the gates, opens the AC terminal and disconnects the DC source for the rest of the run.

Output, progress and restart

File Content
states.csv State snapshots; any saved row can initialize another run.
plant.csv, ctrl.<unit>.csv Optional plant and controller signals.
energy.csv Optional stored-energy and power-balance history.
summary.json Stop condition, solver counts, protection and energy summary.
simulation.pes Complete configuration actually used for the run.

Enabled histories stream directly to their final files in bounded batches. Disabling state output still retains the terminal state for final_states(), and disabling energy output suppresses only the history, not the summary checks.

simulation.initial.t and simulation.t_end are used exactly rather than rounded to a converter timer grid. Restart restores saved physical and controller state, PWM registers, ADC accumulators and timers as applicable. Intermediate oversampled ADC samples are not states, so such a run should be continued from a control interrupt.

Runtime paths are entity-first: physical states use <entity>.*, converter internals use <unit>.ctrl.*, <unit>.pwm.* and <unit>.meas.*, and global solver state uses solver.*. Complex states may be watched by name to display their magnitude. Unit prefixes distinguish the same quantity on different converters.

Extending PESLite

Control loops, circuit elements and events can be registered with register_loop_type, register_element_type and register_event_type. Each registered type owns a frozen parameter dataclass, so custom file parameters use the normal parser and validation. A custom loop may provide sampled updates, continuous state derivatives, or both. User solvers may additionally implement settle() and parameters_changed() for event-aware operation.

Executable custom-type examples live in the tests. The root examples/ directory intentionally contains only YAML simulation files, which are included in the wheel and remain available by their *-example names after installation.

Development

The package uses a src/ layout:

  • components/ contains network, converter, ADC and PWM models;
  • control/ contains loops, controller graphs and modulation;
  • assembly/ validates configuration and builds systems, events and exporters;
  • solver/ contains model evaluation, integration, energy checks and simulation I/O.

Run the test suite with:

python -m pytest

License

GNU Affero General Public License v3.0 only (AGPL-3.0-only). See LICENSE.

Metadata

Release files for peslite 0.2.1

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for peslite 0.2.1
File Size Uploaded
peslite-0.2.1.tar.gz 218.3 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for peslite 0.2.1
File Interpreter ABI Platform
peslite-0.2.1-py3-none-any.whl Python 3 none any Details

Total release size: 418.4 kB

Release files / peslite-0.2.1.tar.gz

Download URL peslite-0.2.1.tar.gz
Size 218.3 kB
Tags Source
SHA-256 checksum
How to use checksums
2d5a15b215cd836d1a7d34b934bb8b11fbf857388d083c9a0c6933546df65788
BLAKE2b-256 checksum
How to use checksums
5b8802fe2dcaf81f46f1f525d09b24ef0f1c7d29b82a9c12bfd1095812aa3cb7
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 2, 2026.

Transparency log

Release files / peslite-0.2.1-py3-none-any.whl

Download URL peslite-0.2.1-py3-none-any.whl
Size 200.1 kB
Tags Python 3
SHA-256 checksum
How to use checksums
15569bfc468b01a8a3d18262568945bd95b78a5bc590abb9af96a556e181e520
BLAKE2b-256 checksum
How to use checksums
219cbdf013a6d4a428eec8284bcbfe4637c6ba8d0cf014ecd1d5974c3ab8c70b
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 2, 2026.

Transparency log

Release history Release notifications | RSS feed

0.3.0

2 release files

0.2.2

2 release files

This release

0.2.1 This release

2 release files

0.2.0

2 release files

0.1.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page