modelSolver: Symbolic Power Simulation

• modelSolver is a symbolic, open-box framework for steady-state power network simulation that allows users to define power flow and state estimation models via mathematical expressions.
• It automates the symbolic derivation and sparse Jacobian assembly for both real and complex formulations, supporting features like Volt-VAr control and load tap changer modeling.
• The framework interoperates with MATPOWER through a Python converter, achieving benchmark case results with errors below 1e-6 and validating its practical accuracy.

Searching arXiv for the specific modelSolver paper and related context. modelSolver is a symbolic, model-driven software framework for steady-state power-network simulation and monitoring that centers problem specification on mathematical expressions rather than procedural programming (Dzafic et al., 25 Aug 2025). It is designed for power flow and state estimation, including voltage-regulated power flow with reactive limits, load tap changer models, continuation power flow, and Gauss-Newton state estimation with equality constraints, while allowing users to define parameters, variables, and equations directly in real or complex form (Dzafic et al., 25 Aug 2025). In the paper’s characterization, its defining feature is an open-box approach: instead of relying on hard-coded internal models, it lets users formulate custom power-system models symbolically and delegates parsing, differentiation, sparse assembly, and numerical solution to the framework (Dzafic et al., 25 Aug 2025).

1. Definition and scope

modelSolver is presented as a “symbolic model-driven solver for power network simulation and monitoring” (Dzafic et al., 25 Aug 2025). Its scope is explicitly steady-state power-system computation, with two principal application classes: power flow and state estimation. The paper positions it not as a single specialized algorithm, but as a framework in which the model definition is the primary artifact and the numerical solution machinery is generated automatically from that definition.

The software is intended to remove dependence on traditional implementation constructs such as arrays, loops, and sparse matrix programming. Instead, the user specifies model components through groups such as Vars, Params, NLEs, WLSEs, ECs, Limits, Repeats, and SubModel. This means that device equations, controller logic, and measurement models are written directly as symbolic expressions rather than embedded in hard-coded source routines (Dzafic et al., 25 Aug 2025).

The paper repeatedly contrasts this with power-system tools whose models are fixed internally. In that contrast, modelSolver is described as open-box: the solver infrastructure is generic, but the governing equations remain user-definable. This is especially relevant for situations in which new controller behavior, inverter-based resource logic, or nonstandard operating constraints must be introduced without modifying internal solver code (Dzafic et al., 25 Aug 2025).

2. Symbolic model-driven formulation

The framework is model-driven in the strict sense that the workflow begins from equations rather than from algorithmic code. A user writes parameters, variables, nonlinear equations, weighted least-squares equations, equality constraints, logic, and repetition rules; the software then parses these expressions, derives symbolic derivatives, and invokes the corresponding sparse numerical procedures (Dzafic et al., 25 Aug 2025).

For nonlinear algebraic models, the relevant problem class is Model[type=NL], with equations placed in NLEs. For state estimation, the relevant class is Model[type=[WLS](https://www.emergentmind.com/topics/augmented-weighted-least-squares-wls-estimator)], with measurement equations in WLSEs and optional exact constraints in ECs. The paper states that equation expressions define residual equations, assignment expressions support operators such as =, +=, -=, *=, /=, and ^=, and logic expressions support if-else and switch-case (Dzafic et al., 25 Aug 2025).

This symbolic interface is not limited to purely algebraic equalities. The paper shows that operational logic can be embedded directly in the model text. Reactive limit enforcement for PV buses is implemented through if-else; inverter Volt-VAr behavior is represented through switch-case; repeated continuation-style studies are expressed through Repeats; and nested workflows such as synthetic measurement generation are handled through SubModel (Dzafic et al., 25 Aug 2025). This suggests a formulation environment in which steady-state network equations and supervisory control logic are expressed in one symbolic layer.

A plausible implication is that modelSolver shifts software complexity away from user-written sparse numerical kernels and toward the framework’s parsing and symbolic processing layer. The paper does not describe parser internals or a low-level symbolic engine, but it is explicit that the framework automatically generates symbolic sparse Jacobians for nonlinear models and symbolic sparse measurement Jacobians for state estimation (Dzafic et al., 25 Aug 2025).

3. Mathematical formulations

The paper organizes the mathematics around two core formulations: nonlinear algebraic equations for power flow and weighted least squares for state estimation.

For power flow, modelSolver solves a nonlinear system

$F(x)=0,$

where the unknown state vector may be represented either with real variables, such as voltage magnitudes and angles, or with complex variables, such as bus voltages and their conjugates. The intended Newton-Raphson update is the standard one,

$$J(x^{(k)})\Delta x^{(k)}=-F(x^{(k)}), \qquad x^{(k+1)}=x^{(k)}+\Delta x^{(k)},$$

with the Jacobian obtained symbolically and treated sparsely (Dzafic et al., 25 Aug 2025).

The paper gives a three-node real-variable example. At a zero-injection node,

$$aY_{21}v_1\cos(\theta_{21}+\delta_1) + v_2 aY_{22}\cos(\theta_{22}+\delta_2) + aY_{23}v_3\cos(\theta_{23}+\delta_3) = 0$$

and

$$aY_{21}v_1\sin(\theta_{21}+\delta_1) + v_2 aY_{22}\sin(\theta_{22}+\delta_2) + aY_{23}v_3\sin(\theta_{23}+\delta_3) = 0.$$

At a PQ node,

$$v_3^2 aY_{33}\cos(\theta_{33}) + v_3\left(aY_{32}v_2\cos(\delta_3-\theta_{32}-\delta_2)\right) = P_{3,\text{inj}}$$

and

$$- v_3^2 aY_{33}\sin(\theta_{33}) + v_3\left(aY_{32}v_2\sin(\delta_3-\theta_{32}-\delta_2)\right) = Q_{3,\text{inj}}.$$

The same system is also written in complex form, for example

$y_{22}v_2 - y_{21}v_1 - y_{23}v_3 = 0$

and

$$v_3 \, \operatorname{conj}(y_{33}v_3 - y_{23}v_2) = S_{3,\text{inj}},$$

with conjugate companion equations included explicitly (Dzafic et al., 25 Aug 2025).

For state estimation, the paper states that modelSolver uses the Weighted Least Squares normal equations approach and, when needed, normal equations with equality constraints (Dzafic et al., 25 Aug 2025). The implied objective is

$\min_x \sum_m w_m |r_m(x)|^2,$

or equivalently

$\min_x \; r(x)^TWr(x),$

with Gauss-Newton normal equations based on a symbolic sparse measurement Jacobian. Measurement equations may be given in complex form, such as

$$J(x^{(k)})\Delta x^{(k)}=-F(x^{(k)}), \qquad x^{(k+1)}=x^{(k)}+\Delta x^{(k)},$$0

$$J(x^{(k)})\Delta x^{(k)}=-F(x^{(k)}), \qquad x^{(k+1)}=x^{(k)}+\Delta x^{(k)},$$1

and voltage-magnitude relations like

$$J(x^{(k)})\Delta x^{(k)}=-F(x^{(k)}), \qquad x^{(k+1)}=x^{(k)}+\Delta x^{(k)},$$2

Equality constraints can then enforce exact conditions such as zero injection: $$J(x^{(k)})\Delta x^{(k)}=-F(x^{(k)}), \qquad x^{(k+1)}=x^{(k)}+\Delta x^{(k)},$$3 The paper explicitly distinguishes this exact-constraint treatment from modeling zero injections as virtual measurements with large weights (Dzafic et al., 25 Aug 2025).

4. Supported capabilities and model patterns

The framework supports several specific power-system formulations beyond basic load flow. One important example is PV-bus modeling with reactive power limits. In complex form, the active-power relation is written as

$$J(x^{(k)})\Delta x^{(k)}=-F(x^{(k)}), \qquad x^{(k+1)}=x^{(k)}+\Delta x^{(k)},$$4

while voltage regulation is imposed by

$$J(x^{(k)})\Delta x^{(k)}=-F(x^{(k)}), \qquad x^{(k+1)}=x^{(k)}+\Delta x^{(k)},$$5

when the generator is in regulating mode. If reactive limits are violated, the model switches to a fixed-reactive formulation,

$$J(x^{(k)})\Delta x^{(k)}=-F(x^{(k)}), \qquad x^{(k+1)}=x^{(k)}+\Delta x^{(k)},$$6

with

$$J(x^{(k)})\Delta x^{(k)}=-F(x^{(k)}), \qquad x^{(k+1)}=x^{(k)}+\Delta x^{(k)},$$7

used to detect violations (Dzafic et al., 25 Aug 2025).

A second example is symbolic inverter Volt-VAr control. The paper expresses the reactive injection as a piecewise law: $$J(x^{(k)})\Delta x^{(k)}=-F(x^{(k)}), \qquad x^{(k+1)}=x^{(k)}+\Delta x^{(k)},$$8 with

$$J(x^{(k)})\Delta x^{(k)}=-F(x^{(k)}), \qquad x^{(k+1)}=x^{(k)}+\Delta x^{(k)},$$9

This demonstrates that controller laws with branching logic are first-class symbolic objects in the framework (Dzafic et al., 25 Aug 2025).

A third example is load tap changer modeling. The tap ratio $$aY_{21}v_1\cos(\theta_{21}+\delta_1) + v_2 aY_{22}\cos(\theta_{22}+\delta_2) + aY_{23}v_3\cos(\theta_{23}+\delta_3) = 0$$0 enters directly into the network equations, for example

$$aY_{21}v_1\cos(\theta_{21}+\delta_1) + v_2 aY_{22}\cos(\theta_{22}+\delta_2) + aY_{23}v_3\cos(\theta_{23}+\delta_3) = 0$$1

and

$$aY_{21}v_1\cos(\theta_{21}+\delta_1) + v_2 aY_{22}\cos(\theta_{22}+\delta_2) + aY_{23}v_3\cos(\theta_{23}+\delta_3) = 0$$2

otherwise

$$aY_{21}v_1\cos(\theta_{21}+\delta_1) + v_2 aY_{22}\cos(\theta_{22}+\delta_2) + aY_{23}v_3\cos(\theta_{23}+\delta_3) = 0$$3

Discrete tap logic is implemented in processing groups through expressions such as

$$aY_{21}v_1\cos(\theta_{21}+\delta_1) + v_2 aY_{22}\cos(\theta_{22}+\delta_2) + aY_{23}v_3\cos(\theta_{23}+\delta_3) = 0$$4

and

$$aY_{21}v_1\cos(\theta_{21}+\delta_1) + v_2 aY_{22}\cos(\theta_{22}+\delta_2) + aY_{23}v_3\cos(\theta_{23}+\delta_3) = 0$$5

The paper does not define the internal semantics of disc, so its exact numerical behavior is not specified there (Dzafic et al., 25 Aug 2025).

The paper also supports continuation-style studies through repeated model execution. In the cited example, the complex load is updated by

$$aY_{21}v_1\cos(\theta_{21}+\delta_1) + v_2 aY_{22}\cos(\theta_{22}+\delta_2) + aY_{23}v_3\cos(\theta_{23}+\delta_3) = 0$$6

allowing a repeated power-flow sequence that traces a P–V curve. This is implemented operationally through the Repeats mechanism rather than through an explicit arc-length continuation derivation (Dzafic et al., 25 Aug 2025).

5. Software architecture and workflow

The user-facing workflow begins with a model file and ends with command-line execution: $$aY_{21}v_1\cos(\theta_{21}+\delta_1) + v_2 aY_{22}\cos(\theta_{22}+\delta_2) + aY_{23}v_3\cos(\theta_{23}+\delta_3) = 0$$7 The model file contains named groups for parameters, variables, equations, limits, processing stages, repetition logic, and nested submodels. The paper’s flowchart indicates initialization of counters such as repeat#, outer#, and baseIter#, followed by optional preprocessing, optional SubModel execution, the main nonlinear or WLS solve, iterative post-processing, limit checking, outer-loop re-solving if statuses change, and optional repetition (Dzafic et al., 25 Aug 2025).

Internally, the framework distinguishes at least three numerical pathways. For nonlinear algebraic equations, it generates a symbolic sparse Jacobian and invokes Newton-Raphson. For weighted least squares, it generates a symbolic sparse measurement Jacobian and assembles sparse gain matrices for the normal-equations solve. For equality-constrained estimation, it extends that normal-equations machinery with exact constraints (Dzafic et al., 25 Aug 2025).

The paper emphasizes that users need not manually implement sparse matrix assembly or factorization. The framework automatically performs equation parsing, symbolic differentiation, sparse Jacobian factorization, Newton-Raphson iteration, sparse gain-matrix construction, and normal-equations solution (Dzafic et al., 25 Aug 2025). This suggests that modelSolver should be understood less as a domain-specific script interpreter than as a symbolic front end to sparse numerical kernels specialized for steady-state power-system problems.

A notable architectural feature is support for both real-domain and complex-domain modeling. Real models are declared with domain=real; complex models with domain=cmplx; and complex conjugates can be included explicitly through conj=true. The paper argues that complex-domain formulations are often more compact and natural for network equations, especially for current-balance and complex-power expressions (Dzafic et al., 25 Aug 2025).

6. Interoperability, validation, and limitations

The main interoperability mechanism is compatibility with MATPOWER via a Python converter script, invoked as

$$aY_{21}v_1\cos(\theta_{21}+\delta_1) + v_2 aY_{22}\cos(\theta_{22}+\delta_2) + aY_{23}v_3\cos(\theta_{23}+\delta_3) = 0$$8

The script is configured through config.xml, requires Python 3.7+, and can generate symbolic modelSolver files from MATPOWER case descriptions in polar, rectangular, or complex representation, with configurable naming conventions and ZIP load settings (Dzafic et al., 25 Aug 2025). This makes standard benchmark networks portable into the symbolic framework and then modifiable with additional custom control logic.

The paper’s clearest quantitative validation is the converter test on case5, case9, case30, case118, and case300, each generated in three representations—polar, rectangular, and complex—for a total of 15 generated cases. The reported power-flow results matched MATPOWER with absolute error less than $$aY_{21}v_1\cos(\theta_{21}+\delta_1) + v_2 aY_{22}\cos(\theta_{22}+\delta_2) + aY_{23}v_3\cos(\theta_{23}+\delta_3) = 0$$9 (Dzafic et al., 25 Aug 2025). This is evidence for functional equivalence at the imported steady-state level, though not for computational superiority.

The demonstrations in the paper cover real and complex power flow, PV buses with reactive limits, inverter Volt-VAr control, repeated power flow for P–V curves, state estimation with equality constraints, measurement generation through SubModel, and LTC transformer regulation (Dzafic et al., 25 Aug 2025). The emphasis is therefore on expressiveness and workflow flexibility rather than on large-scale runtime benchmarking.

Several scope boundaries are explicit or implicit. The current framework is focused on steady-state applications—specifically power flow and state estimation. Future work is stated to include differential-algebraic models for stability analysis, built-in explicit and implicit solvers, and a graphical user interface, which indicates that these are outside the present contribution (Dzafic et al., 25 Aug 2025). The paper also does not disclose parser internals, symbolic-engine internals, or detailed numerical linear algebra implementation choices. A plausible implication is that the present work is best understood as an equation-centric front end with demonstrated functional breadth, rather than as a fully benchmarked high-performance alternative to established production solvers.

In summary, modelSolver is a symbolic, open-box, model-driven framework for steady-state power-system computation in which nonlinear algebraic equations and weighted least-squares estimation models are written directly as mathematical expressions, using real or complex variables, conditional logic, equality constraints, repeated simulations, and submodels (Dzafic et al., 25 Aug 2025). Its central significance lies in re-centering power-system software around declarative mathematical modeling instead of hard-coded solver routines, thereby lowering the barrier to custom power-flow and monitoring formulations while retaining automatic sparse symbolic differentiation and numerical solution.