[WIP] Add nested preconditioner: FGMRES with BiCGSTAB

[eorbay-metu]

Proposed Changes

This draft PR introduces a nested Krylov solver setup in SU2.
The main contribution is enabling FGMRES to use BiCGSTAB as an inner preconditioner.
The aim is to improve convergence robustness and efficiency for stiff linear systems, especially in high-Re/low-Mach cases.

Changes include:

Modifications to the linear solver routines (CSysSolve.cpp, CSysSolve.hpp), CConfig.cpp and option_structure.hpp

Added new functions to allow BiCGSTAB calls inside FGMRES iterations.

Extended configuration parsing to accept LINEAR_SOLVER= FGMRESandBCGSTAB2

Related Work

Builds upon existing Krylov-based solvers already implemented in SU2 (FGMRES, BiCGSTAB).

Complements discussions on improving solver performance for stiff CFD problems.

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.

[pcarruscag]

Hi, the nice of implementing this feature is to wrap the inner linear solver into the generic preconditioner operation that is passed to FGMRES (or any other solver).
Please give it some thought, we can talk more in one of the weekly developer meetings.

[eorbay-metu]

@pcarruscag Thank you for the suggestion! I understand your point about wrapping the inner solver into the generic preconditioner interface for broader reuse.

In my initial implementation I integrated BiCGSTAB directly inside FGMRES rather than as a separate preconditioner function, because my primary goal was to quickly evaluate the nested Krylov approach in SU2 and confirm its effect on convergence. This way I could test the functionality without restructuring the existing preconditioner hierarchy.

I see the benefit of a cleaner design by wrapping it into the preconditioner interface, and I will look into how to move in that direction. I would be glad to discuss this further during one of the weekly developer meetings.

[bigfooted]

Hi, great work, can you also add a small testcase that uses the new function? Looking forward to hearing more about it at the conference.

[bigfooted]

Hi @eorbay-metu , What needs to be done for the PR to get out of draft mode? Can you add a testcase that uses the new FGMRES/BiCGSTAB preconditioner (modify an existing testcase)

[github-advanced-security]

CodeQL found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.

[eorbay-metu]

Hi @bigfooted , thanks for checking in! I'm currently working through the remaining CI issues. The compilation and regression tests are green, but the Code Style workflow is still reporting formatting errors. I’m planning to run clang-format/pre‑commit locally and push a cleaned-up commit to address those shortly.

To show that the new nested FGMRES/BiCGSTAB preconditioner works, I’ve prepared a modified version of an existing RANS/NACA test that uses this nested solver.

Once the formatting is fixed and the new test case is integrated, I’ll take the PR out of draft and open it up for full review. Thanks for your patience and feedback — if you have a particular scenario you’d like me to cover, please let me know!

[bigfooted]

Thanks, looks like your commit fixed it, and do not worry about the codefactor issues. For the regression tests, we would just need a case that uses your implementation, so a simple naca0012 airfoil that we already have (or if you have a simple alternative) can be used. It should run fast, and just 10 iterations or so. If you also have a testcase that can be used in the Verification & Validation tests or as a tutorial, that would be great as well. Just use what you have at the moment.

[pcarruscag]

If the plan is to integrate this PR in the develop branch, my initial comment needs to be addressed.
I would also like to see some results on the effectiveness of this nested preconditioning.

[bigfooted]

SU2 conference presentation:
https://drive.google.com/file/d/1jua_BXhRtSlb437Ydg_4pI76bHKaRrZ6/view

Next week on Wednesday at 16:00 CET we have a developer meeting at https://meet.jit.si/SU2_DevMeeting

[pcarruscag]

Yes, I know, it would have to be more compelling than that to get me to ok copy-pasting code 😄

[bigfooted]

Yes, I know, it would have to be more compelling than that to get me to ok copy-pasting code 😄

thus spoke the gate-keeper. :-)

[eorbay-metu]

Yes, I know, it would have to be more compelling than that to get me to ok copy-pasting code 😄

Haha, fair enough 😄
Thanks for pointing it out — I'll revise accordingly shortly.
Hopefully this time it will be worthy of passing the gate-keeper’s check!