From: Manav B. <bha...@gm...> - 2013-12-05 17:59:59
|
Hi, I am working on this now, and need some help understanding the extra-hanging-dofs. The higher-order elements, say SZABAB on a QUAD9, have 4 dofs for each corner node, then edge bubble functions for each mid-side node (depending on the order of element), and finally all bubble functions on element domain are attached to the middle node. With h-refinement, a side node (now of the neighbor) becomes a corner node of the new elements, and new mid-side nodes are created for the new elements. Given this, would the intent be to constrain the *new* edge dofs (of the child elements) to the *old* corner and edge dofs (of the edge shared by the parent/neighbor)? What about the new dofs that show up at the old edge node, which is now a corner dof? Which of these get characterized as the extra_hanging_dofs? Any comments would be helpful. Manav On Wed, Dec 4, 2013 at 11:36 PM, Manav Bhatia <bha...@gm...> wrote: > Hi Roy, > > I have started to run some test cases in 2D (subsonic flow over a sine > bump) using QUAD9, and have the following observations: > > — All FE types tested: LAGRANGE (till 2nd order), SZABAB and BERNSTEIN > work fine without AMR, and the solution converges. > > — 2nd order LAGRANGE FE type, *with h-refinemement* works fine and > converges. > > — Changing FE type to SZABAB and *using h-refinement* leads to unrealistic > (huge) residual values immediately after first h-refinement and the plotted > solution has odd looking spikes in each element next to a hanging node. > > > This seems to be an expected behavior given the bug described in the > libmesh-devel thread you had sent to me. (?) > > Out of the higher-order polynomials, SZABAB is nested, but BERNSTEIN is > not since the whole basis changes as soon as the p-order is modified. Does > this bug/discussion affect BERNSTEIN in the same was as it does SZABAB? I > mean, if the project_solution, assumes that the change in p-order could be > handled with ignoring/zeroing the highest order dof, then that should not > be the correct approach for BERNSTEIN polynomials? > > > -Manav > > > > On Dec 1, 2013, at 4:30 PM, Roy Stogner <roy...@ic...> wrote: > > > > > On Sun, 1 Dec 2013, Manav Bhatia wrote: > > > >> I will working on some hp-adaptation studies in the coming days. > >> I will keep you posted about my experience. > > > > Thanks! > > > > FYI, the only case where I recall definitely getting exponential > > convergence was on 1D problems with a "h refine only for elements next > > to predefined singularity points" heuristic. This suggests that we > > might have both a bug in the constraints generation and a bug or a > > poor design in the coarsening-based hp-selection heuristic. > > > > IIRC a while ago I identified a possible bug in the constraints > > generation but didn't have time to fix it. Let me see... > > > > > http://www.mail-archive.com/lib...@li.../msg01928.html > > > > And yes, that definitely looks like a bug. When we see high-p > > edge/face dofs on hanging nodes we're not constraining the right > > indices; we need to be testing FEInterface::extra_hanging_dofs and > > hitting the nodal dof indices in reverse order in that case. I can > > probably cook up a patch for that next week, but I don't have much > > time; would you be interested in helping test it? > > > >> I also owe you another PR on the user sensitivity routines for > >> sensitivity analysis. The code is complete at my end and I have > >> been using it. I will soon create a PR for the same. > > > > Thanks! > > > > Didn't you already have a PR open for that? I could swear I remember > > starting to look that over, but going back I can't find it in either > > the open or the closed pulls list on github. > > --- > > Roy > > |