[Libmesh-users] Re: Initial p refinement support committed to CVS

[Roy S. <roy...@ic...>]

This email subject would now be more accurate as "Initial hp refinement=20
support committed to CVS".  The only thing I haven't committed is the p and=
=20
hp options I added to example 14; there's some 3D code mixed in with my=20
changes that would just be confusing until the 3D hierarchics are working. =
=20
If anyone really wants the new ex14 soon, let me know and I'll get it clean=
ed=20
up to add.

On Wednesday 29 March 2006 2:26, I wrote:
> On Wed, 29 Mar 2006, Benjamin S. Kirk wrote:
> > Does
> >
> >> Initial p refinement support - uniform p refinement is working;
> >> adaptive p and hp refinement has yet to be well tested.
> >
> > mean that  hp refinement has been tested, but just not rigorously?
>
> Not even unrigorously.  I've done some fiddling to run through parts
> of the code, but I'd hoped to do the real tests on a real benchmark
> problem... but I'm not sure what to do about error indicators!  I
> don't know how you can choose between h and p refinement with a simple
> to implement code, much less how you can make that choice without
> access to an element assembly function.

Okay, for now I'm ignoring the h-vs-p problem.  That will have to wait for =
me=20
or another libMesh user to become more interested in hp as a research topic=
,=20
not just hp as something I've figured out how to implement easily.  For=20
debugging purposes, I've just been doing both h and p refinement together, =
so=20
technically hp refinement has been tested, but in practice code with singul=
ar=20
solution derivatives will want to stick with h for now.

> If all the code I put in is bugfree (it won't be),

I'm sure it still isn't, but it's giving me solutions on hp meshes now.  I'=
m=20
going to take a break from it here, but if others want to do any testing I'=
d=20
appreciate it.

> and if our simple error indicators can fairly compare elements of differe=
nt=20
> degree (here's hoping),

=46rom what I've been reading, the answer here is that Kelly won't give fai=
r=20
comparisons of different p elements, but the unfairness will probably be a=
=20
small constant that won't break the adaptive loop.

> and if you have a magic fairy guiding your h vs. p=20
> refinement choices (you don't),

Ben's right that the patch recovery estimators may be the way for us to go=
=20
here.  Anything that gives a sufficiently better estimate for the solution=
=20
local to an element will also give a good hp refinement scheme, just by=20
comparing the local error reduction vs. DoF increases for h vs. p refinemen=
t.

> and if your code doesn't accidentally assume constant p (our examples don=
't,=20
> but more complicated code might),

I'm a little more optimistic here now that I've converted ex14; basically=20
anything that works with HIERARCHIC elements at all is likely to work with =
p=20
or hp refined hierarchics - with the exception of infinite element code; I=
=20
don't understand the InfFE classes well enough to feel safe upgrading them =
to=20
hp.

> and if you don't want p>6 in 1D, p>5 in 2D, p>3 or non-hexes=20
> in 3D (you will), then libMesh now supports hp refinement.

I've bumped p up to 11 in 1D and for 2D quads for testing purposes; the cod=
e=20
could go higher, but I'm not sure it could go higher accurately without=20
higher precision arithmetic.

> > Maybe Derek is interested in scripting some stuff up & learning the
> > capabilities of the library?
>
> I'll forward this to him just in case he's not reading the mailing
> lists yet.  Somehow volunteering other people for work never works out
> for me as well as I hope, though.  ;-)

Yeah, no luck there.  I'll forward this to Derek too so maybe he'll feel=20
guilty.  ;-)
=2D-=20
Roy Stogner