Skip to content

Add GCL correction for general topologies#1420

Open
rcknaus wants to merge 9 commits into
kynema:mainfrom
rcknaus:residual-gcl-correction
Open

Add GCL correction for general topologies#1420
rcknaus wants to merge 9 commits into
kynema:mainfrom
rcknaus:residual-gcl-correction

Conversation

@rcknaus
Copy link
Copy Markdown
Contributor

@rcknaus rcknaus commented May 23, 2026

Adds an optional continuity residual correction to kynema-ugf. This will add a non-kinetic energy conserving residual correction if the flow, for whatever reason, has a discrete mass change including a GCL error. For the GCL conforming topologies this has no impact in constant density flow. In non-constant density flow, this will always have an impact and will ensure discrete mass conservation on the first nonlinear iteration, where the predictor is insufficient for maintaining discrete conservation.

This capability will throw an error in a few, likely uncommon, use cases, such as nonconforming meshes and inflow from the FFT-based ABL top boundary condition capability. If those cases are wanted, let me know.

Also adds a hybridMeshDeformation test demonstrating free-stream preservation on a fully hybrid mesh containing all 3D topologies. The mesh itself will need to be added to the mesh repository in a separate PR for that sub-repo. kynema/kynema-ugf-meshes#15

@rcknaus
Copy link
Copy Markdown
Contributor Author

rcknaus commented May 27, 2026

Test failure for CPU-Trilinos build seems unrelated and pre-existing given #1422 . Interestingly it's failing at a different spot in each, so probably need an asan build

@michaelasprague michaelasprague requested a review from Copilot May 28, 2026 15:23
@michaelasprague michaelasprague review requested due to automatic review settings May 28, 2026 15:23
@gantech
Copy link
Copy Markdown
Contributor

gantech commented May 28, 2026

Hey @rcknaus . Thanks for implementing this. Here are my comments. I need some more help to finish reviewing this.

  1. This algorithm is different from the one we had earlier for hex-only meshes. Could you give a single page description as a comment or a pdf file of this algorithm and how it works to satisfy gcl?

  2. We already had a test MeshMotionInterior. Does this still work with this algorithm to the same tolerance in continuity?

  3. Have we tried any of the exawind benchmarks with FSI with this algorithm? Specifically this one? https://github.com/kynema/kynema-benchmarks/tree/main/exawind/Pazy_Wing

@rcknaus
Copy link
Copy Markdown
Contributor Author

rcknaus commented May 29, 2026

Hey Ganesh, in lieu of a document, basically the idea is that you subtract out the continuity residual from flow when the include_continuity_residual: yes option is on. This subtracts out (d_t rho + div mdot) q where q is the dof. That term is exactly the discrete free-stream preservation error (say q is constant) and so ensures free-stream preservation that way. Generally it'll impact any case where there is a discrete loss of mass conservation for whatever reason (so variable density, non-divergence free flows too given we don't fully ensure mass conservation there until nonlinear convergence).

For the new test vs MeshMotionInterior, the new term has no impact whether it's on or not for the MeshMotionInterior test (the continuity residual is ~1e-15 for that case). Anyway, for the new test, running the case with a static mesh has a small free-stream preservation error that I think is due to a lack of volume/area conservation in the pyramid formulation itself. I didn't really track it down--sorry. The mesh motion increases the error ~100 times the static case, but there the mesh almost inverts there and is dramatically better than not having it the continuity residual on.

For testing, I haven't run the Pazy wing test. The expectation there is that this has no impact whether it's switched on or off for that case. There was a less general version of this I ran on a hybrid case Nate worked on a while ago and kept the case from diverging. But more robust testing on more user cases is certainly warranted.

There are definitely some things that could be wrapped up more here, but this should allow you to run deforming, hex-pyramid-tet meshes.

EDIT: also doesn't account for any continuity sources. We don't have any in kynema-ugf but if you ever add them, the term will also need to get adjusted.

@gantech
Copy link
Copy Markdown
Contributor

gantech commented May 29, 2026

Hey Robert. Thanks.

  1. The new approach to satisfying GCL is still unclear to me.

  2. I don't think the regression test I mentioned earlier will work without the GCL treatment we had earlier.

I believe we need to turn off the existing mechanism to satisfy GCL to test the new implementation. Is this correct?

If this is correct, have we turned off the existing mechanism to satisfy GCL as a part of this pull request? I believe the existing mechanism turns on automatically if mesh deformation is on. https://github.com/kynema/kynema-ugf/blob/main/src/edge_kernels/ContinuityEdgeSolverAlg.C#L92

  1. Is the new approach proven through implementation in literature? I believe the previous approach was copied verbatim from Mavriplis et al. and used in a lot of work. If the new approach is not from the literature, then I think we must at least run the exawind benchmarks to prove the new approach on real cases before using it.

…with mdot update, activation of alg in test, and modify warning to clarify on mixed meshes
@rcknaus
Copy link
Copy Markdown
Contributor Author

rcknaus commented May 29, 2026

@gantech updated with the small changes I mentioned in our meeting and a documentation blurb on the residual correction. For the regression test, you'll need to merge kynema/kynema-ugf-meshes#15 first and potentially will need to have @jrood-nrel rebless with gold file with nrel systems.

@jrood-nrel jrood-nrel requested a review from gantech June 2, 2026 20:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants