[Libmesh-devel] Initial p refinement support committed to CVS

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

On Tue, 28 Mar 2006, Roy Stogner wrote:

> On that note, we probably ought to put a global tag on the CVS head
> before I do my next big commit.  I don't think there's anything that
> should break any code which doesn't do p refinement, but it's a big
> change that touches a lot of files, and just in case people do start
> running into bugs it might be prudent to make reverting the whole
> changeset easy.

This morning's CVS head has been tagged, and my p refinement code is
committed.  If anyone's feeling adventurous enough to cvs update, let
me know (preferably with a stack trace) if you encounter any bugs.

The commit log:


Initial p refinement support - uniform p refinement is working;
adaptive p and hp refinement has yet to be well tested.

Major changes include:

DofMap now examines element p_level when assigning and indexing
degrees of freedom.

MeshRefinement now tests for level one p_level conformity when asked,
and can do uniform p refinement and coarsening.

Quadrature rules and FE objects now examine Elem::p_level() when they
are able to.  Library internals have been changed to pass total
polynomial order (= base polynomial order + element p_level) to
functions that cannot examine Elem::p_level() themselves.

Major limitations include:

System::project_vector does not yet work with p refinement.  The
option to turn off projection of solution vectors has been added as a
temporary workaround.

Non-hierarchical element types cannot support adaptive p refinement,
and will be limited to uniform p refinement for the forseeable future.

---
Roy