Skip to content

Fix 11261 floating point overflow in CalcEffectiveSHR#11288

Merged
mitchute merged 6 commits intoNatLabRockies:developfrom
bigladder:Fix-11261-Floating-point-overflow-in-CalcEffectiveSHR
Oct 23, 2025
Merged

Fix 11261 floating point overflow in CalcEffectiveSHR#11288
mitchute merged 6 commits intoNatLabRockies:developfrom
bigladder:Fix-11261-Floating-point-overflow-in-CalcEffectiveSHR

Conversation

@kevin-moos
Copy link
Contributor

Pull request overview

Description of the purpose of this PR

Fix floating point overflow due to passing of large values to std::exp and std::expm1. This was originally discovered in VariableSpeedCoils, but I found and updated similar code in other coils as well. The unit test is only for VariableSpeedCoils.

Pull Request Author

  • Title of PR should be user-synopsis style (clearly understandable in a standalone changelog context)
  • Label the PR with at least one of: Defect, Refactoring, NewFeature, Performance, and/or DoNoPublish
  • Pull requests that impact EnergyPlus code must also include unit tests to cover enhancement or defect repair
  • Author should provide a "walkthrough" of relevant code changes using a GitHub code review comment process
  • If any diffs are expected, author must demonstrate they are justified using plots and descriptions
  • If changes fix a defect, the fix should be demonstrated in plots and descriptions
  • If any defect files are updated to a more recent version, upload new versions here or on DevSupport
  • If IDD requires transition, transition source, rules, ExpandObjects, and IDFs must be updated, and add IDDChange label
  • If structural output changes, add to output rules file and add OutputChange label
  • If adding/removing any LaTeX docs or figures, update that document's CMakeLists file dependencies
  • If adding/removing any output files (e.g., eplustbl.*)
    • Update ..\scripts\Epl-run.bat
    • Update ..\scripts\RunEPlus.bat
    • Update ..\src\EPLaunch\ MainModule.bas, epl-ui.frm, and epl.vbp (VersionComments)
    • Update ...github\workflows\energyplus.py

Reviewer

  • Perform a Code Review on GitHub
  • If branch is behind develop, merge develop and build locally to check for side effects of the merge
  • If defect, verify by running develop branch and reproducing defect, then running PR and reproducing fix
  • If feature, test running new feature, try creative ways to break it
  • CI status: all green or justified
  • Check that performance is not impacted (CI Linux results include performance check)
  • Run Unit Test(s) locally
  • Check any new function arguments for performance impacts
  • Verify IDF naming conventions and styles, memos and notes and defaults
  • If new idf included, locally check the err file and other outputs

@mitchute mitchute added the Defect Includes code to repair a defect in EnergyPlus label Oct 23, 2025
@mitchute mitchute requested a review from rraustad October 23, 2025 20:29
@mitchute
Copy link
Collaborator

Looks reasonable.

Compiler explorer: https://godbolt.org/z/shfP4M3qE

@mitchute mitchute merged commit 7c065df into NatLabRockies:develop Oct 23, 2025
8 of 9 checks passed
@kevin-moos kevin-moos deleted the Fix-11261-Floating-point-overflow-in-CalcEffectiveSHR branch October 23, 2025 21:27
To2 = aa - Tcl * std::expm1(-To1 / Tcl);
// Floating overflow errors occur when -To1/Tcl is a large positive number.
// Cap upper limit at 700 to avoid the overflow errors.
To2 = aa - Tcl * std::expm1(min(700.0, -To1 / Tcl));
Copy link
Collaborator

@rraustad rraustad Oct 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kevin-moos are you seeing an overflow or underflow? I have seen this limit (-700) used but for an underflow condition here and here. Tcl is the latent time constant which is a positive number. How did this calculation result in a large positive number? We do protect against large positive exponents (just search for 700) but not for this type of calculation. Please clarify.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was an overflow. I noted in the issue that it only seems to happen when EnteringDB and EnteringWB are both negative (someone was testing cold climate heat pumps), so the sign is getting flipped somewhere along the way. I saw the fix for the underflow and used that as the basis for my change.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the fan operating as constant when this happens? The unit test shows cycling fan. The model is not supposed to be active during cycling fan.

// Real64 constexpr QLatRated = 197242.22114414035;
// Real64 constexpr QLatActual = 149769.74983225350;
// Real64 constexpr EnteringDB = -4.5144144221489846;
// Real64 constexpr EnteringWB = -4.5144119262695312;
Copy link
Collaborator

@rraustad rraustad Oct 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So maybe this is the clue. The coil turned on in winter? and caused a large positive exponent? I see cycling fan operating mode but the latent degradation model is only active for constant fan mode?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Defect Includes code to repair a defect in EnergyPlus

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Floating-point overflow in CalcEffectiveSHR for variable speed coil with negative entering temperatures

3 participants