Updating Limiters for Finite Volume Formulation

[tanoret]

Closes #28891

[tanoret]

@freiler plase also take a look if you can

[tanoret]

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

[tanoret]

To-do:

• Modify the implicit vs explicit update in the limiters and select the best default option for each
• Correct QUICK issues
• Improve the documentation for all functions in limiters and MathFVUtils
• Write updated documentation on limiters
• Test limited advection schemes from two fronts

[GiudGiud]

you'll want to get rid of the submodule update in the wasp folder

[lindsayad]

Should I wait to review this until you've removed the WIP label? In which case should we convert this to draft?

[tanoret]

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

[lindsayad]

You can mention me once you're done pushing and I will review. Going to unsubscribe for now

[GiudGiud]

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

[moosebuild]

Job Documentation, step Docs: sync website on 2c4b562 wanted to post the following:

View the site here

This comment will be updated on new commits.

[GiudGiud]

early feedback, not quite done but might be delayed tomorrow

[GiudGiud]

are we expecting any additional insights from top-right as opposed to bottom-left?

[tanoret]

Yes. The gradient limiting is directional. I just want to make sure that no direction is ever messed up

[GiudGiud]

The gradient limiting is directional as in it depends on which direction is upwind. high/low X, Y, Z are not coded anywhere?

[tanoret]

No. It also has a directional component when computing the gradient at the center of the cell. If someone messess this up it needs to show in these tests

[GiudGiud]

@grmnptr do you understand why that would be?
I m at a loss on this.

[GiudGiud]

how is top right any different from bottom left in the code?
we dont hard code any direction as different from any other?

[tanoret]

The way in which you do second order limiting, goes as follows:

$$\phi_f = \phi_c + (\nabla \phi)c d{fc}$$

(\nabla \phi)c is computed per direction, e.g., in 2D, (\nabla \phi)c = [(\nabla \phi){c,x}, (\nabla \phi){c,y}]

Note that in top-left advection, each component of the limiting gradient are positive, whereas in bottom-right, they are negative. If someone ever messes up the directionality of this gradient (e.g., by limiting to zero the minimum components of the gradient), it needs to show up in the failing tests but it won't if we are only doing advection from the bottom-left

[GiudGiud]

ok I see now what you are thinking of.
Unfortunately we cant be targeting each potential mistake in modifications using regression tests. For example, what if someone switches the Y and X components? Both of these 45 degree tests would not catch it, yet we wont add 5 more tests to make sure this does not happen.

Testing the limiter for such behavior should be done in a unit test if you care to prevent it.

[tanoret]

Thanks. All limiters don't work the same and depend on the gradient somehow. So, I will still need to test them in both directions. I can remove the upwind test for advection from the top-right if you like. It is the only redundant one that I can think of

[GiudGiud]

if you use the 'hide' parameter as shown in the latest comments I expect the file size will go down enough that it does not matter as much that the tests are doubled

[tanoret]

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?

[moosebuild]

Job Precheck, step Clang format on c6913a1 wanted to post the following:

Your code requires style changes.

A patch was auto generated and copied here
You can directly apply the patch by running, in the top level of your repository:

curl -s https://mooseframework.inl.gov/docs/PRs/28892/clang_format/style.patch | git apply -v

Alternatively, with your repository up to date and in the top level of your repository:

git clang-format 7377410027ba9dbf48902235a0437fdf96485e29

[moosebuild]

Job Precheck on c5dfb2c : invalidated by @grmnptr

[moosebuild]

Job Precheck on c5dfb2c : invalidated by @grmnptr

[grmnptr]

I dropped the submodule upodate and fixed (we will see based on the tests) some tests.

[grmnptr]

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 Steady and previous_nl_solution_required = true on 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.

[grmnptr]

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.