Hi Jean-Paul, On Thursday, December 10, 2020 at 11:39:08 PM UTC+1 Jean-Paul Pelteret wrote:
> 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. > Yes, this issue is similar. I assume I will need to check that for these elements as well since I also need them. > 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. > This is a nice alternative for the Nedelec element. Often though such elements are used in conjunction with H1 or H(div) conformal elements and need to satisfy a compatibility condition (stronger than just LBB, i.e., they must form a bounded co-chain complex that is a subcomplex to something else). I am not sure that this element does satisfy this condition together with classical RT elements etc. > 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! > Lowest order RaviartThomas is already fixed. I will hunt down this issue as good as I can. I might need some help with local and global dof numbering conventions. I will also try to move the discussion to the issue page <https://github.com/dealii/dealii/issues/7970> on github. Best, Konrad -- 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/90968d76-09ae-4dd5-82a8-c49bc6383792n%40googlegroups.com.
