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 <[email protected]> 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 <[email protected]> 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/[email protected]/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
>
>
------------------------------------------------------------------------------
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users
