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 [email protected]
<mailto:[email protected]>.
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>.
--
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/b6ca3402-06af-460b-beb5-1df58b783cbf%40colostate.edu.
