Refactoring of the Linear Solver classes

[pcarruscag]

Proposed Changes

There has been talk about using external solvers in SU2. I am especially interested in this as due to the ill-conditioned matrices I get in structural topology optimization a direct sparse solver will probably be required.
One tricky issue with using external solvers is their compatibility with the discrete adjoint. Luckily in the reverse mode we do not differentiate the solver, only the operation A^-1 * b. Nevertheless currently all CSysVectors and CSysMatrices use su2double which makes them incompatible with external libraries and slower than in direct mode.
To address this issue I want to template the required classes such that we have the option (but not be obligated) to have CSysMatrices of passivedoubles in the discrete adjoint.
Moreover, I want to do some refactoring to make CSysSolve a proper class instead of an aggregate of functions. Currently we instantiate a CSysSolve whenever we need to solve a system, I think it would be beneficial to keep CSysSolve as a member of the classes that use it, so that for example, working memory used by Krylov methods is allocated only once.

Note: I am aware that @talbring started some work on this (and more) in the feature_template_linear_solver branch, I tried to pick up were Tim left of but it was too much (a lot changes in one year). I really like the refactoring he was doing and will try to bring as much as possible into this, but I need to do it in smaller steps.

Now this PR deals with some of the aforementioned refactoring, namely:

• CG, BCGSTAB, and GMRES have their working vectors and matrices as members of CSysSolve and allocate them only on the first call.
• CSysSolve is now a member of CSolver and CVolumetricMovement.
• BCGSTAB uses two fewer vectors than before and the "p" and "v" vectors are initialized to 0 instead of "b" (I think this was a small bug?).
• CSysSolve takes a "mesh deformation" flag at construction so that Solve can be called by CSolver and by CElasticityMovement, before the latter decided what Krylov method to call in place, kind of duplicating what is done by Solve. I did not do the same for CVolumetricMovement because there the differentiation is handled differently. This also allowed SetExternalSolve_Mesh to be merged with SetExternalSolve.
• Now when CSysSolve sets the external solve it passes itself (this) so that CSysSolve_b re-uses it in the reverse path instead of instantiating a CSysSolve every time.
• Part of CSysSolve_b::Solve_b was moved to CSysSolve::Solve_b to allow CSysSolve_b::Solve_g to be dropped. CSysSolve_b::Solve_b now simply prepares the RHS of the adjoint system and calls Solve_b on the pointer it gets through the AD data handler. I decided not to shoehorn Solve_b into Solve as that would be a bit unreadable.

I will now start tackling the templating part, and once I can demonstrate that that works, start bringing in Tim's refactoring.

Related Work

#648
feature_template_linear_solver

PR Checklist

• I am submitting my contribution to the develop branch.
• My contribution generates no new compiler warnings (try with the '-Wall -Wextra -Wno-unused-parameter -Wno-empty-body' compiler flags).
• My contribution is commented and consistent with SU2 style.
• I have added a test case that demonstrates my contribution, if necessary.

[pcarruscag]

Residuals changed in testcase transonic_rotor_2D, I do not know why since it uses FGMRES and in that method I only changed the allocation.
I ran the case to convergence and compared the output, everything matches so I updated the residuals.

[talbring]

@pcarruscag All of the things look reasonable. The long-term goal would be to really have a generic interface for the linear solvers (at least that was my goal) so that we don't have to distinguish between mesh deformation and flow solution anymore inside of the CSysSolve class. Rather we pass objects for the solver and preconditioner and other options to the constructor. We can merge this in as soon as the tests pass.

[rsanfer]

Tests are passing, and I think this is a very valuable contribution, so let's get it merged in. Thanks, @pcarruscag .

[pcarruscag]

@talbring that is definitely the long term goal, this was only the first step to make the templating simpler.
Thanks @rsanfer.