-
Notifications
You must be signed in to change notification settings - Fork 19
Fix for Carnahan-Starling EOS with DensityFromPressureTemperature #563
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Yurlungur
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the fix! This looks like this is introducing test failures, but that might just be formatting changes. Can you run
make format_singularity-eosin the build directory? Hopefully that's why tests are failing. But we might need to make other changes to see. After tests pass on github, we'll also need to make sure they pass on LANL systems by triggering tests on re-git.
You should also add a changelog entry.
I currently don't have a way to run the clang formatting thing. I need to talk with Jeff more about this and see the best way to set this up. I also don't have access to run the re-git process either. But I'll go ahead and update the Changelog. Thank you. |
|
Ok Jeff or I can run the formatting and trigger the tests |
jhp-lanl
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, the gold standards for the test need to be updated (see test). Ideally we'd do something where we didn't need gold standards, but that's probably beyond the scope of this PR.
-------------------------------------------------------------------------------
Scenario: CarnahanStarling6
Given: Parameters for a CarnahanStarling EOS
Given: Pressure and temperature
When: A rho(P, T) lookup is performed
Then: The returned rho(P, T) should be equal to the true value
-------------------------------------------------------------------------------
/home/runner/work/singularity-eos/singularity-eos/test/test_eos_carnahan_starling.cpp:686
...............................................................................
/home/runner/work/singularity-eos/singularity-eos/test/eos_unit_test_helpers.hpp:82: FAILED:
CHECK( isClose(z[i], ztrue[i], tol) )
with expansion:
false
with message:
i: 1, Pressure: 3.44505000000000000e+07, Temperature: 1.53209999999999991e+
03, Value: 7.82907368899728694e-03, True Value: 7.82907368903815008e-03
/home/runner/work/singularity-eos/singularity-eos/test/eos_unit_test_helpers.hpp:82: FAILED:
CHECK( isClose(z[i], ztrue[i], tol) )
with expansion:
false
with message:
i: 2, Pressure: 6.78877500000000000e+07, Temperature: 2.76605000000000018e+
03, Value: 8.54539433273353993e-03, True Value: 8.54539433278823403e-03
===============================================================================
7d00fca to
9c04acc
Compare
|
@Yurlungur @jhp-lanl I think I've gotten everything fixed. Let me know if I need to change anything else. |
It doesn't look like this issue has been resolved. You can either change the tolerance in the unit test or change the value it finds. |
|
I tightened the root finder tolerance on regula falsi and ran formatting. Lets see if that resolves the failed tests. I also triggered the CI on re-git. |
Yurlungur
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. Thanks for the fix! Will only merge after @jhp-lanl also approves and tests pass.
|
Ok those too-tight tolerances cause the solver to fail. I just switched to a lower tolerance on the test, as clearly there's some jitter in the root that the finder finds across methods and other choices. |
|
Ah I think I found an underlying problem, which may have been the issue the hole time. If the upper bound of the root find depends on 1/bb, we cannot allow bb to be exactly zero. I modified the code to enforce strictly bb > 0 and modified the tests appropriately. |
Well, but |
jhp-lanl
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would add an early return for _bb == 0. Well, technically I suggested also taking into account very small values of _bb, but either way the spirit is the same.
| auto status = findRoot(poly, press, guess, lo_bound, hi_bound, xtol, ytol, real_root); | ||
| if (status != Status::SUCCESS) { | ||
| static constexpr Real rho_low = 0.; | ||
| const Real rho_high = robust::ratio(1.0, _bb); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If _bb == 0 then we can just use the ideal gas inversion
| const Real rho_high = robust::ratio(1.0, _bb); | |
| // Use ideal gas value when _bb is zero | |
| if (_bb <= std::numeric_limits<Real>::min()) { | |
| return press / (_Cv * _gm1 * temperature); | |
| } | |
| const Real rho_high = 1.0 / _bb; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that I got rid of the robust::ratio now that we have an explicit guarantee that _bb > 0 at this point in the code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we should rely on min. I think this should be a number slightly larger than the root finder tolerance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah okay, yeah that's a good suggestion
Co-authored-by: Jeff Peterson <83598606+jhp-lanl@users.noreply.github.com>
|
I am fine with that change but am not going to be able to debug this further today. You guys can push changes. Something is concerning with this system still IMO. Tests are passing locally for me but not in the CI. This suggests some low-level floating point issues that have not been tracked down. |
test/test_eos_carnahan_starling.cpp
Outdated
| } | ||
| array_compare(num, density, energy, h_pressure, pressure_true, "Density", | ||
| "Energy"); | ||
| "Energy", 1e-5); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the 1e-5 tolerance fine? It seems kind of big.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is kind of large, but it is about as large as I was seeing differences. If you run the tests locally yourself you can experiment and maybe find a tighter bound... or some other underlying reason why the tests are failing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can also update the gold values to the new values and keep a tighter tolerance
| const Real term1 = x * (1. + eta + eta * eta - eta * eta * eta); | ||
| const Real term2 = | ||
| press / (_Cv * _gm1 * temperature) * math_utils::pow<3>(1. - eta); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this numerically safe? We presumably want this to return something sensible for zero temperature but I think right now it will give NaN or infinity. You can and should replace the / by robust::ratio but you may also want to special case the low pressure limit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good point. So if we allow
|
Okay, sorry for all the issues. It started opening of the door to other bigger questions. The more fundamental question is how to define convergence criteria. But in any case, all the tests are passing, and I updated the tests to include a unit scaling (based on the reference state) on the epsilon for checking errors. Let me know if there are any other changes to do. |
Yurlungur
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems entirely sensible. Thanks for the careful digging and nice work @bgclayton-lanl !
@jhp-lanl or I will run formatting and trigger tests on re-git.
jhp-lanl
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One of the jobs failed, but I'm rerunning it
|
All tests pass now |
PR Summary
This fix corrects some of the fails with the analytic EOS tests regarding the Carnahan-Starling. Mainly it swaps our the root solver for the
regular_falsimethod. I haven't gone through the analysis to determine if the root is unique though. Maybe someone else has done this analysis before?PR Checklist
make formatcommand after configuring withcmake.If preparing for a new release, in addition please check the following:
when='@main'dependencies are updated to the release version in the package.py