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