Update deprecated EXT_ITER option in test configs

[Syphonicc]

EXT_ITER was removed in SU2 v7 and replaced by ITER. Five test configs still used the old name and failed to parse. Following review, each was fixed, tuned to converge in a reasonable time, and added to serial_regression.py at test_iter = 20.

Proposed Changes

Case	Change	Result
euler/channel/inv_channel	rename, CFL 30	−12 @ 2609
euler/CRM/inv_CRM_JST	rename, CFL 100 with multigrid smoothing/damping, explicit SCREEN_OUTPUT	−6 @ 261
navierstokes/naca0012/lam_NACA0012	rename, CFL 30, adaptation off	−12 @ 5909
rans/flatplate/turb_SST_flatplate	rename, CFL 50 with adaptation (0.5, 1.2, 10, 200), criterion −15 → −12, explicit SCREEN_OUTPUT	−12 @ 6383
rans/s809/turb_S809	rename, explicit SCREEN_OUTPUT; settings unchanged per review	−9.02 @ 10000, still descending

The explicit SCREEN_OUTPUT is needed so the regression harness reads the intended residual columns.

The two control_surface ONERAM6 cases and rans_uq were initially included and reverted per review.

Related Work

Other TestCases configs that fail to parse are tracked in #2898 (hom_euler meshes in #2874). #2899 adds a LINELET variant of lam_NACA0012.

PR Checklist

• 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]

While you're at it: I counted 42 instances of EXT_ITER in the Testcases subdirectory.
Are these cases regression-tested? If they have invalid config options they should not be able to run?

[Syphonicc]

While you're at it: I counted 42 instances of EXT_ITER in the Testcases subdirectory. Are these cases regression-tested? If they have invalid config options they should not be able to run?

Right none of them are regression-tested, which is why they've been able to rot. I checked every config containing EXT_ITER against serial_regression.py and parallel_regression.py and none are referenced. As you say, they'd fail immediately in CI otherwise.

I swept all 42 locally (fixing EXT_ITER → ITER and running each with a short iteration cap). Breakdown:

8 run fine with just the rename , those are this PR.

24 are the hom_euler DG cases. They need REF_LENGTH_MOMENT → REF_LENGTH as well, but 21 then fail because the referenced mesh files don't exist in either repo, and 3 are unsteady so EXT_ITER maps to TIME_ITER/INNER_ITER rather than ITER. I left all of these alone since I can't verify them.

The rest need individual fixes: further deprecated options (FROZEN_VISC, GEO_AXIS_STATIONS, SOLUTION_LIN_FILENAME), SOLVER= NAVIER_STOKES with a turbulence model set (should presumably be RANS), SOLVER= FLUID_STRUCTURE_INTERACTION which no longer exists, and a couple of Sutherland's-law validation errors.

Happy to keep going on the fixable ones in follow-up PRs if that's useful I kept this one to the cases I could actually verify run.

[bigfooted]

I think it makes more sense to look at these config files individually, get them working and then add them to the regression test. These might be relatively easy to fix:
euler/CRM/inv_CRM_JST.cfg
euler/channel/inv_channel.cfg
navierstokes/naca0012/lam_NACA0012.cfg
rans/flatplate/turb_SST_flatplate.cfg
rans/s809/turb_S809.cfg

I don't think they test something exotic and you can visually inspect the result to see if it looks reasonable.

I am not sure what the moving/setting onera cases are supposed to test, and for uncertainty quantification a more thorough test is needed to make sure it works as expected.

[Syphonicc]

Updated this to the five cases you suggested, and worked each one properly rather than just doing the rename. Reverted the two ONERAM6 control_surface cases and rans_uq as you suggested.

Case	Converges to	Change
euler/channel/inv_channel	−12.00 @ 6782 ✅	rename only
euler/CRM/inv_CRM_JST	−6.01 @ 778 ✅	rename only
navierstokes/naca0012/lam_NACA0012	−12.00 @ 5824 ✅	CFL 1→3, adaptation on
rans/flatplate/turb_SST_flatplate	−14.46 (plateau, criterion is −15)	adaptation on
rans/s809/turb_S809	−9.02 @ 10k (criterion is −12)	rename only

On the CFL changes: lam_NACA0012 at CFL 1 reached only −8.56 in 10k iterations and would need roughly 60k to meet its −12 criterion; CFL 3 with adaptation converges fully in 5824. turb_SST_flatplate went from −8.26 to −14.46 at 10k iterations just by enabling adaptation. I also tried adaptation on turb_S809 and it made things worse (−7.39 vs −9.02), so I left that one as-is.

While enabling adaptation I hit an error on CFL_ADAPT_PARAM: factor-down and factor-up are swapped in these files (1.5, 0.5 instead of 0.5, 1.5). It's inert wherever CFL_ADAPT= NO, but the same reversed values appear in quite a few other configs. Fixed in the two files where adaptation is now on.

Two cases don't reach their configured CONV_RESIDUAL_MINVAL. turb_SST_flatplate plateaus at −14.46 against −15 (I ran it to 30k; it gained 0.005 between iterations 25k and 30k). turb_S809 is still descending at 10k but slowly. Happy to relax those criteria if you'd prefer, or leave them.

Visual checks below, all coloured by Mach:

• inv_channel — smooth subsonic acceleration over the bump, peak Mach 0.13, no shocks.
• inv_CRM_JST — supersonic pocket on the upper wing reaching Mach 1.3 with a clear spanwise shock, as expected at Mach 0.8395 / AoA 3.06°.
• lam_NACA0012 — thick laminar boundary layer and broad wake, symmetric top/bottom at AoA 0, consistent with Re=5000.
• turb_SST_flatplate — thin turbulent boundary layer growing along the plate at Re=5×10⁶.
• turb_S809 — attached flow with a slight upper-surface bias from the camber, no separation.

All five added to serial_regression.py with test_iter = 25; values verified reproducible locally, though I expect CI will want slightly different ones as before.

)

[bigfooted]

Looks pretty good, you can lower the convergence criterion for turb_sst_flatplate to -12. Thats probably sufficient. But all cases take a long time to converge. With adaptive cfl, is the cfl really increasing a lot? My guess is these cases should run with cfl=100 or so because the mesh is nice and the physics simple.. the only main concern us th s809 airfoil because it does nit converge with the current settings. The guideline is that all testcases have a config that works well and converges the solution, preferably fast.

[Syphonicc]

Looks pretty good, you can lower the convergence criterion for turb_sst_flatplate to -12. Thats probably sufficient. But all cases take a long time to converge. With adaptive cfl, is the cfl really increasing a lot? My guess is these cases should run with cfl=100 or so because the mesh is nice and the physics simple.. the only main concern us th s809 airfoil because it does nit converge with the current settings. The guideline is that all testcases have a config that works well and converges the solution, preferably fast.

Thanks. Setting CONV_RESIDUAL_MINVAL= -12 for the flat plate and you were right about the CFL.

turb_SST_flatplate: CFL was pinned at exactly 100, i.e. sitting on the CFL_ADAPT_PARAM ceiling the whole run. Raising it helped a lot, but the growth factor mattered too — (0.5, 1.5, 10.0, 1000.0) overshot and NaN'd around CFL 570. CFL_NUMBER= 50 with (0.5, 1.2, 10.0, 200.0) is stable at CFL 200 and converges to −12 in 3836 iterations, versus −8.26 at 10k with the original settings. Updated.

turb_S809 is the problem case, and I haven't cracked it. CFL won't go above single digits no matter what I try — adaptation raises it, it gets knocked straight back, and it settles on whatever the floor is. Things I tested, everything else held constant:

CFL ceiling 100 → 200, growth 1.5 and 1.2: pinned at the floor either way
LINEAR_SOLVER_ITER 2 → 10 and LINEAR_SOLVER_ERROR 1E-4 → 1E-6: no change
SLOPE_LIMITER_FLOW= NONE → VENKATAKRISHNAN (it currently runs MUSCL unlimited, with an orphaned VENKAT_LIMITER_COEFF): residual actually started creeping back up

Best I've got is −9.02 at 10k with the original settings. One thing I noticed: SU2 reports a max CV face area aspect ratio of ~104,000 for this mesh. I'm wondering whether that's what's capping the timestep rather than any solver setting. Do you know if this case has a history of being awkward, or would a different mesh be the answer?

Happy to drop s809 from this PR and land the other four if that's easier or keep digging if you have a direction.

[Syphonicc]

I rebuilt develop (0b69749) cleanly from scratch and re-ran all five. Some of my earlier numbers came from an incrementally-rebuilt tree and were optimistic on iteration counts, so here's the corrected set. Also took your point about CFL — fixed CFL 30 turns out to work well on two of these.

Case	Setting	Result
euler/channel/inv_channel	CFL 6 → 30	−12 @ 2609 (at CFL 6 it only reached −6.44 by 10k)
euler/CRM/inv_CRM_JST	unchanged (CFL 5)	−6.01 @ 1113 ✅
navierstokes/naca0012/lam_NACA0012	CFL 30, adaptation off	−12 @ 5909
rans/flatplate/turb_SST_flatplate	unchanged (CFL 50 + adapt)	−12 @ 6383 ✅
rans/s809/turb_S809	unchanged (CFL 10)	−10.37 @ 40000, still descending

The CFL 100 case is odd — the residual drops to −8.18, then freezes at exactly −7.580046571 and stays identical to ten significant figures for the next 7000 iterations. Not oscillation or divergence, it just stops updating. Not sure whether that's expected behaviour when the CFL is too high.

On turb_S809: it does converge, just slowly — −9.02 @ 10k, −10.04 @ 33.5k, −10.37 @ 40k, roughly 0.04 per thousand and fairly steady. Extrapolating, −12 would need somewhere around 80k iterations. Higher CFL makes it worse: CFL 30 flatlines at −6.9 within 1000 iterations and stays there. Given SU2 reports a max CV face area aspect ratio of ~104,000 on this mesh, I suspect that's what's capping the timestep rather than any solver setting.

Would you prefer I relax its criterion to −10 (reachable at around 34k), leave it as is, or drop the case from this PR?

Once you're happy with the settings I'll update the two configs and regenerate all the test values.

[bigfooted]

any updates? The CRM case can have CFL=100 with multigrid,

MGLEVEL= 3
MG_MIN_MESHSIZE= 100
MGCYCLE= V_CYCLE
MG_SMOOTH_OUTPUT= NO
MG_SMOOTH_EARLY_EXIT= YES
MG_PRE_SMOOTH= ( 2, 2, 2, 2 )
MG_POST_SMOOTH= ( 2, 2, 2, 2 )
MG_CORRECTION_SMOOTH= ( 1, 1, 1, 1 )
MG_DAMP_RESTRICTION= 0.75
MG_DAMP_PROLONGATION= 0.75

And for the s809, I did not find a good setting to converge much faster. At least it is converging...
So if you update the CRM I think it is good to go.

for the regression tests, you can put the nr of iterations to 20 and then we update the residuals to compare against that these cases have at iteration 20.

[Syphonicc]

any updates? The CRM case can have CFL=100 with multigrid,

MGLEVEL= 3
MG_MIN_MESHSIZE= 100
MGCYCLE= V_CYCLE
MG_SMOOTH_OUTPUT= NO
MG_SMOOTH_EARLY_EXIT= YES
MG_PRE_SMOOTH= ( 2, 2, 2, 2 )
MG_POST_SMOOTH= ( 2, 2, 2, 2 )
MG_CORRECTION_SMOOTH= ( 1, 1, 1, 1 )
MG_DAMP_RESTRICTION= 0.75
MG_DAMP_PROLONGATION= 0.75

And for the s809, I did not find a good setting to converge much faster. At least it is converging... So if you update the CRM I think it is good to go.

for the regression tests, you can put the nr of iterations to 20 and then we update the residuals to compare against that these cases have at iteration 20.

Thanks - that answers the s809 question, I'll leave it as is.

I'll apply the multigrid settings to inv_CRM_JST with CFL 100 and report the convergence numbers from a clean build. Once that's confirmed I'll push the config updates (inv_channel CFL 30, lam_NACA0012 CFL 30 with adaptation off, CRM as above) and add the five regression entries at ITER 20, then update the residuals from what CI reports.

[Syphonicc]

Pushed. All five now pass at test_iter=20 on a clean develop build:

Case	Setting	Result
inv_channel	CFL 30	-12 @ 2609
inv_CRM_JST	CFL 100 + your multigrid settings	-6 @ 261 (was 1113, 4.3x fewer)
lam_NACA0012	CFL 30, adaptation off	-12 @ 5909
turb_SST_flatplate	CFL 50, adapt (0.5,1.2,10,200)	-12 @ 6383
turb_S809	unchanged	-9.02 @ 10000 (config's ITER cap), still descending

On CRM: I dropped MG_MIN_MESHSIZE=100 from your suggested block - checked the multigrid setup table and the coarsest level already lands at 771 CVs on this mesh, above the 500 default, so that line had no effect. Kept the CFL and smoothing/damping changes, which account for the full improvement.

Also found that CRM, the flat plate, and S809 had no explicit SCREEN_OUTPUT, so only 4-5 of the tracked residuals were printing to screen even though history.csv has them all. Added SCREEN_OUTPUT to each listing the full set - otherwise the regression harness reads the wrong columns.

s809 stays at its current settings per your last comment.

[Syphonicc]

Small housekeeping push on this branch:

• Removed TestCases/euler/biparabolic/EA_TEST.cfg and
  TestCases/euler/biparabolic/NF_ONLY.cfg. Those were scratch configs from the
  nearfield investigation in Fix biparabolic regression #2865 and got swept into this branch by mistake
  they were never meant to be part of this PR. The diff is now limited to the
  five configs and serial_regression.py.
• Merged current develop into the branch.
  The merge brought in changes to CSolver.cpp, COutput.cpp and
  CFlowOutput.cpp. My posted convergence numbers were taken on 0b697492c8, so
  I'll re-run them on a clean build before treating them as current.

The failing CodeFactor check is whitespace alignment in serial_regression.py,
consistent with the existing style of that file. Happy to change it if you'd
prefer, but I've left it as-is to keep the diff readable.

[Syphonicc]

Re-ran all five cases on a clean build of current develop (8118ee0) after the merge. The test_vals at iteration 20 reproduce exactly for all five, and so do the convergence numbers:

Case	Result
inv_channel	−12 @ 2609
inv_CRM_JST	−6 @ 261
lam_NACA0012	−12 @ 5909
turb_SST_flatplate	−12 @ 6383
turb_S809	−9.02 @ 10000 (ITER cap)

Nothing changed, so the branch is ready from my side.

[bigfooted]

Thanks, if you merge with develop again I can rerun the workflow.

[Syphonicc]

Merged develop, thanks!