On Tue, 30 Mar 2010, Derek Gaston wrote:
> On Mar 30, 2010, at 12:09 PM, Roy Stogner wrote:
> Yeah, and I'm starting to wonder if I did it right. While I was
> preparing this patch I think I noticed a bug that would kill the
> convergence rates for hp refinement on C0 elements in 2D/3D - a
> situation in which I never did get exponential convergence.
> No point in attempting a fix now, though, since I won't have time to
> test it. The app code I'm working on now is LAGRANGE-only and so for
> us is p-refinement-incompatible; and without that I've got no excuse
> to spend as much time as it would take to get hp working well by
> myself. I'd try and conscript Vikram, but he's got a tough enough
> problem with h refinement alone on some of these non-conforming QoIs.
> I don't even know if Taylor-Hood elements are LBB-stable under
> adaptive hp refinement.
> Just for catloguing the problem... can you give a small description? Maybe someone else can fix it...
To handle p-refinement, in that snippet of system_projection.C that
Lorenzo and I just fixed, we assume that the basis is p-hierarchic,
which assumptions allows us to either ignore the highest indexed DoF
(when lowering p) or set it equal to 0 (when raising p).
But to handle h-refinement on arbitrary elements, we have a more
complicated system on hanging nodes: vertex DoFs are indexed in
ascending order from 0 up, but edge/face DoFs on hanging nodes are
indexed in descending order from n_dofs_at_node-1 down.
This means that the current project_vector() code is definitely buggy
for the hp case, and it's possible that the constraint generation code
(which uses the same p-hierarchic assumption) has the same problem.