HI Konrad,
I have no familiarity with the H-div elements, so I could be wrong with
this suggestion...
The Fe_Nedelec element suffered from a similar issue, where adjacent
cells had to agree on the edge sense/directionality. This requirement
could not be unconditionally guaranteed for that element type, hence the
following note in its introduction
<https://dealii.org/current/doxygen/deal.II/classFE__Nedelec.html>
Even if this element is implemented for two and three space dimensions,
the definition of the node values relies on consistently oriented faces
in 3D. Therefore, care should be taken on complicated meshes.
The more recent FE_NedelecSZ
<https://dealii.org/current/doxygen/deal.II/classFE__NedelecSZ.html>
element resolves the issue by querying the vertex numbers that make up
each edge/face and applying a rule that gives each face and its bounding
edges a direction. This means that the orientation of the face/edges is
always consistent no matter which of the two cells that share the face
you're on. The details are more explicitly laid out in the FE_NedelecSZ
<https://dealii.org/current/doxygen/deal.II/classFE__NedelecSZ.html>
introduction, as well as the two papers that are listed therein.
Now, I'm by no means certain that underlying issue that you're seeing
here is the same as that which plagued the canonical Nedelec element
(although your comment #3 makes me suspect that it could be). But if it
is, then perhaps what was done to fix the orientation conflict in the
Zaglmayr formulation of the Nedelec element can serve as inspiration for
a fix to the BDM and RT elements?
Thanks for looking into this, and I hope that you have some success at
finding a solution to the problem. Naturally, if there's anything that
we can do to help please let us know. It would be very nice to have a
robust implementation to these elements in the library, so anything that
you might be willing to contribute would be greatly appreciated!
Best,
Jean-Paul
On 10.12.20 18:50, Konrad Simon wrote:
Dear David, dear all,
It seems like the issue is much more involved than I initially
thought. Some updates since I started going into this issue
<https://github.com/dealii/dealii/issues/7970>.
1. I could solve the problem for lowest order RaviartThomas Elements
(RT). This is already good.
2. The fix does not work for lowest order BDM elements.
3. The fix does not work for higher order elements, neither BDM nor RT
elements
Suspected reason: For shape functions of higher order elements (whose
normal components) are supported on a face flipping the sign on a
flipped face is not enough since the flipped face changes/reverts the
ordering of the face dofs hence the translation of local to global
numbering of degrees of freedom changes for cells with flipped faces.
I am not sure but at least I suspect that. Is this being taken care of
by Deal.II somewhere?
I will go on chasing the bug and hopefully come up with a merge
request soon.
Best,
Konrad
On Wednesday, December 9, 2020 at 3:44:58 PM UTC+1 Konrad Simon wrote:
Hi David,
Many thanks for the hint. After some research I believe I stumbled
over this issue#7970
<https://github.com/dealii/dealii/issues/7970>? Let's see what I
can do.
Best,
Konrad
On Tuesday, December 8, 2020 at 10:56:44 PM UTC+1 Wells, David wrote:
Hi Konrad,
This isn't a very satisfying answer but, to the best of my
knowledge, these Hdiv elements weren't written with general
unstructured 3D meshes in mind. I suspect, without looking
more closely, that this is a problem on our side.
We document this for the FE_RaviartThomasNodal class but for
FE_RaviartThomas this is just a comment in the source file.
Would you be willing to write a patch explaining things better
for the other Hdiv classes?
Best,
David
------------------------------------------------------------------------
*From:* [email protected] <[email protected]> on
behalf of Konrad Simon <[email protected]>
*Sent:* Monday, December 7, 2020 12:48 PM
*To:* deal.II User Group <[email protected]>
*Subject:* [deal.II] Div-conforming elements in 3D
Dear Deal.ii community,
Sorry for spamming the mailing list again. I posted some of
the below stuff already in another post but that might have
been with too many unnecessary details and confusing ideas
from my side.
I am not sure if I stumbled over something and would like to
report on that.
Goal is to project a given function onto a finite element
space over a certain mesh. The focus here shall be on
H(div)-conforming elements such as Raviart-Thomas and
Brezzi-Douglas-Marini Elements.
I do so with several different meshes and I noticed an
inconsistency in the projection on meshes with, say, not so
simple topology (e.g., holes and voids).
Observations:
1. The problematic meshes do have faces with non-standard
orientation. My first thought was this was not carried over to
the mapping of the H(div)-basis but I was wrong. The mesh
orientation is consistent (as far as I can tell). A cube, for
example, is not problematic. Please see two example plots below.
2. The issue arises with both Raviart-Thomas and
Brezzi-Douglas-Marini Elements.
3. The issue arises in 3D only.
Any ideas what I ran into?
Best,
Konradplate_with_hole.pnghyper_shell.png
--
The deal.II project is located at http://www.dealii.org/
<http://www.dealii.org/>
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
<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 on the web visit
https://groups.google.com/d/msgid/dealii/fa304b41-f83f-4c96-a2f7-c4e9e813553fn%40googlegroups.com
<https://groups.google.com/d/msgid/dealii/fa304b41-f83f-4c96-a2f7-c4e9e813553fn%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
The deal.II project is located at http://www.dealii.org/
<http://www.dealii.org/>
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
<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]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/dealii/883fee09-6fba-4d38-914d-869e2e7058adn%40googlegroups.com
<https://groups.google.com/d/msgid/dealii/883fee09-6fba-4d38-914d-869e2e7058adn%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 on the web visit
https://groups.google.com/d/msgid/dealii/83772071-e724-fda8-a164-376081ccf8ce%40gmail.com.
