Dear Jean-Paul,
Many thanks for your reply.
On Tuesday, December 29, 2020 at 9:31:49 PM UTC+1 Jean-Paul Pelteret wrote:
> Hi Konrad,
>
> I'm sorry for taking some time to reply. To be honest, the inner working
> of the FE classes is not something that I've ever had the time or
> opportunity to dig into, so I'm really not well positioned to answer many
> of your questions. I'm glad that you've submitted a PR for the work that
> you've done thus far, and I hope that you can be guided by someone who has
> more familiarity with this part of the library.
>
It will be my pleasure if other people will be able to benefit from
implementations that I had to add and to contribute it as well as I
benefited from other peoples‘ work. Let‘s hope that the stuff I asked to
add makes sense.
>
> What I can say, though, is that the various FE classes have been
> implemented by numerous people over time, and the logic that dictates the
> way that the DoFs are assigned varies between each FE. We have always
> considered this to be perfectly fine -- this is, to the average person, an
> implementational detail, and the interface that we have to interrogate DoFs
> (e.g. which vector component they're associated with, whether or not they
> have support points, etc...) seems to be sufficiently rich to most users.
> So, as the end user, you shouldn't be writing code that would care that the
> FE_Q element orders DoFs like this: [N_{0,x} N_{0,y} N_{0,z} N_{1,x} ...] ;
> while IIRC the FE_DGQ element orders DoFs like this: [N_{0,x} N_{1,x}
> N_{2,x} ... N_{0,y} N_{1,y} ...] .
>
> So, returning to your original set of questions: In general, I don't
> believe that it can be assumed that all cell vertex DoFs are enumerated
> before line/edges DoFs, before face DoFs, before cell interior DoFs.
> Through the FiniteElementData class, the FiniteElement base class seems to
> have a set of n_dofs_per_[vertex,line,face,cell]_dofs()
> <https://dealii.org/developer/doxygen/deal.II/classFiniteElementData.html#a0d1f06778f87a7606cc2e0d5338b41ab>
>
> and get_first_[line/quad/hex]_index()
> <https://dealii.org/developer/doxygen/deal.II/classFiniteElementData.html#a078fb199880f2b29fc72d9c01d317bd0>
>
> functions, which does suggest that I'm wrong about this, so I'd be happy to
> be corrected on this point. (Question: What does a vertex/edge/face DoF
> even mean for a DG element?) Maybe these are the exact functions that you
> were looking for (and maybe with this , if the [vertex,edge,face,cell]
> groupings do apply, you can map from the cell DoF->associated geometric
> entity using these functions). But I don't that they would help
> understanding the ordering (e.g. lexiographic or something else; element
> base index fast or spacedim fast, etc.) within each grouping -- again,
> that's probably a decision that was left to the designer of each FE class,
> and I don't think that there's been a need for any consistency between the
> classes. But again, I'm just putting my thoughts out there and anticipate
> being corrected on these points.
>
In my humble opinion the FE should only be implemented in terms of a
reference element. This is, as far as I can tell, the case for all elements
in Deal.II. The mapping though is problematic on complicated domains and I
saw that one needs to renumber or switch signs for some shape functions if
one wants to satisfy continuity conditions for the respective spaces. This
is partly taken care of by the DoFHandler (see renumbering of FE_Q on
faces) class which confused me, while other parts like the sign change is
not. I guess I got the idea. Also, the concept of (generalized) support
points is nice but sometimes it is not really clear to me if this is
helpful in the context of element pairings (for example in the language of
finite element exterior calculus where this concept does not really make
sense globally). I may be wrong and miss a point here and would love to
get a lesson.
>
> I get the feeling that there is no overlap in assignment of DoFs between
> geometric entities. Consider each of these entities not to have closure: so
> you're actually referring to DoFs associated with the cell interior (excl.
> faces, edges and vertices), face interior (excl edges and vertices) and
> edge interiors (excl. vertices). To me, that the only sensible
> interpretation of this.
>
This is partly what is not fully clear to me. Vertex/edge/face/volume dofs
(again FEEC) depends on the functionals that define them and less on
location (a Raviart-Thomas or Nedelec shape function is not regular enough
for point evaluations, although viewing them as a polynomial suggests so).
> Thanks for giving this so much thought, and for the interesting questions.
> I've certainly got a lot to learn from the responses that may come from the
> other developers.
>
As I said, I hope other people can benefit from that but I am not super
familiar with this part of the library as well. Let‘s see what the code
reviewers will say.
All the best wishes for the new year and stay healthy in these crazy times!
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 dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/dealii/d80feff8-2302-46bb-b57e-1fded6778e16n%40googlegroups.com.
