Thanks for the feedback.

On Thu, Jun 21, 2012 at 3:04 PM, Roy Stogner <> wrote:

Looking over this, only two gripes:

The new FEInterface::shape should be a templated method to make it
trivial to extend to RealTensor etc.  This should be easy to fix after
the fact; commit as-is.

Went ahead and fixed this.

The FEInterface::is_vector_type() return type of bool is too
restrictive - we ought to be returning a type enum (TYPE_REAL or
TYPE_REAL_GRADIENT for now) to make it easier to extend later.

Will do. How does everyone feel about "FieldType" as the enum type for this?

I'll fix any problems in complex mode; the svn head is in flux right
now anyway.  My own ParallelMesh support edits are probably breaking
--disable-amr as we speak.

OK, thanks.

I hadn't committed before now, but since that time, I have found many kinks and now have a working example! The example is extending introduction_ex3 and is solving two uncoupled Laplace equations. I have it dumping GMV and ExodusII - I checked both (ParaView for ExodusII) output and everything seems to be working. Among the changes beyond what I had before are the following:

1. An FEBase::build needed to go to FEAbstract::build in dof_map during initialization
2. The shape function code for fe_lagrange_vec.C before was wrong, fixed now.
3. Fixed some bugs in my initial update of build_solution_names and build_solution_vector for output. Works for all old examples and the new vector_fe_ex1
4. As mentioned above, I templated the new void FEInterface::shape functions.

I tested with gcc 4.5 in dbg and opt modes and intel 11.1 in opt mode.

1. I haven't tested restart capability, but it should "just work" for XDR. ExodusII_IO::read will not work for these variables at the moment.
2. Although compute_constraints is enabled for FELagrangeVec, I haven't tested it on adapted meshes. In particular, we still need to test compute_proj_constraints for vector-valued elements.
3. I've only tested GMV and ExodusII_IO, not sure if this has broken others or not.
4. Have not tested on complex-valued problems.

I'm sure there's plenty of other stuff I haven't thought of yet, but please let me know if this breaks you.

Committed in r5717. I'll work on the enum type right away, but please chime in if you don't like the FieldType name.

Of course, if I hosed you, please let me know ASAP.

Next on the agenda is to update FEMSystem/FEMContext to handle this. More to come...