Fix unsteady testcase configs and add regression tests

[Sahilll10]

Proposed Changes

Three unsteady test case configs were missing TIME_DOMAIN=YES and TIME_ITER, causing SU2 to silently default to a single steady iteration instead of running an unsteady simulation. This PR fixes all three configs and registers them in serial_regression.py so they are CI-tested going forward.

Changes made:

pitching_naca64a010_rans/turb_NACA64A010.cfg — fix SOLVER=RANS (was NAVIER_STOKES despite KIND_TURB_MODEL=SA), add TIME_DOMAIN=YES, TIME_ITER=100, remove deprecated EXT_ITER, add SCREEN_OUTPUT
pitching_naca64a010_euler/pitching_NACA64A010.cfg — add TIME_DOMAIN=YES, TIME_ITER=100, remove deprecated EXT_ITER, add SCREEN_OUTPUT
plunging_naca0012/plunging_NACA0012.cfg — add TIME_DOMAIN=YES, TIME_ITER=100, remove deprecated EXT_ITER, add SCREEN_OUTPUT
serial_regression.py — register all three cases with test_iter=1 and unsteady=True, following the pattern of the existing unst_inc_turb_naca0015_sa entry

All three cases were run locally with SU2 v8.4.0 on Ubuntu 24 / GCC 13. Residuals converge steadily through inner iterations and CL/CD values change each time step confirming dual time-stepping is working correctly.

Related Work

Fixes #2524

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.

[Sahilll10]

Thanks @bigfooted for merging develop in and adding the label.

I've synced locally and the branch looks clean on my end too.

Happy to address any review comments if anything comes up.

Please let me know if there's anything else needed to get this across the line.

[pcarruscag]

Your changes are doing 2 timesteps with 2000 inner iterations each.
Run the cases locally and show us a plot of the results.
Then you should add restart files to the testcases repo so that the tests to a few time steps starting from a meaningfully developed flow. Then the values of lift and drag tracked in the regressions make sense.

[Sahilll10]

Hi @pcarruscag @bigfooted

I havee been working on the restart files now, wanted to share progress and ask a couple of questions before I finalize.

I ran all three cases locally for the full 100 time steps with OUTPUT_FILES= (RESTART_ASCII) to generate restart files. The Euler case finished cleanly and I have restart_flow_00098.csv and restart_flow_00099.csv (8607 lines each, looks healthy). The plunging case completed 23 time steps before the process was killed by the OS — I suspect memory pressure from running all three jobs in parallel.
I have files up to restart_flow_00022.csv which should be sufficient. The RANS case is still running — I reduced INNER_ITER from 2000 to 300 for the restart generation

Following the pattern of square_cylinder, my plan is to:

1. rename the last two completed restart files of each case to solution_flow_00000.csv and solution_flow_00001.csv
2. add RESTART_SOL= YES, READ_BINARY_RESTART= NO, RESTART_ITER= 2, OUTPUT_FILES= (RESTART_ASCII) to each config
3. commit the solution files to the TestCases repo
4. re-run test_iter=1 from the restart to extract new test_vals from a developed flow

Two questions before I proceed:

1. For the RANS case the residuals at time step 2 with INNER_ITER=300 are around rms[Rho]=-4.6, rms[nu]=-5.3 — is that sufficient convergence per time step for the restart to be considered "meaningfully developed", or should I wait for the full INNER_ITER=2000 run to complete?

2. For the plunging case — 22 completed time steps corresponds to roughly 22% of the pitching period. Is that enough for the flow to be considered developed, or do you want a restart from closer to a full oscillation cycle (time step ~90+)?

Happy to re-run everything at full quality if needed .

Please confirm the approach before i commit files to the TestCases repo.

[pcarruscag]

Show us what the solution and time history of coefficients looks like.

[Sahilll10]

Hi @pcarruscag

Here are the time histories of CL and CD for all three cases.
The Euler and RANS/SA pitching cases both show clean periodic sinusoidal behaviour — CL amplitude ±0.11 to ±0.12 with CD settling from the initial transient to a small periodic oscillation after ~15-20 time steps.
The RANS case used INNER_ITER=300 for the restart generation run which explains the slightly faster initial transient decay compared to the full 2000 inner iter run.
The plunging NACA0012 case only completed 23 time steps (the process was killed by OS memory pressure from running all three jobs in parallel).
The CL shows the large initial added-mass spike decaying toward periodic behaviour but has not yet reached a settled oscillation. I will rerun this case in isolation to get a full 100 time steps.

For the restart files, my plan remains as described in the previous comment — rename the last two files of each completed run to solution_flow_00000.csv and solution_flow_00001.csv following the square_cylinder pattern.

Happy to proceed once you confirm this approach is acceptable.

[bigfooted]

The RANS case used INNER_ITER=300 for the restart generation run which explains the slightly faster initial transient decay compared to the full 2000 inner iter run.

Does it? What do the inner iterations do to enhance transient decay?
Your explanation sounds like you do not fully understand what is going on with inner and outer iterations. Can you study this once more, and come back to us and explain what you think the importance of more inner iterations is and what effect this has?

I think you're doing a great job here with validation, but I also think it is important that you understand what you are really doing so you can make knowledge based decisions. Ask chatgpt or whatever, but analyze the feedback/results yourself.

[pcarruscag]

100's of inner iterations per time step is not an acceptable configuration, you need to tweak the CFL and linear solver settings such that the relative residuals in each time step drop 3 orders of magnitude in about 20 iterations.

[Sahilll10]

The RANS case used INNER_ITER=300 for the restart generation run which explains the slightly faster initial transient decay compared to the full 2000 inner iter run.

Does it? What do the inner iterations do to enhance transient decay? Your explanation sounds like you do not fully understand what is going on with inner and outer iterations. Can you study this once more, and come back to us and explain what you think the importance of more inner iterations is and what effect this has?

I think you're doing a great job here with validation, but I also think it is important that you understand what you are really doing so you can make knowledge based decisions. Ask chatgpt or whatever, but analyze the feedback/results yourself.

Hi @bigfooted
You are completely right to push back on that. I went back and thought about it properly.

Inner iterations have nothing to do with how fast the physical transient decays. That was a wrong statement on my part. The physical transient — how quickly CL settles into a periodic oscillation — depends entirely on the flow conditions and how many real time steps have passed.
Inner iterations are purely numerical.
They drive the pseudo-time residual down within a single physical time step before we move forward.
More inner iterations means each time step is solved more accurately, but the rate at which the flow develops physically stays the same regardless.

What actually happened in my plot:
The RANS run with INNER_ITER=300 just had fewer completed time steps when I generated the plot, so the transient hadn't fully settled yet.

The actual effect of dropping from 2000 to 300 inner iterations shows up in the residual: with 300 inner iters the density residual reaches about -4.6 per time step, versus -6.8 with 2000.
The CL values at the same time step differ by less than 0.2% in this case, but that is specific to this flow —for harder problems, not fully converging each step can add up and affect the results

Sorry for the sloppy explanation earlier.

I will make sure I explain each thing before asking for review.

[Sahilll10]

100's of inner iterations per time step is not an acceptable configuration, you need to tweak the CFL and linear solver settings such that the relative residuals in each time step drop 3 orders of magnitude in about 20 iterations.

Hi @pcarruscag

I tried tuning the settings and want to show you the numbers before going further.
The main changes that helped were switching LINEAR_SOLVER_PREC from LU_SGS to ILU and raising CFL_NUMBER from 4 to 200. Here is the residual drop at Time_Iter=0 for both:
Before (CFL=4, LU_SGS):

Drop in 20 iterations: ~0.95 orders

After (CFL=200, ILU, LINEAR_SOLVER_ITER=20):

Drop in 20 iterations: ~2.13 orders

This is a significant improvement but still short of your 3 orders in 20 target.
I also tried CFL=500 and LINEAR_SOLVER_ITER=50 — both gave identical results, which tells me the linear solver is already converging within its tolerance and the bottleneck is the nonlinear outer convergence rate itself.

Could you point me toward what else I should adjust to close that remaining gap?

[pcarruscag]

That's good enough

[bigfooted]

Can you now update the regression tests with these settings?

[Copilot]

Pull request overview

This PR fixes several unsteady SU2 testcase configurations so they actually run in time-accurate mode (instead of silently behaving like steady runs), and adds them to the serial regression suite to prevent future regressions (per #2524).

Changes:

• Add missing unsteady controls (TIME_DOMAIN=YES, TIME_ITER) and remove deprecated EXT_ITER in three unsteady testcase cfgs.
• Correct solver selection for the SA turbulent case (SOLVER=RANS) and add SCREEN_OUTPUT fields needed for regression parsing.
• Register the three cases in TestCases/serial_regression.py as CI regression tests (unsteady=True, test_iter=1).

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 8 comments.

File	Description
TestCases/unsteady/plunging_naca0012/plunging_NACA0012.cfg	Enables true unsteady stepping + adjusts output; also changes some solver/runtime knobs.
TestCases/unsteady/pitching_naca64a010_rans/turb_NACA64A010.cfg	Fixes solver type for SA RANS + enables unsteady stepping/output; also changes some solver/runtime knobs.
TestCases/unsteady/pitching_naca64a010_euler/pitching_NACA64A010.cfg	Enables unsteady stepping/output; also changes some solver/runtime knobs.
TestCases/serial_regression.py	Adds three new unsteady regression entries so these cases are exercised in CI.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

CFL_NUMBER is increased from 10.0 to 200.0. This is a significant numerical change and isn’t described in the PR summary; please confirm it’s intentional for this testcase and consider adding a short note in the cfg explaining the choice.

[Copilot]

This changes LINEAR_SOLVER_PREC from LU_SGS to ILU without being mentioned in the PR description. Please confirm this is intentional and add a brief rationale, since it changes the testcase’s solver configuration beyond the unsteady fix.

[Copilot]

This config change includes runtime/solver-setup modifications beyond the PR description: INNER_ITER is reduced from 1000 to 50. Please confirm this is intentional for the regression/CI version of the case and add a brief rationale (or keep the original value if the intent is only to fix missing unsteady keys).

[Copilot]

This PR also changes the linear solver preconditioner from LU_SGS to ILU, which is not mentioned in the PR description. If this is meant to improve robustness/speed for CI, please document it; otherwise consider reverting to avoid altering the numerical setup beyond the unsteady fix.

[Copilot]

In addition to the unsteady keys, this hunk changes INNER_ITER from 2000 to 30. Since the PR description focuses on TIME_DOMAIN/TIME_ITER/EXT_ITER + solver selection, please confirm the INNER_ITER reduction is intentional and note the motivation (e.g., CI runtime) to avoid surprising changes to the case definition.

[Copilot]

CFL_NUMBER is increased from 4.0 to 200.0. This is a substantial numerical change and isn't called out in the PR description; please confirm it is required/intentional for this testcase (and ideally leave a short in-file comment explaining why this value is appropriate).

[Copilot]

This changes LINEAR_SOLVER_PREC from LU_SGS to ILU without any note in the PR description. Please confirm this is intentional and document the rationale, since it can affect convergence and performance characteristics of the testcase.

[Copilot]

This hunk changes INNER_ITER from 110 to 20 in addition to adding TIME_DOMAIN/TIME_ITER. Since the PR description doesn’t mention adjusting INNER_ITER, please confirm the reduction is intentional (e.g., to reduce CI runtime) and document it to avoid silently changing the testcase’s numerical setup.

[Sahilll10]

Hi
I have updated the regression tests with the tuned solver settings.
The RANS and Euler test_vals are taken from the CI Docker computed values (local serial build produces different residuals due to compiler diff). The plunging preconditioner was reverted from ILU back to LU_SGS since ILU caused divergence on the CI build for that case.
Final settings and test_vals:

RANS: CFL=200, ILU, INNER_ITER=30 → [-2.474001, -6.039495, 0.031041, 0.053671]

Euler: CFL=200, ILU, INNER_ITER=20 → [-1.864773, 3.545935, 0.035685, 0.035843]

Plunging: CFL=1.0, LU_SGS, INNER_ITER=50 → [-5.248321, 0.372499, 2.100860, 6.212394]

The restart files are pending , Should i add them in my next commit?

Please let me know if there are further adjustments required .