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: bange...@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/43d5afe6-63a6-3a92-ac4b-a9cb30ce3118%40colostate.edu.
