Implementing a Nédélec Finite Element for Triangles and Tetrahedra

[Lukas Dreyer]

Dear deal.II community,

I am currently exploring the implementation of a Nédélec finite element for triangles and tetrahedra.

My focus is on linear elements, where all DoFs are located on the edges of the element. For triangles, the basis functions are defined as:

p_1 = (1 - y,  x),  p_2 = ( -y ,  x),  p_3 = (  y , 1 - x)

For the construction of the linear functionals N_i, I define the tangential vectors t_i and edge midpoints q_i as follows:

t_1 = (1, 0),  t_2 = (-1, 1),  t_3 = (0, 1)

q_1 = (0.5, 0),  q_2 = (0.5, 0.5),  q_3 = (0, 0.5)

Then, with N_i(p) = p(q_i) · t_i, we obtain N_i(p_j) = δ_ij.

These functionals require generalized support points, as the functionals are not point evaluations.

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?

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.

Best regards,
Lukas Dreyer

[Wolfgang Bangerth]

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: bang...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/

[Siarhei Uzunbajakau]

Dear Lukas,

I am also interested in the Nedelec finite elements. Unfortunately, I have absolutely no experience in implementing new finite elements, so I cannot help you with it.  I strongly suspect  that I will have to learn how to do that in the future as I would like to make a few finite elements that will be handy in combination with FE_NedelecSZ.

I have never tried the finite elements on triangular and tetrahedral cells in deal.II so I cannot tell you what is going on with cell orientation there. I know that the deal.II library compensates for edge/face orientation in the case of the FE_Nedelec finite elements on the quadrilateral and hexahedral cells in 2D and 3D if the order of the finite elements is less than five. It does the compensation by remembering the orientation of each edge and face. The mismatch in edge orientation is compensated by flipping the sign of the shape function. The mismatch in face orientation is compensated by a table lookup. There are eight possible face orientations and eight entries in the table. Each entry encodes which shape functions to swap and which shape functions needs to flip sign. The orientation compensation  of the 2D FE_Nedelec finite elements is done in source/fe/fe_poly_tensor.cc. The 3D FE_Nedelec finite elements  are compensated in source/fe/fe_nedelec.cc. See comments in these two files for more details.

I prefer not to think in terms of global cell orientation. Local orientation is good enough for me. Cells that can map themselves onto the reference cell correctly is all we need. In my opinion the cells are mapped correctly onto the reference cell in 2D and 3D if element degree <5, see test file tests/fe/fe_nedelec_face_edge_orientation.h . I do not experience any problems with the global mesh orientation and sign conflicts under these conditions.

The classical FE_Nedelec finite elements have a disadvantage: they do not work quite well (upset De Rham complex) if the degree of the finite elements varies from cell to cell (p- adaptation), see for example introduction to this article,  DOI:10.1016/S0898-1221(00)00062-6, or first pages in the thesis of Sabine Zaglmayr (listed in the deal.II bibliography page). I guess the main reason why people create new Nedelec finite elements, such as FE_NedelecSZ, is the desire to overcome this disadvantage.  Although, I must admit that “incorporating the global orientation into the finite element itself and resolving sign conflicts” is a cool feature of FE_NedelecSZ. The FE_Nedelec implements this cool feature by compensation of the mismatch in the edge/face orientation as described  above.  From the user’s stand point, the real significant difference between FE_Nedelec and FE_NedelecSZ is that FE_NedelecSZ allows a nonuniform distribution of the degree of the finite elements over the mesh. The degree of the FE_Nedelec finite elements must be uniform all over the mesh.

Do not be discouraged by the above mentioned disadvantage of the FE_Nedelec finite elements. In my humble opinion, one can have a lot of fun even if the degree of the finite elements is uniform all over the mesh.

Please, let me know if you have made any progress in creating new finite elements. I am interested in this topic and will be more than happy to learn from your experience.

Kind regards,
Siarhei

[Thomas Wick]

Dear Lukas,

would it not help to talk to Sebastian Kinnewig who implemented recently 

a lit of this stuff for quads and hexes? 

Of course for your question 

Both FE_PolyTensor and FE_Simplex_Polyseem 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 also assume that the core deal.II developers have a reasonable suggestion.

Best regards, Thomas

—

+++++

Prof. Dr. Thomas Wick

www.thomaswick.org

Sent from my iPhone

On 30. Oct 2025, at 14:21, Siarhei Uzunbajakau <s.uzun...@gmail.com> wrote:

Dear Lukas,

--
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 dealii+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/dealii/daed4470-8e65-49d8-8f3a-284f80a038c6n%40googlegroups.com.

[Siarhei Uzunbajakau]

Dear Thomas,

I would like to congratulate you with your new just accepted article. The results with your new extended FE_NedelecSZ finite elements look magnificent!

In my humble opinion, the results for the classical FE_Nedelec finite elements in the first column of Fig. 11 look somewhat bleak. This could be due to the fact that the FE_Nedelec finite elements were not fully implemented in deal.II 9.5.2, see the attached screen short. That is, all the code needed for compensation of the sign-conflict was in place, but the permutation and sing-flip tables were initialized to zeros (meaning do nothing). The versions of deal.II released after 29.01.2025 contain correct initialization of the tables for the finite elements of the order <5. I have tested the FE_Nedelec finite elements with the new tables on globally refined meshes. The results look good. Now I am busy verifying them on locally refined meshes.

I was wondering, will you be willing to generate the images in the first column of Fig. 11 with the last version of deal.II as a test of the new compensation tables?

Thanks in advance!

Kind regards,

Siarhei

[Sebastian Kinnewig]

Dear Siarhei Uzunbajakau,

concerning your exchange last week with Thomas Wick, I can add as follows:

The first preprint of the paper mentioned above was already published on arXiv in 2023. At that time, the FE_Nedelec class could not be applied to non-orientable grids (as demonstrated in Fig. 11). Therefore, I reran all the tests using the latest version of DEALII, and I am happy to report that the FE_Nedelec class now handles non-orientable grids and hanging nodes correctly. I implemented a convergence test, which is part of the DEALII test suite, that also confirms your implementation handles non-uniform grids correctly.

However, I noticed that the FE_Nedelec class still yields incorrect results for "balls" (e.g., a geometry generated by GridGenerator::hyper_ball_balanced).

As the person who implemented the hanging-edge and hanging-face support for Nédélec elements, it's commendable work! I know how hard it is.

However, precisely because I know how cumbersome it is to deal with the orientation problem for the Nédélec elements, my question arises: is there a specific reason you chose to reimplement it, instead of using the existing implementation?

As additional background information for our paper, I would like to explain why I chose the FE_NedelecSZ class. The FE_NedelecSZ class (implemented in 2017/18 by R.M. Kynch and P.D. Ledger, as described in the corresponding paper) already provided support for non-orientable grids and arbitrary polynomial degrees. Moreover, the FE_NedelecSZ leads to a better sparsity pattern. Additionally, discussions on the DEALII GitHub page (see https://github.com/dealii/dealii/pull/2240#issuecomment-388184286) indicate that the FE_Nedelec class should be removed in the future. Therefore, I decided to continue the work on the FE_NedelecSZ class. As my implementation is based on the work of Kynch and Ledger, it also works for arbitrary polynomial degrees.

Best,

Sebastian

[Siarhei Uzunbajakau]

Dear Sebastian,

Thank you for running the tests! I am still testing FE_Nedelec finite elements and the information you have kindly provided is very useful to me. May I ask you to share the details of the failed numerical experiment with the GridGenerator::hyper_ball_balanced so I can reconstruct the experiment and attempt to fix the problem?

You give too much credit to me. I have not reimplemented FE_Nedelec. I just inserted the code that initializes the permutation and sign-change tables into already existing implementation. The existing implementation was already capable of resolving sign-conflict. One component was missing: initialization of the tables. I do not know who has implemented FE_Nedelec.

I think your choice to use FE_NedelecSZ is perfectly legitimate: they are simply superior to FE_Nedelec.

The reason why I use FE_Nedelec and not FE_NedelecSZ is the following. To be happy I need four finite elements that span the four function spaces of the De Rham complex. I think that FE_Q, FE_Nedelec, FE_RaviartThomas, and FE_DGQ span the four spaces. I could attempt to replace FE_Nedelec with FE_NedelecSZ in this sequence (let’s forget about exactness for a moment),  but I expect that the result will be somewhat clumsy. If I understand it correctly, FE_NedelecSZ are hierarchical finite elements while FE_Q, FE_Nedelec, FE_RaviartThomas, and FE_DGQ are normal, non-hierarchical. I think that having one type of hierarchical finite elements among three non-hierarchical is less practical. Furthermore, to do the replacement, I need a compelling reason why FE_Nedelec could not be used. I have not found one. I must confess, if all four types of the finite elements (the complete sequence) from the thesis of Sabine Zaglmayr have been already implemented, I would be gratefully using them as well. At this moment only one, FE_NedelecSZ, out of four is implemented.

Yes, I have seen the discussion about removing the FE_Nedelec in the future. I feel sad about it: having more advanced finite elements, FE_NecelecSZ, does not mean we need to ditch the immortal classic.

You article illustrates a magnificent achievement. Now, thanks to you, we at last have hp-capable curl-conforming finite elements. I think many people, myself included, will be interested in how to apply  your finite elements correctly.  Are you planing to convert the results from your article into a deal.II tutorial?

Kind regards,
Siarhei

[Wolfgang Bangerth]

On 11/4/25 07:37, Sebastian Kinnewig wrote:
> herefore, I reran all the tests using the latest version of DEALII, and
> I am happy to report that the FE_Nedelec class now handles non-
> orientable grids and hanging nodes correctly. I implemented a

> convergence test <https://nam10.safelinks.protection.outlook.com/?
> url=https%3A%2F%2Fgithub.com%2Fdealii%2Fdealii%2Fblob%2Fmaster%2Ftests%2Ffe%2Ffe_nedelec_sz_hanging_nodes_convergence.cc&data=05%7C02%7CWolfgang.Bangerth%40colostate.edu%7Ce2cfccb6e8b942a9f27108de1bafa6c8%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C638978639429271878%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C&sdata=Ur06sYXutwv8MRDBxXP1kzjksok4xO%2BhiopmSp7CBME%3D&reserved=0>, which is part of the DEALII test suite, that also confirms your implementation handles non-uniform grids correctly.

>
> However, I noticed that the FE_Nedelec class still yields incorrect
> results for "balls" (e.g., a geometry generated by

> GridGenerator::hyper_ball_balanced <https://
> nam10.safelinks.protection.outlook.com/?
> url=https%3A%2F%2Fdealii.org%2Fcurrent%2Fdoxygen%2Fdeal.II%2FnamespaceGridGenerator.html%23a1a07e4609d568267cab4a2f0414cd913&data=05%7C02%7CWolfgang.Bangerth%40colostate.edu%7Ce2cfccb6e8b942a9f27108de1bafa6c8%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C638978639429292138%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C&sdata=fYlOOUFrd72AZ3W5HQVY%2FknCll9NDhNS0E76Vj4HEL8%3D&reserved=0>).
>

Hi Sebastian:
out of curiosity: Are these tests that are part of the deal.II test
suite? If not, could I interest you two on perhaps making them into a
pull request that could go into the test suite?

Best
W.

[Wolfgang Bangerth]

On 11/4/25 12:30, Siarhei Uzunbajakau wrote:
>
> Yes, I have seen the discussion about removing the FE_Nedelec in the
> future. I feel sad about it: having more advanced finite elements,
> FE_NecelecSZ, does not mean we need to ditch the immortal classic.

You will have noticed that pull request #6941 was opened in 2018 and has
not been merged in the seven years since then because FE_NedelecSZ was
always missing features that FE_Nedelec has. Perhaps once the two are
truly interchangeable, we will throw out one in favor of the other, but
until then I don't think you have to fear that FE_Nedelec will be
removed :-)

Cheers
W.