Base class for transported scalars

[TobiKattmann]

Proposed Changes

Hi all,

The general idea for this PR can be cited from @pcarruscag in #1226:

The ideia would be to create a CFVMSolverBase (in the style of the one for flow solvers) to cover:

    Turbulence solvers;
    Heat solver;
    Radiation solver;
    General passive/active scalar solvers;
    Eventual transition solvers;

The starting point would be the current base turbulence solver.

Right now the only things I did were (i.e. don't fear the large diff)

• create CScalarSolver/Variable files/classes and scalar_convection/diffusion/sources files and fill them with the contents of the CTurb* or turb_* files.
• Make CScalarSolver/Variable the parent class of CTurbSolver/Variable
• Delete pretty much everything from CTurb* or turb_* files except for some constructors

So far it compiled and some local regression testing showed no problems, lets see what the CI pipeline has to say about this

Now with this additional class introduced the actual works begins:

• figure out what is a reasonable interface in CScalar* to unify transported species and turb-models (and the other solvers probably)
• code this common interface and push all turb-specific things back into the respective files (that is why I didn't git mv )

In order to keep this somewhat limited I would focus on porting the Turbsolvers to the new structure (however that might look, but looking at #1223 is what I'll do first) and maybe a simple transported passive scalar or so. We want the turb solver to be integrated under that Scalar-class which is arguably what most/all people use, that's why I want to have in this work at the beginning. We also have quite a few RANS Testcases so it is directly visible if something in the actual computation is changed.

In case there are comments, ideas foreseeable stepping stones from experience please let me know here.

Related Work

#777 by @economon which is the initial push towards this separate scalar solver class for additionally transported scalars (not merged)
#1223 by @danielmayer @bigfooted which builds up on #777 and extends it to its needs (but does not support the turb solvers e.g.)
#1226 by @oleburghardt - In this PR is a discussion on creating the structure which this (and following) PR('s) try to achieve
#1332 by @mheimgartner - implementing multi component flow (or analytic mixing properties of said multicomp flow). That PR is built upon #1223 but will merge this PR (once it is done) and throw out all additional changes in order to be merged into develop without relying on feature_flamelet

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, or simply --warnlevel=2 when using meson).
• My contribution is commented and consistent with SU2 style.
• 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.

[TobiKattmann]

Still WIP but with that in the title the regression status behind each commit is always "unfinished" because WIP-check-bot does that. Now that we have Draft-PR I guess we dont WIP anymore tbh

[pcarruscag]

It helps me with the manual edit of the release notes, to know what was not merged yet.

[pcarruscag]

Awesome work 👍 can't wait to see the crash diet that some solvers are about to go on.

[TobiKattmann]

Thanks @pcarruscag for making this PR a lot better.

@bigfooted @danielmayer @mheimgartner
To layout future steps as discussed after this merge:

1. Merge these changes into feature_flamelet (and then feature_multicomp). Therefore the CScalar* things that are currently present in these branches will be renamed to CLegacyScalar* to not overwrite files. This has the advantage that those branches are kept up-to-date with develop.
2. Implement a rudimentary (passive) CSpeciesSolver (specifically does not contain multicomponent mixing from [WIP] Composition dependent fluid properties for multicomponent flow  #1332 ) and merge that. Finding a good (validation) Testcase would be great here.
3. Extend the CSpeciesSolver by [WIP] Composition dependent fluid properties for multicomponent flow  #1332 mixing models. Either by cutting away all the flamelet specific parts or by porting the additions to a new PR.
4. Make feature_flamelet switch to the new structure. This is an in-place change as both implementations are then present but just one will be kept. This will shrink the PR size of [WIP]: Flamelet progress variable (FPV) model #1223 by quite a bit

Additionally the heat and radiation solver should be ported into this new structure, but that is independent work.