[Dune] localFiniteElement for C1

[Carsten Gräser]

Dear Elisa,

Am 31.08.2015 um 15:58 schrieb Elisa Friebel:
> Dear Dune-Developers,
> 
> I'm interested in implementing C1-Macro Elements within the Dune-Framework.
> 
> Since the global degrees of freedom correspond to derivatives, C1
> (Macro) elements do not form an affine family. Hence, the implementation
> of a Dune localFiniteElement is not sufficient.
> As far as I see, in the literature are two approaches,
> either the implementation of a reference element and providing data* for
> the transformation (as for example done in libmesh [1])
> or direct spline evaluation depending on grid information such as
> vertices, normals etc.
> 
> Is there any already existing infrastructure in Dune suitable for one
> these approaches? Or is there anyone else currently working on similar
> features?
the LocalFiniteElement interface in dune is currently not sufficient
to model C1 elements properly for several reasons:

a)The interface is designed such that you store the LFEs and return
  them by reference. This is a major issue if the basis functions
  differ from element to element.
b)Evaluating higher derivatives is inconvenient.
c)We currently don't have an interface for differentiable functions
  that would be needed to properly define the interface of local
  interpolation.

One may also think of implementing C1 elements as
GlobalFiniteElements that are generated on the fly
and returned by value, solving a). Furthermore GFEs
improve on b) by having a slightly more convenient
interface for higher order derivatives. But notice
that the GFE interface is (I'd say _highly_) experimental.

All this aside, I know that Maren-Wanda Wolf and Tobias Kies,
both here at FU Berlin, have implemented the Morley-element
(nonconforming C1, triangles) and the Bogner-Fox-Schmidt-element
(conforming C1, quadrilaterals), respectively. However,
both implementations are experimental, because the
former hacks around a) and b), whereas the latter is
tied to YaspGrid using knowledge on its implemen-
tation-defined element orientations.

The main reason for those shortcomings, is that we never
really discussed the needs of FEs with higher order regularity
requirements. Please notice that there is significant progress
on c) going on in the dune-functions module. I also hope, that
we can discuss this on the upcoming developer meeting.

Best,
Carsten






-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20150831/f4796d8d/attachment.sig>