Hi Wolfgang,
Or is it true that these days anisotropic refinement only works for DG elements where constraints are not an issue? I grepped anisotropic refinement related funtion names from tutorial programs and only found step-30. Indeed as you observed, it’s a DG finite element with L2 conformity, hence sparing AffineConstraint. It appears get_dpo_vector is implemented relatively trivially <https://dealii.org/current/doxygen/deal.II/fe__dgq_8cc_source.html#l00183> for these FEs such that n_dofs_per_face would return 0. The make_hp_hanging_node_constraints function would have therefore ignored <https://dealii.org/current/doxygen/deal.II/dof__tools__constraints_8cc_source.html#l01096> them anyways. No, the old-style way just needs to go. What is missing is that the hp function needs to learn how to do anisotropic refinement. After going through the hp-paper and the make_hp_hanging_node_constraints function, it seems that, at least for my current purposes, a lot of code won’t be triggered since my dofhandlers are not hp capable and hence all affine constraints fall under the *simple case* in the hp paper. Though I’m not sure how susceptible the simple case code would be to the complications anisotropic refinement brings in step-30. I’ll spend more time looking into it. Best regards, Greg On Monday, April 10, 2023 at 9:35:35 PM UTC Wolfgang Bangerth wrote: > > Hi Greg: > > > Thanks a lot for your suggestions! My code is actually not using hp but > > simply > > FE_DGQ<3>(1) and FE_FaceQ<3>(1). The related source code shows that the > > boolean of > dof_handler.get_fe_collection().hp_constraints_are_implemented() > > decides whether internal::make_hp_hanging_node_constraints(dof_handler, > > constraints) should be called and for the FE_FaceQ class, > > make_hp_hanging_node_constraints > > always > > < > https://dealii.org/current/doxygen/deal.II/fe__face_8cc_source.html#l00279 > > > > returns true. > > Ah yes, I remember now. > > > > This makes sense since the 2D implementation of > > make_oldstyle_hanging_node_constraints seems to be looping over cells and > > their 1D faces to locate hanging nodes, which won’t apply to > FE_FaceQ<3>(1). > > We should just nuke the old-style stuff. It's been ~20 years since we > built finite elements that way, and the hp-function is the way to go. > > > > As a reference, I wrote a stripped-down version applying IPHDG to > step-4’s > > Poisson problem and reproduced the same error message. Demo-wise, four > cases > > were ran with attached pngs numbered accordingly: > > > > 1. isotropic refinement + no hanging nodes; > > 2. isotropic refinement + hanging nodes; > > 3. anisotropic refinement + no hanging nodes; > > 4. anisotropic refinement + hanging nodes (error). > > > > Would you consider as a way out of this rewriting the 2D version of > > make_oldstyle_hanging_node_constraints by essentially replacing the > > cell/face > > pairs with face/line pairs? > > No, the old-style way just needs to go. What is missing is that the hp > function needs to learn how to do anisotropic refinement. > > Since you're already looking into all of the right places: I have > forgotten how anisotropic constraints work. The place where we currently > generate the error you are seeing suggests that the function in question > simply can't do anisotropic refinement at all. But we have programs that > do anisotropic refinement. How do they end up in the old-style function? > In other words, how does this function > > https://github.com/dealii/dealii/blob/master/source/dofs/dof_tools_constraints.cc#L1789-L1808 > not always go to the hp case given that for almost all finite elements, > hp_constraints_are_implemented() is true? > > Or is it true that these days anisotropic refinement only works for DG > elements where constraints are not an issue? I should really know the > answers to these questions, but not a lot of people use anisotropic > refinement and so a lot of the knowledge behind it got lost... > > Best > W. > > -- > ------------------------------------------------------------------------ > Wolfgang Bangerth email: bang...@colostate.edu > 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. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/cd96de6d-0a20-4bd6-ad4b-dc9c8230436en%40googlegroups.com.
