Add support for Bernstein interpolation

[lijas]

It could be interesting to add support for bernstein polynomials. In general, they should give the exactly same result as Higher order lagrange interpolations, but they differ from lagrange interpolations in that they are not interplatory at the interior nodes. This breaks some assumptions in the code, for example when adding non-homogenous dirichlet conditions, or in the apply_analytical! functions (and maybe more).

So they could be added as a nice way to check for correctness :)

Fourth order bernstein bases:

[KnutAM]

That is an interesting issue/test case indeed!

I actually hit a similar issue in #798, since the dofs are associated with edges and faces, and not nodes. There I simply defined the reference coordinates as NaN, which makes it work for the homogeneous Dirichlet BC case, but maybe not the best way...

For apply_analytical! we already note in the docstring that it only works for "nodal finite elements", an option here could be to add a trait to interpolations stating if they are nodal or not.

But how do Bernstein bases break BC values/ Dirichlet boundary conditions? Don't they only require that it is interpolatory on the boundary of the cells, which this basis looks to be?

[lijas]

The reason Bernstein does not work for non-constant dbc (for example f(x) -> x*2 or something) is because we assume that we can directly set the dof values a_i(as in u(x) = \sum N_i(x) a_i) in update!. But I dont think this is correct for the inner dofs because they are not interpolatory. (It will work for constant dbc though (like f(x) -> 2 or 0), because ssum(N_I) = 1`)

[termi-official]

The DG stuff has literally the same issue, which we currently bypass with some "hacks".

[lijas]

What hacks are that? I think it was pretty clever to introduce dirichlet_face_indices.

[termi-official]

I also kinda like the idea, but then it does not work for most of the DG elements, because usually the dofs are not on the faces.

[fredrikekre]

But would you enforce Dirichlet BC via hard constraints for those interpolations or penalize the jump instead?

[termi-official]

The penalty approach can be implemented by users anyway, so this is not a big issue from my perspective. :) I would like to have some kind of hard enforcement, but I am not sure how exactly this could be achieved. I just wanted to note that this might boil down to the same issue.