By looking at the possible values of the condition.

I have a case where visiting has a side effect that I want to avoid.
Also spares work.

This options enables to generate jacobian apply methods regardless
of the `matrix_free` option. If `matrix_free` is set to true,
`generate_jacobian_apply` is also set to true. This option replaces
`matrix_free` in all contexts except in the selection of the solver.

We previously used bool() on the constraints expression to find
out whether we need to use the DIrichletConstraintsAssembler.
However, UFL does the stupid thing of evaulating

bool(eq(x[0], 0))

to False, because x[0] and 0 are obvioulsy not the same. Veeeery
bad behaviour for a symbolic language.

Matrix inversion at code generation time does only work to
a very limited extent (up to n=4). We can instead assemble
the tensor in C++ and invert it there (e.g. using Dune::FieldMatrix)

Calculate the evaluation and jacobians of geometry mappings of cells
using sum factorization. By avoiding all geometry mapping of intersections
we can avoid the face-twist problem and just make the grid consistens (not
yet done).

TODO:
- Make grid consistent
- Vectorization
- 3D

Not yet implemented:

- Vectorization of quadrature loop
- Anisotropic amount of quadrature points per direction

René Heß authored 6 years ago and Dominic Kempf committed 6 years ago

Probably not the solution we want to have in the long run but right
now it is not possible to have a backend switch for
default/blockstructured/sumfact. This way the old code should behave
the same way as before and it is possible to switch between those
three things.

Note: This is still structured for now

Probably not the solution we want to have in the long run but right
now it is not possible to have a backend switch for
default/blockstructured/sumfact. This way the old code should behave
the same way as before and it is possible to switch between those
three things.