Assemble the implicit operators in an expression

[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

Details in PR #246

[bevanwsjones]

Is it not possible to keep the definition of the DLS outside of fvcc? I fully get that the actual discretisation should be associated with the spatial discretisation method - after all the Divergence, Laplacian, etc operators are spatial in nature, so it make sense their implementation details should be there. However, as an interface, the DSL itself feels like it should remain outside of fvcc. At least thats the way I would think about it.