Another follow-up question:
If the problem described in the previous email is relevant to all
higher order elements with edge-dofs, then wouldn't
FEInterface::extra_hangin_dofs() be true all such elements? If yes, then
why would BERNSTEIN and SZABAB return false, while HIERARCHICH return true
for this function?
-Manav
On Thu, Dec 5, 2013 at 12:59 PM, Manav Bhatia <[email protected]> wrote:
> 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
