The loadflow-server is a microservice of the GridSuite platform dedicated to power network load flow computation.
It provides the following capabilities:
- Run load flow computations on a network using configurable providers (OpenLoadFlow, DynaFlow).
- Detect and store limit violations (current, voltage, active power, ...) with enriched metadata (overload durations, PATL limits, upcoming overloads).
- Compute energy balance per connected component and per country (load, generation, losses, net positions, cross-border exchanges).
- Store results in a relational database and query them with filtering, sorting, and pagination.
- Manage parameter sets (create, read, update, duplicate, delete) with provider-aware limit reduction configurations.
- Run computations either synchronously (direct response) or asynchronously (via a RabbitMQ message queue).
- Spring Boot (Web, Data JPA, Actuator, Cloud Stream)
- PostgreSQL
- Liquibase
- RabbitMQ via Spring Cloud Stream
- API documentation : OpenAPI / Swagger (
springdoc) - Micrometer / Prometheus
- gridsuite-computation
- powsybl-loadflow-api: powsybl API/SPI for load flow computation, used to run the analysis and model its inputs/outputs (parameters, results). The concrete computation engine is a pluggable provider (OpenLoadFlow, DynaFlow), resolved at runtime via
ServiceLoader.
Build Docker image
mvn install -DskipTests -Dpowsybl.docker.installPlease read liquibase usage for instructions to automatically generate changesets. After you generated a changeset do not forget to add it to git and in src/resource/db/changelog/db.changelog-master.yml
┌──────────────────────┐
│ loadflow-server │──► network-store-server (read/write network topology)
│ │──► filter-server (resolve equipment filters for limit violations)
│ │──► report-server (post computation functional logs)
└──────────────────────┘
▲ ▼
RabbitMQ (loadflow.run / loadflow.cancel / loadflow.result / loadflow.stopped)
- The controller publishes a message on the
loadflow.runqueue. - Parallel consumers (
consumeRun1throughconsumeRunX) process messages concurrently for load balancing. - The computation result is published on
loadflow.result. - Cancellation of a running computation goes through the
loadflow.cancelqueue. - Dead-letter queues (
loadflow.run.dlx) and quorum queues ensure reliability.
A load flow result is composed of several complementary datasets exposed through the REST API:
| Dataset | Description |
|---|---|
| Component results | Per-electrical-island results: status, iteration count, distributed active power, energy balance (consumption, generation, losses, exchanges). Supports filtering, sorting, and pagination. |
| Limit violations | Detected current and voltage limit violations with enriched metadata: overload duration, PATL limit, upcoming overload, next limit name. Supports global filters (network-element-based), column filters, sorting, and pagination. |
| Modifications | Tap changer positions and shunt compensator section counts applied to the network when applySolvedValues=true (stored as JSON). |
| Country adequacy | Per-country energy balance: load, generation, losses, net position, and cross-border exchange matrix. |
All major computation steps (network loading, computation execution, result saving, network flushing) are wrapped in named Micrometer observations via LoadFlowObserver, enabling distributed tracing and metric collection without cluttering business logic.
The following capabilities are provided by the gridsuite-computation shared library:
- asynchronous run/cancel pipeline,
- transactional result notifications,
- network equipment filtering,
- report integration,
- Micrometer observability.
The loadflow-server itself focuses on load flow-specific logic (parameters, result model, providers) and delegates the common computation infrastructure to this lib.
You can find information on openLoadFlow here