Line orientation of hanging edges for nedelec elements on simplices

[Lukas Dreyer]

Hello everyone,

I am currently implementing the lowest order nedelec simplex elements, which just have one degree of freedom on each edge, but this dof is oriented.

I already made good progress in 2D with triangles and hanging nodes, but the sign-conflict for hanging edges in 3D is difficult to resolve.

For 3D, in order to get consistent, precomputable restriction matrices, we need to redefine the orientation of local basis functions at hanging faces and hanging edges.

I should be able to adapt the definition for hanging faces from FE_NedelecSZ(Link). 

For hanging edges, the orientation of the child basis function on that line must be the same orientation as the parent basis function of the coarser neighbor on that line.

For the FE_NedelecSZ class, the sign adjustment for hanging edges is computed by assuming that each line_neighbor is at most two face_neighbors away (Link). This assumption does not hold for simplices (and not even for all cube coarse meshes)..

So the problem that I want to solve is: On a 2:1 edge-balanced 3d mesh, given a cell and a local edge, return the parent global line when there is a coarser edge-adjacent element and return the own global line, when no coarser element is edge-adjacent.

With that information, I can multiply the local basis functions by -1 if their orientation does not fit the global orientation of the line or the parent line.

We already thought about some approaches:

1. Contrary to the cell iterators, line iterators do not provide parent functionality. Thus we could add parent functionality to line iterators.

2. It is possible to precompute the edge-relations with one sweep over all cells, since children are available for line-iterators. But since I am trying to incorporate the functionality into fill_fe_values, fill_fe_values itself is not the place to precompute information, and get_data(), where precomputation should take place does not have access to the triangulation.

3. If we still want to focus on precomputation, this information could be saved in the nedelec finite element, with a special function to update that information, which the user needs to call.

4. If we do not precompute anything, one possible solution could be to iterate over face-neighbors adjacent to that line until we find a coarser element, the boundary or our original element.

5. We also had a look into vertex_to_cell_map, but as its computation contains a loop over all cells, we again would want to precompute it, but we do not see an appropriate place to precompute information depending on the triangulation in a finite element.

(6. Move resolving the sign-conflict from the finite element to the dof-handler.)

Am i missing any options? Which of these options do you think are viable, and which do you prefer?

Best regards

Lukas Dreyer

[Wolfgang Bangerth]

Lukas:
in a strange coincidence, I went back to one of the pull requests that have
been open for too long already, and I think it's exactly what you need:
https://github.com/dealii/dealii/pull/16644
Does this help with what you want to do?

I lost track of that PR, and @kinneweg has left academia since he wrote that
patch. So I don't know whether he has the time to finish the work there or
whether we need to find a different way to get it merged. But if the material
in that PR is something that would help you in your work, let's find a way to
get it merged so we can get you unstuck!

Best
W.


On 6/9/26 05:31, Lukas Dreyer wrote:
> *** Caution: EXTERNAL Sender ***

>
> Hello everyone,
>
> I am currently implementing the lowest order nedelec simplex elements, which
> just have one degree of freedom on each edge, but this dof is oriented.
> I already made good progress in 2D with triangles and hanging nodes, but the
> sign-conflict for hanging edges in 3D is difficult to resolve.
>
> For 3D, in order to get consistent, precomputable restriction matrices, we
> need to redefine the orientation of local basis functions at hanging faces and
> hanging edges.
> I should be able to adapt the definition for hanging faces from

> FE_NedelecSZ(Link <https://nam10.safelinks.protection.outlook.com/?
> url=https%3A%2F%2Fgithub.com%2Fdealii%2Fdealii%2Fblob%2Fb18de73e305dfdb7db0f36526767de32c1b86584%2Fsource%2Ffe%2Ffe_nedelec_sz.cc%23L1796-L1828&data=05%7C02%7CWolfgang.Bangerth%40colostate.edu%7Cba36c6a91318462dea3808dec623067e%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C639166050906441933%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=H9eDw%2F2w06tns3G2i4vjr80%2FjvSEojraUxCA1lVpLWg%3D&reserved=0>).

>
> For hanging edges, the orientation of the child basis function on that line
> must be the same orientation as the parent basis function of the coarser
> neighbor on that line.
>
> For the FE_NedelecSZ class, the sign adjustment for hanging edges is computed
> by assuming that each line_neighbor is at most two face_neighbors away (Link

> <https://nam10.safelinks.protection.outlook.com/?
> url=https%3A%2F%2Fgithub.com%2Fdealii%2Fdealii%2Fblob%2Fb18de73e305dfdb7db0f36526767de32c1b86584%2Fsource%2Ffe%2Ffe_nedelec_sz.cc%23L1830-L1930&data=05%7C02%7CWolfgang.Bangerth%40colostate.edu%7Cba36c6a91318462dea3808dec623067e%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C639166050906484963%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=vL7n037x7x0l%2FKtEdJ6HFpa9ZYKwE78qO3A71YYrRLs%3D&reserved=0>). This assumption does not hold for simplices (and not even for all cube coarse meshes)..

>
> So the problem that I want to solve is: On a 2:1 edge-balanced 3d mesh, given
> a cell and a local edge, return the parent global line when there is a coarser
> edge-adjacent element and return the own global line, when no coarser element
> is edge-adjacent.
>
> With that information, I can multiply the local basis functions by -1 if their
> orientation does not fit the global orientation of the line or the parent line.
>
> We already thought about some approaches:
> 1. Contrary to the cell iterators, line iterators do not provide parent
> functionality. Thus we could add parent functionality to line iterators.
>
> 2. It is possible to precompute the edge-relations with one sweep over all
> cells, since children are available for line-iterators. But since I am trying
> to incorporate the functionality into fill_fe_values, fill_fe_values itself is
> not the place to precompute information, and get_data(), where precomputation
> should take place does not have access to the triangulation.
>
> 3. If we still want to focus on precomputation, this information could be
> saved in the nedelec finite element, with a special function to update that
> information, which the user needs to call.
>
> 4. If we do not precompute anything, one possible solution could be to iterate
> over face-neighbors adjacent to that line until we find a coarser element, the
> boundary or our original element.
>

> 5. We also had a look into vertex_to_cell_map <https://
> nam10.safelinks.protection.outlook.com/?
> url=https%3A%2F%2Fdealii.org%2Fdeveloper%2Fdoxygen%2Fdeal.II%2FnamespaceGridTools.html%23a9b7e2ca8ecd26a472e5225ba91a58acb&data=05%7C02%7CWolfgang.Bangerth%40colostate.edu%7Cba36c6a91318462dea3808dec623067e%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C639166050906516948%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=owyvl5BVae2TmQVtnpTQthbXZWlm1mr8ZF8nHpO9vC4%3D&reserved=0>, but as its computation contains a loop over all cells, we again would want to precompute it, but we do not see an appropriate place to precompute information depending on the triangulation in a finite element.

>
> (6. Move resolving the sign-conflict from the finite element to the dof-handler.)
>
> Am i missing any options? Which of these options do you think are viable, and
> which do you prefer?
>
> Best regards
> Lukas Dreyer
>

> --
> The deal.II project is located at http://www.dealii.org/ <https://
> nam10.safelinks.protection.outlook.com/?
> url=http%3A%2F%2Fwww.dealii.org%2F&data=05%7C02%7CWolfgang.Bangerth%40colostate.edu%7Cba36c6a91318462dea3808dec623067e%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C639166050906548787%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=RzHbcoZNlVRdQcXCj7IfU%2BDsZfMpAwR9A1QRtftGuoY%3D&reserved=0>
> For mailing list/forum options, see https://groups.google.com/d/forum/dealii?
> hl=en <https://nam10.safelinks.protection.outlook.com/?
> url=https%3A%2F%2Fgroups.google.com%2Fd%2Fforum%2Fdealii%3Fhl%3Den&data=05%7C02%7CWolfgang.Bangerth%40colostate.edu%7Cba36c6a91318462dea3808dec623067e%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C639166050906585769%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=d3Zf%2B4ARdLQW1gTsZJdq4gPVYtnINq%2B8cFaUuUTa9wg%3D&reserved=0>
> ---
> 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
> <mailto:dealii+un...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/dealii/
> c92aa252-ad70-44b8-8d26-228e7479049fn%40googlegroups.com <https://
> nam10.safelinks.protection.outlook.com/?
> url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fdealii%2Fc92aa252-
> ad70-44b8-8d26-228e7479049fn%2540googlegroups.com%3Futm_medium%3Demail%26utm_source%3Dfooter&data=05%7C02%7CWolfgang.Bangerth%40colostate.edu%7Cba36c6a91318462dea3808dec623067e%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C639166050906618943%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=bDXpByjqozzdEdmMukAiYiWv69KalCekmGbIyXS7v7k%3D&reserved=0>.