FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

Releases · SPS-L/stepss-java-ui · GitHub

Repository navigation

Releases: SPS-L/stepss-java-ui

STEPSS v3.83

Choose a tag to compare

Filter
apetros released this 29 Sep 14:38

STEPSS v3.83

Rebuilt for RAMSES 3.83 (was 3.82), URAMSES 3.83 (was 3.82).

Bundled components

Component Version Upstream release Published
RAMSES 3.83 v3.83 2026-09-29
Helios 1.5.0 v1.5.0 —
DYNGRAPH 1.4.0 v1.4.0 —
CODEGEN 5.4 v5.4 —
URAMSES 3.83 v3.83 2026-09-29

Bundled examples

Example Version Upstream release Refreshed
Kundur two-area 1.4.0 v1.4.0 —
IEEE Nordic 1.3.0 v1.3.0 —
5-bus tutorial 1.2.0 v1.2.0 —
6-bus microgrid 1.1.0 v1.1.0 —

Upstream release notes

RAMSES v3.83 — v3.83 - grid-following converters at zero reactive power no longer stall

Grid-following converters (INJEC GFOL) dispatched at zero reactive power no longer stall the simulation after a disturbance.

The limit on the direct-axis current, Idmax, took the converter's maximum current Imax as its upper bound. Its input is sqrt(Imax² − iq²), which equals Imax exactly when the converter carries no reactive current, so at unity power factor the signal rested on its own bound. The limiter then switched in and out on every time step, driven by solver noise alone. On a network with many such converters this produced hundreds of thousands of discrete events, very short time steps, and a trajectory that changed with the Newton tolerance.

The bound now sits one convergence tolerance above Imax. It still catches a genuine numerical overshoot, but noise can no longer trip it. On the European WAMCES test system (500 grid-following converters at zero dispatch), a 2.4 s run with a 1000 MW load step goes from 844 time steps and 80 s to 124 time steps and 2.6 s, with no limiter events, and gives the same trajectory at Newton tolerances of 1e-4 and 1e-6.

Setting the rate-limiter time constant Trlim below 0.001 s, which is meant to disable that limiter, now works. It previously overwrote Imax itself with the largest representable number, so the saturation-circle calculation overflowed and the run stopped before its first time step.

No data file changes are needed, and no other model is affected.

URAMSES v3.83 — v3.83 - grid-following converters at zero reactive power no longer stall

Toolchain and kit provenance

The modules_*/ directories in this release ship pre-compiled RAMSES
libraries and .mod files. They are committed to the repository, so the
Source code archive below (or a clone checked out at this tag) is the
whole release; there are no separate kit downloads to fetch and unpack.

A .mod file can only be read by the gfortran generation that wrote it, so
to add your own Fortran models you need a compiler emitting the same module
ABI version as your platform's kit. make -f <makefile> check-deps verifies
this before building.

Makefile Kit directory Built with .mod ABI Target Runtime floor
build/Makefile.linux modules_l GNU Fortran (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0 15 x86_64-linux-gnu ldd (Ubuntu GLIBC 2.39-0ubuntu8.9) 2.39
build/Makefile.macos modules_m GNU Fortran (Homebrew GCC 16.2.0) 16.2.0 16 aarch64-apple-darwin24 macOS 15.7.9 arm64; needs brew install gcc openblas
build/Makefile.windows modules_wg GNU Fortran (Rev4, Built by MSYS2 project) 16.2.0 16 x86_64-w64-mingw32 static - self-contained, no MSYS2 runtime required

Exact compile flags, BLAS build and RAMSES commit for each kit are recorded in
that kit's BUILDINFO.txt, for example modules_l/BUILDINFO.txt.

The Windows/Intel kit in modules_wi/ (used by build/msvs/URAMSES.sln) is
not refreshed by this release: no CI produces Intel-format modules. See
modules_wi/BUILDINFO.txt for what it was last built from.


Grid-following converters (INJEC GFOL) dispatched at zero reactive power no longer stall the simulation after a disturbance.

The limit on the direct-axis current, Idmax, took the converter's maximum current Imax as its upper bound. Its input is sqrt(Imax² − iq²), which equals Imax exactly when the converter carries no reactive current, so at unity power factor the signal rested on its own bound. The limiter then switched in and out on every time step, driven by solver noise alone. On a network with many such converters this produced hundreds of thousands of discrete events, very short time steps, and a trajectory that changed with the Newton tolerance.

The bound now sits one convergence tolerance above Imax. It still catches a genuine numerical overshoot, but noise can no longer trip it. On the European WAMCES test system (500 grid-following converters at zero dispatch), a 2.4 s run with a 1000 MW load step goes from 844 time steps and 80 s to 124 time steps and 2.6 s, with no limiter events, and gives the same trajectory at Newton tolerances of 1e-4 and 1e-6.

Setting the rate-limiter time constant Trlim below 0.001 s, which is meant to disable that limiter, now works. It previously overwrote Imax itself with the largest representable number, so the saturation-circle calculation overflowed and the run stopped before its first time step.

No data file changes are needed, and no other model is affected.

Artifact

stepss.jar — SHA-256 63e596d19462ffcf8d28eeee01baf1318bd4754f42b32f5cfc733e04f5e44d67

STEPSS v3.82

Choose a tag to compare

Filter
apetros released this 22 Sep 21:09

STEPSS v3.82

Changes to STEPSS itself. The bundled components are unchanged since v3.81.2.

Changes in this release

  • Sign the Mach-O binaries that travel inside the jars
  • Keep the signing keychain alive for the length of the build
  • Pin the mac bundle identifier at the value the field already carries
  • Release: sign the app image and notarize the .dmg
  • Record the jpackage macOS signing options on the JDK 21 runner
  • Re-pin the Kundur example at v1.3.0

Bundled components

Component Version Upstream release Published
RAMSES 3.82 v3.82 —
Helios 1.5.0 v1.5.0 —
DYNGRAPH 1.4.0 v1.4.0 —
CODEGEN 5.4 v5.4 —
URAMSES 3.82 v3.82 —

Bundled examples

Example Version Upstream release Refreshed
Kundur two-area 1.4.0 v1.4.0 —
IEEE Nordic 1.3.0 v1.3.0 —
5-bus tutorial 1.2.0 v1.2.0 —
6-bus microgrid 1.1.0 v1.1.0 —

Artifact

stepss.jar — SHA-256 b58f9e71bdd73b3c4ba7c983aa6a4d37d6b4157f076d0f13e9afe9da45a002ad

STEPSS v3.81.2

Choose a tag to compare

Filter
apetros released this 23 Aug 18:52

STEPSS v3.81.2

Changes to STEPSS itself. The bundled components are unchanged since v3.81.1.

Changes in this release

  • Clean break: no legacy support anywhere
  • Re-pin kundur v1.2.1; note that LEGACY_CFG is now the only copy

Bundled components

Component Version Upstream release Published
RAMSES 3.81 v3.81 —
Helios 1.4.1 v1.4.1 —
DYNGRAPH 1.3.0 v1.3.0 —
CODEGEN 5.3 v5.3 —
URAMSES 3.81 v3.81 —

Bundled examples

Example Version Upstream release Refreshed
Kundur two-area 1.2.1 v1.2.1 —
IEEE Nordic 1.3.0 v1.3.0 —
5-bus tutorial 1.2.0 v1.2.0 —
6-bus microgrid 1.1.0 v1.1.0 —

Artifact

stepss.jar — SHA-256 c028affdbd14b836a90ae6070d0a6804550b8b1e63dc437140eac9c97161198c

STEPSS v3.81.1

Choose a tag to compare

Filter
apetros released this 23 Aug 09:53

STEPSS v3.81.1

Changes to STEPSS itself. The bundled components are unchanged since v3.81.

Changes in this release

  • record.dump becomes record.init; Open Examples loads the shipped .cfg
  • Merge branch 'remove-open-in-editor'
  • Merge branch 'main' of github.com:SPS-L/stepss-java-ui
  • Merge branch 'dyngraph-output': DYNGRAPH reports into the Analysis console, Tools loses five items

Bundled components

Component Version Upstream release Published
RAMSES 3.81 v3.81 —
Helios 1.4.1 v1.4.1 —
DYNGRAPH 1.3.0 v1.3.0 —
CODEGEN 5.3 v5.3 —
URAMSES 3.81 v3.81 —

Bundled examples

Example Version Upstream release Refreshed
Kundur two-area 1.2.0 v1.2.0 —
IEEE Nordic 1.3.0 v1.3.0 —
5-bus tutorial 1.2.0 v1.2.0 —
6-bus microgrid 1.1.0 v1.1.0 —

Artifact

stepss.jar — SHA-256 8868f5a9982fab052ebed6d6c30e0f6251ea2a02e6b861512e262595ccc8324a

STEPSS v3.81

Choose a tag to compare

Filter
apetros released this 22 Aug 09:48

STEPSS v3.81

Rebuilt for RAMSES 3.81 (was 3.80), URAMSES 3.81 (was 3.80).

Changes in this release

  • Merge branch 'main' of github.com:SPS-L/stepss-java-ui
  • Merge branch 'ssa-output-pane': the Analysis tab gets its own engine console

Bundled components

Component Version Upstream release Published
RAMSES 3.81 v3.81 2026-08-22
Helios 1.4.1 v1.4.1 —
DYNGRAPH 1.3.0 v1.3.0 —
CODEGEN 5.3 v5.3 —
URAMSES 3.81 v3.81 2026-08-22

Bundled examples

Example Version Upstream release Refreshed
Kundur two-area 1.1.0 v1.1.0 —
IEEE Nordic 1.2.0 v1.2.0 —
5-bus tutorial 1.1.0 v1.1.0 —
6-bus microgrid 1.0.0 v1.0.0 —

Upstream release notes

RAMSES v3.81 — v3.81 - a clearer answer when the eigensolve refuses

Small-signal analysis: a clearer answer when the eigensolve refuses

A message-only release. Nothing about the engine's numerical behaviour
changes, no results file changes, and no data file needs editing.

solve_state_matrix reported both kinds of LAPACK failure with one sentence:

the dense eigensolve failed, dgeev returned info =  -4
(positive: the QR iteration did not converge)

The parenthetical is true only when info is positive, and negative is the
case a reader is more likely to meet. The two are now reported separately.

Positive keeps the convergence wording and names the eigenvalues affected,
rather than leaving you to look up what info means.

Negative says LAPACK rejected an argument, spells out which one, and
points at the XERBLA lines LAPACK has already printed above, which name the
internal routine that refused. It also names the cause you would otherwise
never guess: a NaN or Inf anywhere in the state matrix surfaces through
the illegal-argument channel and never mentions a NaN. A single bad entry in
a 4x4 matrix produces the whole cascade:

** On entry to DGEBAL parameter number  3 had an illegal value
** On entry to DGEHRD parameter number  2 had an illegal value
** On entry to DORGHR parameter number  2 had an illegal value
** On entry to DHSEQR parameter number  4 had an illegal value
dgeev info: -4

DGEBAL finds the non-finite entry while balancing and refuses through
XERBLA. It leaves ILO and IHI unset when it does, so the three routines
after it each fail on those instead: four messages, one cause.

This is the other half of the zero-time-constant fix in 3.80. Since that
release the engine no longer produces a non-finite state matrix, so nothing
in it can reach this path today; the next case that does deserves better than
a wrong sentence.

URAMSES v3.81 — v3.81 - a clearer answer when the eigensolve refuses

Toolchain and kit provenance

The modules_*/ directories in this release ship pre-compiled RAMSES
libraries and .mod files. They are committed to the repository, so the
Source code archive below (or a clone checked out at this tag) is the
whole release; there are no separate kit downloads to fetch and unpack.

A .mod file can only be read by the gfortran generation that wrote it, so
to add your own Fortran models you need a compiler emitting the same module
ABI version as your platform's kit. make -f <makefile> check-deps verifies
this before building.

Makefile Kit directory Built with .mod ABI Target Runtime floor
build/Makefile.linux modules_l GNU Fortran (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0 15 x86_64-linux-gnu ldd (Ubuntu GLIBC 2.39-0ubuntu8.8) 2.39
build/Makefile.macos modules_m GNU Fortran (Homebrew GCC 16.1.0) 16.1.0 16 aarch64-apple-darwin24 macOS 15.7.7 arm64; needs brew install gcc openblas
build/Makefile.windows modules_wg GNU Fortran (Rev5, Built by MSYS2 project) 16.1.0 16 x86_64-w64-mingw32 static - self-contained, no MSYS2 runtime required

Exact compile flags, BLAS build and RAMSES commit for each kit are recorded in
that kit's BUILDINFO.txt, for example modules_l/BUILDINFO.txt.

The Windows/Intel kit in modules_wi/ (used by build/msvs/URAMSES.sln) is
not refreshed by this release: no CI produces Intel-format modules. See
modules_wi/BUILDINFO.txt for what it was last built from.


Small-signal analysis: a clearer answer when the eigensolve refuses

A message-only release. Nothing about the engine's numerical behaviour
changes, no results file changes, and no data file needs editing.

solve_state_matrix reported both kinds of LAPACK failure with one sentence:

the dense eigensolve failed, dgeev returned info =  -4
(positive: the QR iteration did not converge)

The parenthetical is true only when info is positive, and negative is the
case a reader is more likely to meet. The two are now reported separately.

Positive keeps the convergence wording and names the eigenvalues affected,
rather than leaving you to look up what info means.

Negative says LAPACK rejected an argument, spells out which one, and
points at the XERBLA lines LAPACK has already printed above, which name the
internal routine that refused. It also names the cause you would otherwise
never guess: a NaN or Inf anywhere in the state matrix surfaces through
the illegal-argument channel and never mentions a NaN. A single bad entry in
a 4x4 matrix produces the whole cascade:

** On entry to DGEBAL parameter number  3 had an illegal value
** On entry to DGEHRD parameter number  2 had an illegal value
** On entry to DORGHR parameter number  2 had an illegal value
** On entry to DHSEQR parameter number  4 had an illegal value
dgeev info: -4

DGEBAL finds the non-finite entry while balancing and refuses through
XERBLA. It leaves ILO and IHI unset when it does, so the three routines
after it each fail on those instead: four messages, one cause.

This is the other half of the zero-time-constant fix in 3.80. Since that
release the engine no longer produces a non-finite state matrix, so nothing
in it can reach this path today; the next case that does deserves better than
a wrong sentence.

Artifact

stepss.jar — SHA-256 1823bdb9f39be5e2e9c6c10aa853b4b7f9e575c1d552f2c145c6d36af56b7fcd

STEPSS v3.80.1

Choose a tag to compare

Filter
apetros released this 22 Aug 07:50

STEPSS v3.80.1

Changes to STEPSS itself. The bundled components are unchanged since v3.80.

Changes in this release

  • SSA plot: one adjustable damping ray, and the origin always in view

Bundled components

Component Version Upstream release Published
RAMSES 3.80 v3.80 —
Helios 1.4.1 v1.4.1 —
DYNGRAPH 1.3.0 v1.3.0 —
CODEGEN 5.3 v5.3 —
URAMSES 3.80 v3.80 —

Bundled examples

Example Version Upstream release Refreshed
Kundur two-area 1.1.0 v1.1.0 —
IEEE Nordic 1.2.0 v1.2.0 —
5-bus tutorial 1.1.0 v1.1.0 —
6-bus microgrid 1.0.0 v1.0.0 —

Artifact

stepss.jar — SHA-256 d7d2f3007b45333957e232612834181980bc42878221787560d824cbba8410a7

STEPSS v3.80

Choose a tag to compare

Filter
apetros released this 22 Aug 00:18

STEPSS v3.80

Rebuilt for RAMSES 3.80 (was 3.79), URAMSES 3.80 (was 3.79).

Bundled components

Component Version Upstream release Published
RAMSES 3.80 v3.80 2026-08-22
Helios 1.4.1 v1.4.1 —
DYNGRAPH 1.3.0 v1.3.0 —
CODEGEN 5.3 v5.3 —
URAMSES 3.80 v3.80 2026-08-22

Bundled examples

Example Version Upstream release Refreshed
Kundur two-area 1.1.0 v1.1.0 —
IEEE Nordic 1.2.0 v1.2.0 —
5-bus tutorial 1.1.0 v1.1.0 —
6-bus microgrid 1.0.0 v1.0.0 —

Upstream release notes

RAMSES v3.80 — v3.80 - a zero time constant is a constraint, not a state

Small-signal analysis: a zero time constant is a constraint, not a state

Device equations are held in the form tc * dx/dt = f(x, y). A tc of exactly
zero makes that the algebraic constraint f(x, y) = 0, with no state behind
it. TR = 0 in an AVR record is how a great deal of real AVR data is written,
so this is ordinary input rather than an edge case.

Small-signal analysis used to decide that such a row was differential and then
divide it by its own time constant, which put Inf and NaN across the whole
row. LAPACK refused the state matrix and reported the NaN through the only
channel it has for it:

** On entry to DGEBAL parameter number  3 had an illegal value

That reads like a calling bug and is not one: argument 3 is the matrix itself.
DGEBAL also leaves ILO and IHI unset when it bails out, so DGEHRD,
DORGHR and DHSEQR each fail after it, and all four messages have a single
cause.

Such an equation is now treated as the algebraic constraint it is, which is
what the time-domain solver has always done with it: the solver multiplies by
the time constant when it algebraizes, so a zero one simply drops the
derivative term.

What changes for you

  • Cases that failed the eigensolve with the DGEBAL message now run.

  • The state count can be smaller than the number of equations that name a
    state
    , and each analysis says so once, for example:

    Small-signal analysis: 7 equation(s) carry a zero time constant and are treated
    as algebraic constraints, as the time-domain solver treats them; 280 states
    remain.
    

    Those variables were never states. They are algebraically slaved to their
    inputs, and the modes that vanish with them are modes the system does not
    have.

  • In <basename>_eqs.dat, an affected row is now labelled a rather than d
    with a state column of 0. That file and the state count now agree with each
    other, which they did not before.

  • A time constant that is small but nonzero is unaffected. It remains an
    ordinary fast state and stays in the spectrum. The test is against exactly
    zero, because that is where the solver's own behaviour changes.

No time-domain change

The row scaling this corrects is reached only from the Jacobian assembly that
the JAC and EIG paths use, so no simulated trajectory moves. The Nordic
regression trajectory is bit-identical to the previous release.

Results file formats

Unchanged. All three small-signal files keep their v2 banners and still carry
every mode.

URAMSES v3.80 — v3.80 - a zero time constant is a constraint, not a state

Toolchain and kit provenance

The modules_*/ directories in this release ship pre-compiled RAMSES
libraries and .mod files. They are committed to the repository, so the
Source code archive below (or a clone checked out at this tag) is the
whole release; there are no separate kit downloads to fetch and unpack.

A .mod file can only be read by the gfortran generation that wrote it, so
to add your own Fortran models you need a compiler emitting the same module
ABI version as your platform's kit. make -f <makefile> check-deps verifies
this before building.

Makefile Kit directory Built with .mod ABI Target Runtime floor
build/Makefile.linux modules_l GNU Fortran (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0 15 x86_64-linux-gnu ldd (Ubuntu GLIBC 2.39-0ubuntu8.8) 2.39
build/Makefile.macos modules_m GNU Fortran (Homebrew GCC 16.1.0) 16.1.0 16 aarch64-apple-darwin24 macOS 15.7.7 arm64; needs brew install gcc openblas
build/Makefile.windows modules_wg GNU Fortran (Rev5, Built by MSYS2 project) 16.1.0 16 x86_64-w64-mingw32 static - self-contained, no MSYS2 runtime required

Exact compile flags, BLAS build and RAMSES commit for each kit are recorded in
that kit's BUILDINFO.txt, for example modules_l/BUILDINFO.txt.

The Windows/Intel kit in modules_wi/ (used by build/msvs/URAMSES.sln) is
not refreshed by this release: no CI produces Intel-format modules. See
modules_wi/BUILDINFO.txt for what it was last built from.


Small-signal analysis: a zero time constant is a constraint, not a state

Device equations are held in the form tc * dx/dt = f(x, y). A tc of exactly
zero makes that the algebraic constraint f(x, y) = 0, with no state behind
it. TR = 0 in an AVR record is how a great deal of real AVR data is written,
so this is ordinary input rather than an edge case.

Small-signal analysis used to decide that such a row was differential and then
divide it by its own time constant, which put Inf and NaN across the whole
row. LAPACK refused the state matrix and reported the NaN through the only
channel it has for it:

** On entry to DGEBAL parameter number  3 had an illegal value

That reads like a calling bug and is not one: argument 3 is the matrix itself.
DGEBAL also leaves ILO and IHI unset when it bails out, so DGEHRD,
DORGHR and DHSEQR each fail after it, and all four messages have a single
cause.

Such an equation is now treated as the algebraic constraint it is, which is
what the time-domain solver has always done with it: the solver multiplies by
the time constant when it algebraizes, so a zero one simply drops the
derivative term.

What changes for you

  • Cases that failed the eigensolve with the DGEBAL message now run.

  • The state count can be smaller than the number of equations that name a
    state
    , and each analysis says so once, for example:

    Small-signal analysis: 7 equation(s) carry a zero time constant and are treated
    as algebraic constraints, as the time-domain solver treats them; 280 states
    remain.
    

    Those variables were never states. They are algebraically slaved to their
    inputs, and the modes that vanish with them are modes the system does not
    have.

  • In <basename>_eqs.dat, an affected row is now labelled a rather than d
    with a state column of 0. That file and the state count now agree with each
    other, which they did not before.

  • A time constant that is small but nonzero is unaffected. It remains an
    ordinary fast state and stays in the spectrum. The test is against exactly
    zero, because that is where the solver's own behaviour changes.

No time-domain change

The row scaling this corrects is reached only from the Jacobian assembly that
the JAC and EIG paths use, so no simulated trajectory moves. The Nordic
regression trajectory is bit-identical to the previous release.

Results file formats

Unchanged. All three small-signal files keep their v2 banners and still carry
every mode.

Artifact

stepss.jar — SHA-256 55e159025f37a7f042f170916b2231c3b8a3e47b043221ddc09a2f8b83dbfe7d

STEPSS v3.79.1

Choose a tag to compare

Filter
apetros released this 21 Aug 22:09

STEPSS v3.79.1

Changes to STEPSS itself. The bundled components are unchanged since v3.79.

Changes in this release

  • Start every launch empty, and never show an earlier run's modes
  • Put the banner's message on one line with the spaces still in it

Bundled components

Component Version Upstream release Published
RAMSES 3.79 v3.79 —
Helios 1.4.1 v1.4.1 —
DYNGRAPH 1.3.0 v1.3.0 —
CODEGEN 5.3 v5.3 —
URAMSES 3.79 v3.79 —

Bundled examples

Example Version Upstream release Refreshed
Kundur two-area 1.1.0 v1.1.0 —
IEEE Nordic 1.2.0 v1.2.0 —
5-bus tutorial 1.1.0 v1.1.0 —
6-bus microgrid 1.0.0 v1.0.0 —

Artifact

stepss.jar — SHA-256 527299290cc863742cb0d7f5abce7a9bf0543d3f9b2e029c30fa64a31bc12d2d

STEPSS v3.79

Choose a tag to compare

Filter
apetros released this 21 Aug 20:43

STEPSS v3.79

Rebuilt for RAMSES 3.79 (was 3.78), URAMSES 3.79 (was 3.78).

Changes in this release

  • SSA results: filter and zoom the run you already have (#21)

Bundled components

Component Version Upstream release Published
RAMSES 3.79 v3.79 2026-08-21
Helios 1.4.1 v1.4.1 —
DYNGRAPH 1.3.0 v1.3.0 —
CODEGEN 5.3 v5.3 —
URAMSES 3.79 v3.79 2026-08-21

Bundled examples

Example Version Upstream release Refreshed
Kundur two-area 1.1.0 v1.1.0 —
IEEE Nordic 1.2.0 v1.2.0 —
5-bus tutorial 1.1.0 v1.1.0 —
6-bus microgrid 1.0.0 v1.0.0 —

Upstream release notes

RAMSES v3.79 — v3.79 - small-signal results carry every mode

Breaking: EIG takes a basename and nothing else

EIG used to accept an optional real_limit and pf_threshold pair. Both are gone, and a record still carrying either is refused (exit 78) rather than having it ignored. The values changed what the previous engine wrote, so accepting one silently would produce a results set that looks entirely normal and answers a different question.

1.000 EIG 'ssa'                 # the whole grammar
1.000 EIG 'ssa' -1.0 0.05       # refused

Existing .dst files need the parameters removed. A run that wants the old participation floor writes $PF_THRES 0.05 ; in its solver settings.

Why

real_limit did two contradictory jobs: it gated <base>_pf.dat and <base>_ms.dat, and it labelled rows in <base>_modes.dat. So a mode a reader could see in the modes file had no participation behind it and no mode shape, and no way to obtain either short of running the case again. Reported by Thierry Van Cutsem against the interface (#21); the inconsistency underneath it is the reason.

All three files now carry every mode. Which of them are worth reading is decided when the results are read, and both interfaces filter live against the full set, so changing a limit re-filters what is already on screen.

New: $PF_THRES

$PF_THRES 0.001 ;

Floor below which a participation entry is not written, default 1e-3. It sits with the solver settings beside $EIG_MAX_STATES because it is the same kind of thing: a guard on what the analysis costs, not a parameter of it. Participation is the one output quadratic in the state count (one row per mode-state pair, so 25 million rows and roughly 2 GB at the $EIG_MAX_STATES ceiling unfloored). No mode can be emptied by it for any value below 1, because each mode's column is normalised so its largest entry is exactly 1. Recorded as pf_floor in the modes header.

File format v2

All three banners move to v2.

v1 v2
_modes.dat columns index re im zeta freq_hz dom smp index re im zeta freq_hz smp
_modes.dat header real_limit, pf_threshold pf_floor
_pf.dat dominant modes only every mode
_ms.dat dominant modes only every mode

Check the banner if you read these positionally. The retired dom column sat exactly where smp sits now, at the same width, so reading a v2 file as a v1 does not fail: it reports the simplicity flag as the dominance flag and reads smp off the end of the line.

Also

The banner no longer calls itself a "Full" or "Limited" version. That word was chosen from mxbus, a compile-time array bound that is 50000 in every build, so it always said "Full" whether or not a $LICENSE record was present, and it could not have been fixed in place either since print_info runs before any settings have been read. Enforcement is unchanged.

The Kundur physics is unchanged: zeta -0.0233 without PSS, +0.1087 with.

URAMSES v3.79 — v3.79 - small-signal results carry every mode

Toolchain and kit provenance

The modules_*/ directories in this release ship pre-compiled RAMSES
libraries and .mod files. They are committed to the repository, so the
Source code archive below (or a clone checked out at this tag) is the
whole release; there are no separate kit downloads to fetch and unpack.

A .mod file can only be read by the gfortran generation that wrote it, so
to add your own Fortran models you need a compiler emitting the same module
ABI version as your platform's kit. make -f <makefile> check-deps verifies
this before building.

Makefile Kit directory Built with .mod ABI Target Runtime floor
build/Makefile.linux modules_l GNU Fortran (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0 15 x86_64-linux-gnu ldd (Ubuntu GLIBC 2.39-0ubuntu8.8) 2.39
build/Makefile.macos modules_m GNU Fortran (Homebrew GCC 16.1.0) 16.1.0 16 aarch64-apple-darwin24 macOS 15.7.7 arm64; needs brew install gcc openblas
build/Makefile.windows modules_wg GNU Fortran (Rev5, Built by MSYS2 project) 16.1.0 16 x86_64-w64-mingw32 static - self-contained, no MSYS2 runtime required

Exact compile flags, BLAS build and RAMSES commit for each kit are recorded in
that kit's BUILDINFO.txt, for example modules_l/BUILDINFO.txt.

The Windows/Intel kit in modules_wi/ (used by build/msvs/URAMSES.sln) is
not refreshed by this release: no CI produces Intel-format modules. See
modules_wi/BUILDINFO.txt for what it was last built from.


Breaking: EIG takes a basename and nothing else

EIG used to accept an optional real_limit and pf_threshold pair. Both are gone, and a record still carrying either is refused (exit 78) rather than having it ignored. The values changed what the previous engine wrote, so accepting one silently would produce a results set that looks entirely normal and answers a different question.

1.000 EIG 'ssa'                 # the whole grammar
1.000 EIG 'ssa' -1.0 0.05       # refused

Existing .dst files need the parameters removed. A run that wants the old participation floor writes $PF_THRES 0.05 ; in its solver settings.

Why

real_limit did two contradictory jobs: it gated <base>_pf.dat and <base>_ms.dat, and it labelled rows in <base>_modes.dat. So a mode a reader could see in the modes file had no participation behind it and no mode shape, and no way to obtain either short of running the case again. Reported by Thierry Van Cutsem against the interface (#21); the inconsistency underneath it is the reason.

All three files now carry every mode. Which of them are worth reading is decided when the results are read, and both interfaces filter live against the full set, so changing a limit re-filters what is already on screen.

New: $PF_THRES

$PF_THRES 0.001 ;

Floor below which a participation entry is not written, default 1e-3. It sits with the solver settings beside $EIG_MAX_STATES because it is the same kind of thing: a guard on what the analysis costs, not a parameter of it. Participation is the one output quadratic in the state count (one row per mode-state pair, so 25 million rows and roughly 2 GB at the $EIG_MAX_STATES ceiling unfloored). No mode can be emptied by it for any value below 1, because each mode's column is normalised so its largest entry is exactly 1. Recorded as pf_floor in the modes header.

File format v2

All three banners move to v2.

v1 v2
_modes.dat columns index re im zeta freq_hz dom smp index re im zeta freq_hz smp
_modes.dat header real_limit, pf_threshold pf_floor
_pf.dat dominant modes only every mode
_ms.dat dominant modes only every mode

Check the banner if you read these positionally. The retired dom column sat exactly where smp sits now, at the same width, so reading a v2 file as a v1 does not fail: it reports the simplicity flag as the dominance flag and reads smp off the end of the line.

Also

The banner no longer calls itself a "Full" or "Limited" version. That word was chosen from mxbus, a compile-time array bound that is 50000 in every build, so it always said "Full" whether or not a $LICENSE record was present, and it could not have been fixed in place either since print_info runs before any settings have been read. Enforcement is unchanged.

The Kundur physics is unchanged: zeta -0.0233 without PSS, +0.1087 with.

Artifact

stepss.jar — SHA-256 9bd1e2bb464539ea34b9fff7d1aa357b7464d4cf8833c4165b35aa4b1208a749

STEPSS v3.78.5

Choose a tag to compare

Filter
apetros released this 21 Aug 10:16

STEPSS v3.78.5

Rebuilt for CODEGEN 5.3 (was 5.2.0).

Bundled components

Component Version Upstream release Published
RAMSES 3.78 v3.78 —
Helios 1.4.1 v1.4.1 —
DYNGRAPH 1.3.0 v1.3.0 —
CODEGEN 5.3 v5.3 2026-08-21
URAMSES 3.78 v3.78 —

Bundled examples

Example Version Upstream release Refreshed
Kundur two-area 1.1.0 v1.1.0 —
IEEE Nordic 1.2.0 v1.2.0 —
5-bus tutorial 1.1.0 v1.1.0 —
6-bus microgrid 1.0.0 v1.0.0 —

Upstream release notes

CODEGEN v5.3 — CODEGEN v5.3

No change to the code generator. This release normalises the version scheme and
wires CODEGEN into the two things that redistribute it.

Versions are now vX.Y, two components. v5.1.0 and v5.2.0 were X.Y.Z;
this matches stepss-ramses, whose releases have always been vX.Y.
tools/check_version_tag.sh rejects a three-component tag rather than assuming
one, because the number is a contract with a downstream that appends to it.

A release now reaches CODEGEN Studio as well as STEPSS. notify-cg-studio
joins notify-java-ui: stepss-cg-studio bundles these executables for all
three platforms in its PyPI wheel, so pip install stepss-cg-studio can run
the generator on a fresh install, and it derives its own version from this one.
CODEGEN 5.3 makes the next CODEGEN Studio release 5.3.0, and a change on its
Python side after that 5.3.1. A third component here would have produced a
four-component wheel.

The two notify jobs both depend on publish and deliberately not on each
other, so one downstream failing cannot silently skip the other.

Also in this release: the Hydro-Quebec exciters are dropped from the examples,
and STEPSS is told about a release rather than polling for one on a schedule.

Artifact

stepss.jar — SHA-256 6fd0ff30831db05593a0e9ecb11dbfc3df3d6e94a198c6e517889fdee7defd01


Back | FazBrowse Home | New Git URL