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 On Tuesday, November 4, 2025 at 3:37:10 PM UTC+1 [email protected] wrote: > > 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 <https://arxiv.org/abs/2306.01416> in 2023. At that time, the > FE_Nedelec > <https://dealii.org/current/doxygen/deal.II/classFE__Nedelec.html> 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 > <https://github.com/dealii/dealii/blob/master/tests/fe/fe_nedelec_sz_hanging_nodes_convergence.cc>, > > 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://dealii.org/current/doxygen/deal.II/namespaceGridGenerator.html#a1a07e4609d568267cab4a2f0414cd913> > ). > > 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 <https://doi.org/10.1016/j.compstruc.2016.05.021>) > 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 > > [email protected] schrieb am Freitag, 31. Oktober 2025 um 04:47:07 > UTC+1: > >> 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 >> >> >> On Thursday, October 30, 2025 at 2:42:22 PM UTC+1 Thomas Wick wrote: >> >>> Dear Lukas, >>> >>> would it not help to talk to Sebastian Kinnewig who implemented recently >>> >>> [image: default_cover.png] >>> >>> Algorithmic Realization of the Solution to the Sign Conflict Problem for >>> Hanging Nodes on Hp-Hexahedral Nédélec Elements | ACM Transactions on >>> Mathematical Software <https://dl.acm.org/doi/10.1145/3766903> >>> dl.acm.org <https://dl.acm.org/doi/10.1145/3766903> >>> <https://dl.acm.org/doi/10.1145/3766903> >>> >>> >>> 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 <[email protected]> >>> wrote: >>> >>> 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 >>> On Monday, October 27, 2025 at 11:44:52 AM UTC+1 Lukas Dreyer wrote: >>> >>>> 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 >>>> >>>> >>>> -- >>> 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/daed4470-8e65-49d8-8f3a-284f80a038c6n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/dealii/daed4470-8e65-49d8-8f3a-284f80a038c6n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> -- 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/af0742e4-491c-4b1e-a6af-d29ead4a27a4n%40googlegroups.com.
