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

Reply via email to