Dsl/implicit operators

[HenningScheufler]

Motivation

The DSL needs to handle implicit operators.

This PR handles strategy how to assemble the linear system and proposes architectural changes to the current design

Assumption

• the sparsity pattern is identical for all operators in the DSL

Consequences

• the linear system needs an identifier, which sparsity pattern is used --> currently a std::string (for now)
• the DSL is heavily linked to the cell-centered finite volume method
• the implicit source terms and temporal operators use the same sparsity pattern, despite being diagonal matrices

Tradeoffs

A long-term goal of NeoFOAM is to build a multi physic solver, the current assumption is that every region as its own physics with its on strategy to solve PDE's. The coupling between the regions would be via the boundary conditions.

Pro

• simpler design
• simpler implementation of the operators and DSL as the data structures are know
• increased performance: operators and expression know which numerical method they support and can optimize the performance (e.g. fvcc --> flux-based summation and other strategies to compute the operators depending scaling factors)

Contra

• Abstraction needed to accumulate the different regions into one coupled system

Recommendation

Currently, only one numerical method is supported (fvcc) and the coupling between the methods, will be tackled later. v0.4+. Defining a general abstraction, how the DSL works for every numerical method is complex and is a tradeoff between universality and performance.

A DSL should be more tightly coupled to a specific method --> e.g. move dsl folder into finite volume

A general abstraction, how the different linear system and rhs should be coupled over the regions seems still feasible as it only requires the concatenation of each linear system. However, this should be tackled if other PDE solution strategies are implemented

[HenningScheufler]

@greole @bevanwsjones @MarcelKoch

Please write your general comments into the issue #248

Code review should still be done in the PR. This makes it easier to track the required substeps. Sadly, PR cannot be added as subissues

Note: I will summaries the decision in the PR description

[github-actions]

Deployed test documentation to https://exasim-project.com/NeoFOAM/Build_PR_246

[greole]

some quick comments

[greole]

i think that isn't even necessary inside the NeoFOAM namespace you should be able to use just la::

[greole]

why is sparsityPattern a string?

[greole]

maybe a enum is better?

[HenningScheufler]

This will be merged in the stack/implicitOperator branch improvements can be added by seperate PR into stack/implicitOperator