[WIP] Updating Limiters for Finite Volume Formulation
Closes #28891
@freiler plase also take a look if you can
This are the current results on October 18, 2024
Upwind
Variartion Limited Second-Order Upwind:
Min-Mod:
VanLeer:
QUICK:
Venkatakrishnan:
Notes:
- Flux limiters are lagged in time step
- Deterioration in convergence is only observed for Venkatakrishnan (all the rest converge as upwind)
- QUICK does not show improvements with respect to upwind
To-do:
- [x] Modify the implicit vs explicit update in the limiters and select the best default option for each
- [x] Correct QUICK issues
- [x] Improve the documentation for all functions in limiters and MathFVUtils
- [x] Write updated documentation on limiters
- [x] Test limited advection schemes from two fronts
you'll want to get rid of the submodule update in the wasp folder
This are the latest results. Images are in the docs. Limiters are working as expected. Tests include:
- advection in a cartesian mesh in two directions (bottom-left to top-right and inverted)
- advection in a triangular mesh
- lid-driven cavity with Newton
- lid-driven cavity with SIMPLE
You can mention me once you're done pushing and I will review. Going to unsubscribe for now
We'll want to reduce the size of the tests. 25x25 for a full grid of tests is bloating the repo. You ll see it fail the same way with 5x5 but at (theoretically) 1/25th of the memory cost
Job Documentation, step Docs: sync website on fe27fcd wanted to post the following:
View the site here
This comment will be updated on new commits.
For the fvkernels/mms/advective-outflow.QUICKLimiter, which is supposed to test QUICK convergence with order $2 \pm 0.05$, we are converging with order 2.3. Does someone know rapidly what could be going on with this test or should I dig deeper into this?
Job Precheck, step Size check on 83e44c5 wanted to post the following:
Warning: This PR changes repo size by 5.28 MiB.
Job Coverage, step Generate coverage on fe27fcd wanted to post the following:
Framework coverage
| cedfd0 | #28892 fe27fc | ||||
|---|---|---|---|---|---|
| Total | Total | +/- | New | ||
| Rate | 85.14% | 85.13% | -0.01% | 79.57% | |
| Hits | 107658 | 107795 | +137 | 183 | |
| Misses | 18792 | 18824 | +32 | 47 | |
Modules coverage
Heat transfer
| cedfd0 | #28892 fe27fc | ||||
|---|---|---|---|---|---|
| Total | Total | +/- | New | ||
| Rate | 88.81% | 88.81% | - | 100.00% | |
| Hits | 4406 | 4406 | - | 1 | |
| Misses | 555 | 555 | - | 0 | |
Navier stokes
| cedfd0 | #28892 fe27fc | ||||
|---|---|---|---|---|---|
| Total | Total | +/- | New | ||
| Rate | 84.82% | 84.82% | +0.01% | 96.43% | |
| Hits | 17329 | 17350 | +21 | 54 | |
| Misses | 3102 | 3104 | +2 | 2 | |
Full coverage reports
Reports
-
framework -
chemical_reactions -
combined -
contact -
electromagnetics -
external_petsc_solver -
fluid_properties -
fsi -
functional_expansion_tools -
geochemistry -
heat_transfer -
level_set -
misc -
navier_stokes -
optimization -
peridynamics -
phase_field -
porous_flow -
ray_tracing -
rdg -
reactor -
richards -
scalar_transport -
solid_mechanics -
solid_properties -
stochastic_tools -
thermal_hydraulics -
xfem
Warnings
-
frameworknew line coverage rate 79.57% is less than the suggested 90.0%
This comment will be updated on new commits.
Numerical diffusivity seems to have improved a lot for SOU and Minmod. Quick and Ventakakrishnan seem to still be very diffusive. Do we expect this for these two? Is there something we can reference? Maybe this classic case has been studied with another code and those limiters in the litterature?
Numerical diffusivity seems to have improved a lot for SOU and Minmod. Quick and Ventakakrishnan seem to still be very diffusive. Do we expect this for these two? Is there something we can reference? Maybe this classic case has been studied with another code and those limiters in the litterature?
This assessment is not correct. Taking a screenshot of the comment above showing how numerical diffusivity behaves
so the figures in your first post are outdated? This one looks good across the board
No. They are not. What makes you think that? The tests are in a very corse mesh. The actual limiting tests are done for a finer mesh
because on your figure at the top of this thread, these two (Venta, QUICK) have results on that 2D case that look very much like 1st order upwind, while SOU, Vanleer and MinMod are very distinctly less numerically diffusive. Do we have MMS tests that check the order at this point?
because on your figure at the top of this thread, these two (Venta, QUICK) have results on that 2D case that look very much like 1st order upwind, while SOU, Vanleer and MinMod are very distinctly less numerically diffusive. Do we have MMS tests that check the order at this point?
Yes. It is in the tests (test/tests/fvkernels/mms). There is no need to test every single limiter though. Order of convergence is not related to dipersion
Job Precheck on c5dfb2c : invalidated by @grmnptr
Job Precheck on c5dfb2c : invalidated by @grmnptr
I dropped the submodule upodate and fixed (we will see based on the tests) some tests.
I also did the technical review on this PR yesterday. As part of that, I ran the tests manually and noticed a few things:
- When I try some of the limiters with
Steadyandprevious_nl_solution_required = trueon the dispersion tests it actually converges somehow but to the wrong results. I suggest throwing errors if somebody wants to use the limiters with Steady executioners. - The venkatakrishnan limiter doesn't seem to converge for the dispersion test on the rectangular grid (levels off at 1e-4ish), is this expected? This is the only test that has this limiter.
- None of the limiters converge for the dispersion test on the triangular mesh. They level off at around 1e-2 - 2e-2. When I refine the mesh (so use 150k elements in 2D instead of a few 10s) the behavior slightly improves, but still levels off at around 5e-4 - 1e-3. I tested the lid driven cavity example too with a triangular mesh and I found no convergence issues there (both SIMPLE and Transient converged to very low residuals even with higher Re numbers). I suppose this can be due to the discontinuity in the field, but would be nice to talk about this.
I remembered wrong, considering that I did not run bigger, more application-oriented problems, my review is not a technical review. Just observations based on the test cases.
Okay, I moved the limiter tests to the framework and added error messages for cases when the user selects steady executioners. I removed the triangular tests too. What is left at this point:
- Regold the test files for SOU and the dispersion test and make sure that the gold files show up only once in the history
We may see issues additional issues with the new additions. I'll keep monitoring this PR.
Okay, regold history is clean, we will need this in: https://github.com/idaholab/moose/pull/29146 And then we can roll.
actually this last commit should be squashed in a previous one see dc52825 15691c9
you re checking in 8 gold files twice
I will delete the gold files from https://github.com/idaholab/moose/commit/15691c99b6f9a23b5a9c19ee54f3c4b3452a69f4 Finding a issues with squashing and don't have time to evaluate non-regression in the flow test bed
Edit: Should be good