On 10/27/25 04:44, Lukas Dreyer wrote:
I have found two existing implementations for Nédélec elements on hypercubes:
FE_Nedelec and FE_NedelecSZ.
From my understanding, FE_Nedelec requires globally oriented meshes, where
each local edge orientation matches the global orientation.
In contrast, FE_NedelecSZ incorporates the global orientation into the finite
element itself and resolves sign conflicts by multiplying incorrectly oriented
DoFs by -1.
I am currently deciding which base class would be most suitable for my
implementation.
Is there a better option than deriving directly from FiniteElement?
You can't guarantee orientations of triangles and tetrahedra (and hexahedra)
in the same way as you can for quadrilaterals, and so you have to deal with
edge orientations in both 2d and 3d if you want these elements for simplex
meshes. As a consequence, the only real choice you have is to go the route of
the FE_NedelecSZ element.
Both FE_PolyTensor and FE_Simplex_Poly seem like reasonable starting points.
However, from my initial review, FE_Simplex_Poly only takes
unit_support_points in its constructor, and I am unsure how it supports
generalized support points.
For the FE_PolyTensor approach, I could refer to FE_Nedelec, but I am not
certain whether this approach is compatible with a local reorientation strategy.
I would greatly appreciate any insights or recommendations on how to implement
the simplicial linear nedelec element with minimal code duplication.
As you discovered, there is quite a wild west out there with these
intermediate classes. I have to admit that I've long lost an overview of what
they all do, and I suspect that others feel the same. If you think that one
intermediate class *almost* does what you need, you can always extend it to do
what you need.
I'm afraid I don't have much more advice to give. If I had to take on this
project, I would start by trying to understand what the various intermediate
classes do and how they differ (and in the process probably augment the
documentation in many places writing down what I find). One of the options you
always have is to derive from an intermediate class, but override some of the
virtual functions in your derived class. The overriding function can of course
call the function in the base class, and then if necessary fix up some of the
base class's output -- say, adjusting signs that were not set correctly by the
base class.
It's possible that some of the others on this forum have more advice, and I
hope that they would speak up in that case!
Best
Wolfgang
--
------------------------------------------------------------------------
Wolfgang Bangerth email: [email protected]
www: http://www.math.colostate.edu/~bangerth/
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups "deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/dealii/518394dd-f100-4bc7-b1b2-6bb338fae828%40colostate.edu.
