Fix recuperator bisection bracket failure on wasm#64
Merged
Conversation
The bisection event handler mapped all SecondLawViolation errors to assume_positive. On wasm, CoolProp enthalpy round-trip noise at the lower bracket endpoint (t_out = t_in) can exceed the ENTHALPY_RELATIVE_ZERO threshold and produce a spurious wrong-direction heat flow. The handler then made both bracket endpoints positive, causing 'no sign change'. Now the handler checks whether t_out is near t_top_in. Near the inlet, the violation is FP noise (UA ≈ 0, negative residual). Farther away, it's a genuine overshoot (positive residual). Closes #63
gdtroszak
approved these changes
Mar 3, 2026
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Fixes the recuperator "invalid bracket: no sign change" error on wasm targets with segments > 1.
On wasm (strict IEEE 754, no x86 extended precision), CoolProp's enthalpy round-trip noise at the lower bracket boundary (
t_out = t_in) can exceed theENTHALPY_RELATIVE_ZEROthreshold from #59. When the noise produces a spurious wrong-direction heat flow, the resolve step emits aSecondLawViolation. The event handler was mapping all such violations toassume_positive— correct for genuine overshoots mid-iteration, but wrong at the zero-heat-transfer boundary where UA ≈ 0 and the residual should be negative. Both endpoints end up positive → bracket rejected.How
The event handler now checks whether the candidate
t_outis neart_top_in(within 1e-9 K). Near the inlet, aSecondLawViolationis FP noise →assume_negative. Farther away, it's a real overshoot →assume_positive.The
ENTHALPY_RELATIVE_ZEROthreshold is unchanged — it's still the first line of defense in the resolve step. The event handler is the fallback for when the thermo backend's noise exceeds it.Closes #63