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?

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.

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.

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.

)

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.

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.