IEEEST Stabilizer Improvements/Corrections by lukelowry · Pull Request #460 · ORNL/GridKit

lukelowry · 2026-06-22T16:49:18Z

Description

Fixes and cleans up the IEEEST stabilizer implementation and documentation.

This updates the older initial implementation style so that reduced-order notch filters and zero denominator time constants are handled consistently

Proposed changes

Replace the branchy/safe-inverse notch logic with a fixed DAE form using differential tags.
Initialize IEEEST from the attached input signal instead of forcing all states to zero.
Document the implemented equations, initialization, derived parameters, and unsupported compatibility parameters.
Tests for initialization, residuals, invalid wiring, invalid notch parameters, zero time constants, and Jacobian consistency.

Checklist

All tests pass for the focused PhasorDynamics coverage.
Code compiles cleanly with flags -Wall -Wpedantic -Wconversion -Wextra.
The new code follows GridKit™ style guidelines.
There are unit tests for the new code.
The new code is documented.
The feature branch is rebased with respect to the target branch.

Changelog changes N/A

Further comments

This is cleanup/correction work for the existing IEEEST model, not a new model

lukelowry · 2026-06-22T18:44:31Z

@pelesh this fix is also ready to be merged I forgot to make a PR for this one.

pelesh

The logic governing changing differential into algebraic equations and vice versa does not seem to be sustainable. This requires more offline discussion.

pelesh · 2026-06-24T21:02:03Z

+        f[8]  = tag_[4] * (-T2_ * (v5 - x5) + T1_ * (v4 - x5)) + (1 - tag_[4]) * (v4 - v5);
+        f[9]  = tag_[5] * (-T4_ * (v6 - x6) + T3_ * (v5 - x6)) + (1 - tag_[5]) * (v5 - v6);
+        f[10] = tag_[6] * (-T6_ * v7 + Ks_ * T5_ * (v6 - x7)) + (1 - tag_[6]) * (Ks_ * v6 - v7);


I am not sure if this is a good idea. We are changing equations based on whether we defined other equations to be differential or algebraic. Furthermore, we rely here on implicit bool-to-integer and integer-to-floating point conversions. This logic needs to be implemented in a different way.

I am not sure how to implement this without introducing template-y solutions. Do we want to move toward something like this where we define the model conditionally?

template <class ScalarT, typename IdxT, Order order, Block t2, Block t4, Block t6>

But there are 31 different permutations, so there would be a lot of duplicate code. I don't know what the general approach should be, so I am open to any suggestions.

pelesh · 2026-06-24T21:14:09Z

+        tag_[0]  = (a2_ != ZERO<RealT> || a3_ != ZERO<RealT> || a4_ != ZERO<RealT>);
+        tag_[1]  = tag_[0];
+        tag_[2]  = (a3_ != ZERO<RealT> || a4_ != ZERO<RealT>);
+        tag_[3]  = (a4_ != ZERO<RealT>);
+        tag_[4]  = (T2_ != ZERO<RealT>);
+        tag_[5]  = (T4_ != ZERO<RealT>);
+        tag_[6]  = (T6_ != ZERO<RealT>);


The logic implemented this way will break when we add solvers that require DAEs implemented in Hessenberg form.

Opened an issue #463 where hopefully we can discuss the general approach to take since this impacts almost every model

lukelowry · 2026-06-26T12:48:23Z

I have rebased and adjusted the formulation to align with #463 .

nkoukpaizan

I have a few comments here. Perhaps worth discussing at our next meeting.

nkoukpaizan · 2026-06-28T22:05:05Z

-        tag_.resize(size);
-        abs_tol_.resize(size);
+
+        f_.assign(size, ScalarT{0});


resize makes more sense to me in the allocate method. Initialization occurs later.

nkoukpaizan · 2026-06-28T22:08:22Z

+        };
+
+        std::fill(tag_.begin(), tag_.end(), false);
+        tag_[index(IeeestInternalVariables::X1)] = true;


This is a lot less readable to me than the previous implementation.

nkoukpaizan · 2026-06-28T22:17:50Z

          {
-            std::cout << "Non-zero residual at index " << i << ": " << f[i] << "\n";
-            success = false;
+            auto test_tol = (i == 11) ? loose_tol : tol_;


A comment would be helpful when changing tolerances.

nkoukpaizan · 2026-06-28T22:23:28Z

      {
+        const auto U = static_cast<size_t>(IeeestExternalVariables::U);
+
+        std::fill(ws_.begin(), ws_.end(), ZERO<RealT>);


I would argue std::fill is a overkill here. The size is 1.

nkoukpaizan · 2026-06-28T22:26:09Z

+        const auto U   = static_cast<size_t>(IeeestExternalVariables::U);
+
+        const ScalarT x1  = y[X1];
+        const ScalarT x2  = y[X2];


Same here, the indirection from the enum is less readable to me. We should discuss a sustainable way to use the enums.

nkoukpaizan · 2026-06-28T22:39:34Z

        using Variable = typename ModelDataT::MonitorableVariables;
-        monitor_->set(Variable::vss, [this]
-                      { return y_[11]; });
+        auto index     = [](IeeestInternalVariables variable)


I've seen this pattern a few times. Consider defining once if it is really needed. I would argue it's less readable.

nkoukpaizan · 2026-06-28T22:41:40Z

-  result += test.constructor();
-  result += test.zeroInitialResidual();


Why remove the constructor and the zeroInitialResidual tests?

nkoukpaizan · 2026-06-28T22:42:29Z

+#include <cstddef>
+#include <memory>
+#include <vector>


Pretty sure vector should already be included. Could you comment on the need for cstddef and memory?

nkoukpaizan · 2026-06-28T22:44:25Z

      Ieeest<scalar_type, index_type>::Ieeest()
      {
-        size_ = 12;
+        size_ = static_cast<IdxT>(IeeestInternalVariables::MAXIMUM);


I prefer the hard-coded size, but that's minor. Perhaps add an assert for the enum.

nkoukpaizan · 2026-06-28T22:46:20Z

+        const std::vector<ResidualCase> cases = {
+            {"baseline",
+             [](DataT&) {},
+             {0.19, 0.28, 0.37, 1.0975, 0.25, 0.24, -0.01, -0.42, -0.25, -0.31, 1.15, 0.0}},


This combination of std::vector and lambda functions is not very readable to me. Consider splitting.

lukelowry marked this pull request as ready for review June 22, 2026 18:43

lukelowry mentioned this pull request Jun 23, 2026

10k Bus Case #461

Draft

7 tasks

lukelowry force-pushed the lukel/ieeest-dev branch from 509506c to e2c07d8 Compare June 24, 2026 20:00

pelesh requested changes Jun 24, 2026

View reviewed changes

lukelowry force-pushed the lukel/ieeest-dev branch from e2c07d8 to bab57ad Compare June 24, 2026 22:11

pelesh mentioned this pull request Jun 25, 2026

Make PhasorDynamics models Hessenberg-ready #463

Open

lukelowry force-pushed the lukel/ieeest-dev branch 2 times, most recently from 8bbbad6 to 090289b Compare June 26, 2026 11:02

lukelowry force-pushed the lukel/ieeest-dev branch from 755ee20 to 282fc1d Compare June 26, 2026 21:59

nkoukpaizan reviewed Jun 28, 2026

View reviewed changes

lukelowry added 4 commits July 1, 2026 00:14

Fix bad parameter initialization and polish docs

0d274da

Update Docs

7b0cdeb

isEqual change and tidy

e15d613

Hessenberg form

579b3c1

lukelowry force-pushed the lukel/ieeest-dev branch from 282fc1d to 579b3c1 Compare July 1, 2026 05:17

		result += test.constructor();
		result += test.zeroInitialResidual();

Uh oh!

Conversation

lukelowry commented Jun 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Proposed changes

Checklist

Further comments

Uh oh!

lukelowry commented Jun 22, 2026

Uh oh!

pelesh left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lukelowry commented Jun 26, 2026

Uh oh!

nkoukpaizan left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

lukelowry commented Jun 22, 2026 •

edited

Loading