This is a first draft of an FEM framework. Currently, major limitations/assumptions are:
- assumes Standard-Galerkin approach
- assumes non-composite dune function space bases
I have tried to incorporate suggestions stemming from the discussion in #884, in particular it is:
The state of the grid variables was always dependent on the problem (e.g. due to BCs) and a current solution. Nevertheless, we had grid variables and problem and cursol as arguments in several assembly-related functions. In particular, we did
assembler.assemble(curSol). The assembler introduced here fulfills this interface (for compatibility with NewtonSolver), but does not use curSol. Instead, the assembler is instantiated with grid variables, which are updated with a solution and a problem. Thus, the assembler takes the solution and problem from the grid variables. So, you would want to do
Assembler assembler(gridVariables); assembler.assemble(). This could help implementing other time stepping schemes, where you create grid variables on different time levels (stages), make an assembler from them and let it assemble the stage. The assembler is basically a copy of
FVAssembler, which was almost general and non fv-specific. There is one piece of commented code related to parallelism with box (with a todo in the comment) which has to be figured out still.
Local assemblers are now a
localViewof the assembler, no which you then call
bindwith only an element. The problem & current solution are extracted from the grid variables with which the assembler was instantiated. This guarantees that a wrong combination of problem state, solution state and grid variables state is passed to it.
None of the classes use the property system anymore. I wrote a little test solving a poisson equation, which completely works without the property system. See test/discretization/fem/poisson. Therein, a problem and local residual have to be implemented. Currently, I implemented it in a "Dumux conforming" way, also implementing a spatial parameters class that stores the tensor and an "IntegrationPointVariables" class (the equivalent of vol vars in fv schemes), which hold the tensor at an integration point. The test implementation could be simplified very much if the custom local residual simply called
problem.getTensor()or so - that would get rid of the spatial params and the integration point variables implementations. I did it this way for now to illustrate the complete workflow for implementing a new model and test.
All of this is subject to discussion, and all new headers have "TODOs" all over the place which can be discussed.