Axisymmetric near-axis fixes using L’Hôpital-consistent formulations by raghava-davuluri · Pull Request #2715 · su2code/SU2

raghava-davuluri · 2026-01-22T02:03:23Z

Proposed Changes

Give a brief overview of your contribution here in a few sentences.

Improve axisymmetric source-term behavior near the symmetry axis by smoothly transitioning between the standard v/r formulation and a L’Hôpital-consistent ∂v/∂r formulation as r→0.
Apply a L’Hôpital-consistent treatment for axisymmetric auxiliary gradient terms at the axis instead of zeroing them.

Related Work

Resolve any issues (bug fix or feature request), note any related PRs, or mention interactions with the work of others, if any.

Addresses nonphysical behavior observed in axisymmetric stagnation-region solutions where the 1/r terms become singular near the axis. This PR was prepared for review/discussion with SU2 developers.
The standard formulation is preserved away from the axis; the near-axis modification only affects the r→0 limit.

PR Checklist

Put an X by all that apply. You can fill this out after submitting the PR. If you have any questions, don't hesitate to ask! We want to help. These are a guide for you to know what the reviewers will be looking for in your contribution.

I am submitting my contribution to the develop branch.
My contribution generates no new compiler warnings (try with --warnlevel=3 when using meson).
My contribution is commented and consistent with SU2 style (https://su2code.github.io/docs_v7/Style-Guide/).
I used the pre-commit hook to prevent dirty commits and used pre-commit run --all to format old commits.
I have added a test case that demonstrates my contribution, if necessary.
I have updated appropriate documentation (Tutorials, Docs Page, config_template.cpp), if necessary.

bigfooted · 2026-01-22T06:55:04Z

Hi @raghava-davuluri, thanks for this fix! Does this case need additional regression tests or is it covered by the existing regression tests for axisymmetric flow?
At the moment we have these testcases with axisymmetry, not too much so maybe add an additional one that you've worked on:

axisymmetric_rans/air_nozzle/air_nozzle_restart.cfg:16:AXISYMMETRIC= YES
flamelet/05_laminar_premixed_ch4_flame_cfd_axi/lam_prem_ch4_cfd_axi.cfg:29:AXISYMMETRIC= YES
nonequilibrium/visc_cylinder/cyl_ion_gy.cfg:14:AXISYMMETRIC= YES
nonequilibrium/visc_wedge/axi_visccone.cfg:18:AXISYMMETRIC= YES
py_wrapper/turbulent_premixed_psi/psi.cfg:67:AXISYMMETRIC= YES
vandv/species_transport/sandia_jet/validation.cfg:58:AXISYMMETRIC= YES

Hanquist · 2026-01-22T14:19:08Z

This is addressing #2438

It helps in most situations, but dips in axisymmetric heating cases can still be present for some meshes. So @raghava-davuluri is doing a pull request to help get more eyes on it.

Hanquist · 2026-01-22T15:39:01Z

@raghava-davuluri @bigfooted, reading up on this more, L'Hopital's rule may be more suitable for cell-centered and less so for vertex-centered codes. And that all the residuals should still be zero at the symmetry line. Here is an example of the axisymmetric sources along the surface. I would expect the energy and momentum-x to smoothly go to zero at theta=0 instead of a discontinuity

bigfooted · 2026-01-26T07:21:49Z

+  /*--- Common calculations for both branches ---*/
+  su2double rho = U_i[0];                     // density
+  su2double u = U_i[1]/U_i[0];                // u-velocity
+  su2double v = U_i[2]/U_i[0];                // v-velocity


Suggested change

su2double v = U_i[2]/U_i[0]; // v-velocity

//su2double v = U_i[2]/U_i[0]; // v-velocity

@raghava-davuluri can you fix these so the code compiles on github and we see the result of the regression tests?

@bigfooted I have addressed the requested changes and updated the branch. Could you please approve the workflows so the CI checks can run?

bigfooted · 2026-01-26T07:24:04Z

I'd say the source terms should not jump close to r=0, but they are allowed to be nonzero.

bigfooted · 2026-09-11T07:05:47Z

@raghava-davuluri can you update the branch? Even though there is still work to be done I think we should put this in the code since it is an improvement over what we currently have.

raghava-davuluri · 2026-09-15T21:13:08Z

@bigfooted Thanks! I have updated the branch with the latest develop. The regression-test workflow is currently awaiting maintainer approval to run.

bigfooted · 2026-09-16T05:52:08Z

Hi @raghava-davuluri is there an existing regression test that can be used? How large is the testcase that you used for the image?

bigfooted · 2026-09-16T18:55:56Z

@raghava-davuluri can you check the failed regression tests and if it makes sense, update the residuals?

raghava-davuluri · 2026-09-16T21:20:20Z

@bigfooted I am working on that. I will update you soon.

raghava-davuluri · 2026-09-22T19:24:05Z

@bigfooted I’ve updated the branch, resolved the conflicts, and updated the affected regression values. The workflows are now awaiting maintainer approval. Could you please approve them when you get a chance? Thanks!

raghava-davuluri · 2026-09-23T18:30:18Z

@bigfooted, I’ve pushed another update to address the regression test issue. The workflow is awaiting approval again. Hopefully this is the last time and everything works this time! Thanks again for your help.

bigfooted · 2026-09-23T19:09:02Z

Hi @raghava-davuluri OK, you're the next PR to get merged, great to have this fix finally in!

bigfooted · 2026-09-24T15:20:38Z

@raghava-davuluri can you check that the ion regression testcase converges if you let it run for more iterations? one of the density residual values is increasing but maybe it's temporary? Preferably all regression tests should converge if you run it to completion.

raghava-davuluri · 2026-09-24T20:16:24Z

@bigfooted I looked into this further and found the source of the ion_gy regression. The change I made in ComputeAxisymmetricAuxGradients() is also affecting NEMO, since both CEulerSolver and CNEMOEulerSolver call this common routine. I confirmed this locally by restoring only this function to the upstream version, after which the ion_gy regression test passes again.

I’ll work on separating the new axis treatment from the existing NEMO behavior. Please give me a day to resolve this, and I’ll leave another comment here once the fix is pushed and ready for CI approval.

bigfooted · 2026-09-24T20:58:38Z

If the method is correct for NEMO then that's fine, it should just be checked that the case still converges with this different type of source term. If it doesn't then I hope it's sufficient to use a lower CFL.

raghava-davuluri · 2026-09-24T23:07:36Z

@bigfooted Thanks. The axisymmetric treatment in this PR is currently only intended for the standard SU2 solver; the corresponding NEMO treatment has not been included yet. Since SU2 and NEMO share the same auxiliary-gradient function, the change was also affecting NEMO and caused the ion_gy regression failure. I’ve now added a condition to exclude NEMO from this treatment for the time being, and verified the NEMO axisymmetric regression cases locally. Hopefully this is the last time I’ll need to ask you to approve the CI tests!

bigfooted · 2026-09-25T09:51:21Z

OK, thanks for the clarification. there is now a conflict, can you check? I guess it needs to be merged with latest develop again.

raghava-davuluri · 2026-09-25T19:12:23Z

@bigfooted Done. I rebased the branch onto the latest develop and resolved the conflict. I also rebuilt and rechecked the relevant axisymmetric cases, including the NEMO cases, and they pass locally. The workflows are awaiting approval again. Thanks!

bigfooted · 2026-09-26T20:40:37Z

only axi_rans_air_nozzle_species regression test still fails...
edit: because of the changes I made to the multigrid solver...

bigfooted · 2026-09-27T12:54:27Z

+  su2double std_res[4];
+  if (r > EPS) {
+    yinv = 1.0/r;
+    std_res[0] = yinv*Volume*U_i[2];                    // ρv/r


Suggested change

su2double std_res[4];

if (r > EPS) {

yinv = 1.0/r;

std_res[0] = yinv*Volume*U_i[2]; // ρv/r

su2double std_res[4];

yinv = (r > EPS) ? 1.0/r : 0.0;

if (r > EPS) {

std_res[0] = yinv*Volume*U_i[2]; // ρv/r

bigfooted · 2026-09-27T12:56:42Z

+      // Use standard Jacobian when mostly in standard formulation
+      yinv = 1.0/r;


Suggested change

// Use standard Jacobian when mostly in standard formulation

yinv = 1.0/r;

// Use standard Jacobian when mostly in standard formulation

bigfooted added the changelog:fix label Jan 22, 2026

github-advanced-security AI found potential problems Jan 22, 2026

View reviewed changes

Comment thread SU2_CFD/src/numerics/flow/flow_sources.cpp Fixed

pcarruscag approved these changes Jan 22, 2026

View reviewed changes

bigfooted reviewed Jan 26, 2026

View reviewed changes

raghava-davuluri force-pushed the develop_axifix branch from 1422a8a to 914bebc Compare September 15, 2026 21:02

raghava-davuluri force-pushed the develop_axifix branch from 67520e7 to f8006e0 Compare September 22, 2026 19:21

Hanquist and others added 7 commits September 25, 2026 14:30

Trying to fix axisymmetry issue seen in heat flux

f4467cf

Clarifying the change

1b53ab2

Axisymmetric source term: blend dv/dr with v/r near axis

a26ee2a

Remove redundant velocity definition

80027c2

Update regression values for axisymmetric source term

060b823

Restore ion_gy regression values

cd725f1

Exclude NEMO from axisymmetric auxiliary correction

b765070

Remove trailing whitespace

503e6fd

raghava-davuluri force-pushed the develop_axifix branch from d415566 to 503e6fd Compare September 25, 2026 19:09

bigfooted reviewed Sep 27, 2026

View reviewed changes

	su2double v = U_i[2]/U_i[0]; // v-velocity
	//su2double v = U_i[2]/U_i[0]; // v-velocity

		// Use standard Jacobian when mostly in standard formulation
		yinv = 1.0/r;

Conversation

raghava-davuluri commented Jan 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Proposed Changes

Related Work

PR Checklist

Uh oh!

bigfooted commented Jan 22, 2026

Uh oh!

Uh oh!

Hanquist commented Jan 22, 2026

Uh oh!

Hanquist commented Jan 22, 2026

Uh oh!

bigfooted Jan 26, 2026

Choose a reason for hiding this comment

Uh oh!

bigfooted Jan 27, 2026

Choose a reason for hiding this comment

Uh oh!

raghava-davuluri Apr 9, 2026

Choose a reason for hiding this comment

Uh oh!

bigfooted commented Jan 26, 2026

Uh oh!

bigfooted commented Sep 11, 2026

Uh oh!

raghava-davuluri commented Sep 15, 2026

Uh oh!

bigfooted commented Sep 16, 2026

Uh oh!

bigfooted commented Sep 16, 2026

Uh oh!

raghava-davuluri commented Sep 16, 2026

Uh oh!

raghava-davuluri commented Sep 22, 2026

Uh oh!

raghava-davuluri commented Sep 23, 2026

Uh oh!

bigfooted commented Sep 23, 2026

Uh oh!

bigfooted commented Sep 24, 2026

Uh oh!

raghava-davuluri commented Sep 24, 2026

Uh oh!

bigfooted commented Sep 24, 2026

Uh oh!

raghava-davuluri commented Sep 24, 2026

Uh oh!

bigfooted commented Sep 25, 2026

Uh oh!

raghava-davuluri commented Sep 25, 2026

Uh oh!

bigfooted commented Sep 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bigfooted Sep 27, 2026

Choose a reason for hiding this comment

Uh oh!

bigfooted Sep 27, 2026

Choose a reason for hiding this comment

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

raghava-davuluri commented Jan 22, 2026 •

edited

Loading

bigfooted commented Sep 26, 2026 •

edited

Loading