Yes, that makes sense to me. But now if we have neighboring faces with differrent refinement levels (e.g. the face element on one side is only half as long as the one on the other side) the situation gets a little more complicated, right? Since then you cannot just copy the coefficients 1 to 1, or do I get that wrong?
So what you suggest is that one could actually go on and implement hp_*_identities for FE_FaceP, in the way you describe? Do you know of some other element that already implements this, not using interpolation, which one could use as reference? Best, Samuel On Friday, August 4, 2017 at 2:45:40 PM UTC+2, Wolfgang Bangerth wrote: > > > > As indicated in the documentation > > <http://dealii.org/developer/doxygen/deal.II/classFE__DGP.html>, the > finite > > elements FE_DGP and FE_FaceP are not based on nodal interpolation (as > eg. > > FE_DGQ and FE_FaceQ), but on projection. Apparently, this prevents these > > elements from being used in combination with a hp::DoFHandler, since > there > > seems to be no easy way (or even no way?) to implement the functions > > hp_*_identities for FE_FaceP (which is needed to support hp) when no > nodal > > interpolation (ie. no unit_support_points) is available. > > > > I would really like to use the FE_DGP/FE_FaceP combination in a hp FEM > > computation, as this requires fewer DoFs than the FE_DGQ/FE_FaceQ > couple. > > > > Does anyone have an idea how to fix this problem? I imagine that either: > > - one could implement hp_*_identities, somehow, based on the existing > code > > with projection, or > > - one could implement a different version of FE_FaceP with nodal > interpolation > > but i don't really know whether these approaches could work and where to > start. > > The interpolation property is not actually necessary. What is necessary > for > using things in the hp framework is that the space on one side is *larger* > than the one on the other side, and consequently that you can constrain > one to > the other by a set of linear constraints. That is what > make_hanging_node_constraints() does. > > The hp_*_identities actually do a subset of that, namely identify degrees > of > freedom on one side with those on the other side. For interpolation, that > is > simple. But it doesn't have to be. Think of shape functions > 1, x, x^2 > along an edge (-1,1), for example. These are moments, not interpolatory. > Now > on a neighboring cell, you may have > 1, x, x^2, x^3 > and for continuity, you'll have to have that on that cell, the coefficient > for > the last shape function is zero and the coefficients for the first three > equal > the same coefficients for the three shape functions on the first of the > two > cells. This identity is what the hp_*_identities() functions record. In > other > words, for that face, you should get the identities > (0,0) // DoF 0 on one side equals DoF 0 on the other side > (1,1) > (2,2) > and later on, make_hanging_node_constraints() would set U_3 on the second > cell's face to zero. > > Does that make sense? > > Best > W. > > > -- > ------------------------------------------------------------------------ > Wolfgang Bangerth email: bang...@colostate.edu > <javascript:> > www: http://www.math.colostate.edu/~bangerth/ > > -- 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. For more options, visit https://groups.google.com/d/optout.
