Add grad for LagrangeRefSpace{T,1,3}

[sbadrian]

Currently, it provides the function value and the curl. However, for discretization a Laplacian, the gradient would be needed, too.

I think that simply adding the gradient to the tuple shouldn't be a problem, should it?

[krcools]

The ad-hoc supply of derivatives has always bothered me. In the Mawell single layer it makes complete sense to have both the function value and the divergence. For now, I make the Laplacian like this:

Id = BEAST.Identity()
grad = BEAST.gradient

@hilbertspace u
@hilbertspace v

a = @varform Id[grad(v), grad(u)]

X = lagrangec0d1(Gamma)
A = assemble(a, X, X)

Moving forward we have to choose probabely one of:

• Complementing evaluation of shape functions with a maximal set of derivatives
• Supplying multiple evaluation functions for shape functions and let dispatch depend on the type of operator
• Solely depend on the above method. This opens new questions like what local space should the derivative be expressed in? Is there always a straightforward minimal choice for this?
• The approach @PaulOlyslager takes (see the section on composite operators in the dev version of the docs)
• Overload assembly for a LaplacianOperator to first take the gradient of test and trial functions and off-load the heavy lifting to the assembly of the identity (essentially automating the procedure above).

[sbadrian]

Complementing evaluation of shape functions with a maximal set of derivatives

I guess this could be done as quick solution at the price of a performance penalty. I am not sure how many function spaces are affected that would need several derivatives as does the LagrangeRefSpace{T,1,3}

Supplying multiple evaluation functions for shape functions and let dispatch depend on the type of operator
Should be also fairly easy to move to this, shouldn't it? Probably even code duplication could be avoided using nested (inline) functions?

Solely depend on the above method. This opens new questions like what local space should the derivative be expressed in? Is there always a straightforward minimal choice for this?

You mean computing the, for example, gradient of a function space as in your code snippet? I feel it somehow contradicts the logic of operators and handling "mixed" discretizations seems difficult.

The approach @PaulOlyslager takes (see the section on composite operators in the dev version of the docs)
What specifically do you have in mind?

I guess it would be interesting to also find a solution for linear combinations of operators so that it is automatically deduced what needs to be computed and it is only computed once for all operators. This seems, however, more difficult to attain quickly.