GitLab

They are needed for analytic assembly

Correct handling of gravitational flux contributions requires the
mpfa framework to be completely re-designed.

The Doxygen comment `//!` refers to the line after the comment. If
the comment should refer to the same line, `//!<` has to be used.

This implies that all processes use the same interaction volume on the boundaries. We typically
use the o-method on boundaries, where this is guaranteed.

we now have the following levels of type tags:

- basic numerical model
- linear solver type tag
- discretization scheme-specific type tag
- physics-related type tag (e.g. pmflow)
- problem-specific type tag

the dual grid index set now does not contain the data on the global scv indices
that are connected to the faces. The local data is only available in the iv index set.
This should be better for methods other than the mpfa-o method, as in those the local mappings
of the dual grid index set is maybe useless (e.g. for the mpfa-l scheme).

this commit furthermore introduces that the problem is given to the global containers
for volume variables and flux variables in the constructor.

TODO: implement ficks and fouriers law, as well as the interaction volume data handles
accordingly for problems involving diffusion/heat conduction

Dennis Gläser authored Feb 15, 2017 and Timo Koch committed Feb 17, 2017

by passing the implementation of the actual method's interaction volume type
to the o-method interaction volume we are able to overload functionalities in
derived classes and still use different interaction volume types on the boundary and
inside the domain. This was not possible through the property system as it was unclear
which interaction volume is the actual implementation.

Dennis Gläser authored Feb 13, 2017 and Timo Koch committed Feb 17, 2017

We now call the Implementation from the o-method interaction volume because we need
to incorporate some terms in the problems with facet coupling.
Todo: Problems using interior interaction volumes that inherit from the o-method
specialization AND use the o-method on the boundaries do not work at the moment. We
would have to tell the o-method the actual implementation somehow introducing a new
template parameter for the implementation.

Dennis Gläser authored Feb 07, 2017 and Timo Koch committed Feb 17, 2017

we do not incorporate the handling of lower dimensional elements on the facets
in the base laws etc anymore. We want to overload functionalities required to
realize the coupling in the mixeddimension-specific classes. The upwind scheme
is still to be modified!

the lambdas are used to obtain the tensors related to a law, i.e. an
expression for a flux (advective, diffusive, conductive). We now introduce
a lambda factory that passes lambdas for the different physical processes.

The flux variables cache now inherits from caches defined in the different laws.
These also define a respective filler class that is called when updating the flux
variables caches. That enables us to define different caches for different laws.

Dennis Gläser authored Jan 19, 2017 and Timo Koch committed Jan 27, 2017

The interaction volumes have to be instantiated with a valid fvGeometry etc and
during assembly they only exist temporarily for the transmissibility calculations.
Interaction volumes can now not be instantiated and stored globally anymore, but, why
would one like to do that. If global flux var caching is enabled, then the transmissibilities
are stored over the whole simulation time. This is the main thing one wants from them.

Dennis Gläser authored Dec 14, 2016 and Timo Koch committed Dec 16, 2016

We have to make sure that the provided diffusion coefficients are
greater than zero. Zero coefficients will end up degenerating the
local systems.

For non-zero neumann boundary conditions we did a scaling to recover
DgradU at the boundary from the prescribed flux. We don't do this anymore
and assume that when the UseTpfaBoundary property is set to false, that the
user provides -DgradU at the boundary instead of, e.g., mass fluxes.

The function to make the indices unique in the local sub-control entity seeds
was buggy and led to wrong outside scv faces in the assembly of the local matrices.

Furthermore, calling scvfTouchesBranchingPoint() for grids with dim = dimWorld would have led
to a segmentation fault.

Also, in the interaction volume, when getting the transmissibilities, we always have to compute them
again when coming from the outside face, as the normal vector of the outside face can always be different to
that of the inside face, even when not on a branching point.

for dim < dimWorld (i.e. 2 < 3), the algorithm for the setup of the interactionvolume seed is more complex
than the one for dim = dimWorld = 2. This commit introduces a forwarding to the more simple algorithm if the
face does not touch a branching point.