| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Rebuilt for RAMSES 3.83 (was 3.82), URAMSES 3.83 (was 3.82).
| 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 |
| 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 | — |
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 stallThe 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.
stepss.jar — SHA-256 63e596d19462ffcf8d28eeee01baf1318bd4754f42b32f5cfc733e04f5e44d67
Changes to STEPSS itself. The bundled components are unchanged since v3.81.2.
| 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 | — |
| 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 | — |
stepss.jar — SHA-256 b58f9e71bdd73b3c4ba7c983aa6a4d37d6b4157f076d0f13e9afe9da45a002ad
Changes to STEPSS itself. The bundled components are unchanged since v3.81.1.
| 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 | — |
| 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 | — |
stepss.jar — SHA-256 c028affdbd14b836a90ae6070d0a6804550b8b1e63dc437140eac9c97161198c
Changes to STEPSS itself. The bundled components are unchanged since v3.81.
| 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 | — |
| 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 | — |
stepss.jar — SHA-256 8868f5a9982fab052ebed6d6c30e0f6251ea2a02e6b861512e262595ccc8324a
Rebuilt for RAMSES 3.81 (was 3.80), URAMSES 3.81 (was 3.80).
| 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 |
| 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 | — |
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.
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.
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.
stepss.jar — SHA-256 1823bdb9f39be5e2e9c6c10aa853b4b7f9e575c1d552f2c145c6d36af56b7fcd
Changes to STEPSS itself. The bundled components are unchanged since v3.80.
| 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 | — |
| 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 | — |
stepss.jar — SHA-256 d7d2f3007b45333957e232612834181980bc42878221787560d824cbba8410a7
Rebuilt for RAMSES 3.80 (was 3.79), URAMSES 3.80 (was 3.79).
| 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 |
| 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 | — |
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.
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.
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.
Unchanged. All three small-signal files keep their v2 banners and still carry
every mode.
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.
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.
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.
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.
Unchanged. All three small-signal files keep their v2 banners and still carry
every mode.
stepss.jar — SHA-256 55e159025f37a7f042f170916b2231c3b8a3e47b043221ddc09a2f8b83dbfe7d
Changes to STEPSS itself. The bundled components are unchanged since v3.79.
| 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 | — |
| 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 | — |
stepss.jar — SHA-256 527299290cc863742cb0d7f5abce7a9bf0543d3f9b2e029c30fa64a31bc12d2d
Rebuilt for RAMSES 3.79 (was 3.78), URAMSES 3.79 (was 3.78).
| 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 |
| 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 | — |
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.
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.
$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.
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.
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 modeThe 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.
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.
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.
$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.
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.
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.
stepss.jar — SHA-256 9bd1e2bb464539ea34b9fff7d1aa357b7464d4cf8833c4165b35aa4b1208a749
Rebuilt for CODEGEN 5.3 (was 5.2.0).
| 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 | — |
| 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 | — |
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.
stepss.jar — SHA-256 6fd0ff30831db05593a0e9ecb11dbfc3df3d6e94a198c6e517889fdee7defd01
| Back | FazBrowse Home | New Git URL |