Improve support for 2d meshes embedded in 3d space

[nmnobre]

No description provided.

[moosebuild]

Job Coverage, step Generate coverage on e525e69 wanted to post the following:

Coverage

	159f51	#4064 e525e6
	Total	Total	+/-	New
Rate	63.22%	63.23%	+0.00%	96.30%
Hits	74214	74218	+4	26
Misses	43168	43169	+1	1

Diff coverage report

Full coverage report

This comment will be updated on new commits.

[nmnobre]

John (@jwpeterson), Roy (@roystgnr), do we have support for transforming vector functions/solutions (Lagrange, Hierarchical, Monomial) after a mesh transformation?

For instance, FE<3, MONOMIAL_VEC>::shape() exists and gives a vector basis function, but then monomial_vec_nodal_soln() falls back to the scalar basis functions again for some reason? Equipped with the vector function, it'd be easier to formulate 2d problems in 3d. Is the functionality (partially) implemented somewhere - it feels like it must be?

[jwpeterson]

do we have support for transforming vector functions/solutions (Lagrange, Hierarchical, Monomial) after a mesh transformation?

I don't know the answer to your question for sure, but I fear it's probably "no". If I understand correctly, you are asking about mapping a vector solution from an initial mesh to a stretched/translated version of that same mesh?

[nmnobre]

I don't know the answer to your question for sure, but I fear it's probably "no". If I understand correctly, you are asking about mapping a vector solution from an initial mesh to a stretched/translated version of that same mesh?

Yep, or rotated for instance. Because that's the same map we'd need if solving 1d/2d problems in a higher dimensional space. If each dof maps to a vector function, then I can transform that function the same way I transformed the mesh.
If the problem is formulated effectively as 3 scalar variables (whose transformation is just the identity) then I'm guessing the answer is no indeed. But I'm wondering if we could assemble/formulate from 3 vector variables with zeros on the two other components instead. Just like what FE<3, MONOMIAL_VEC>::shape() returns.

[nmnobre]

To answer myself above, I'm now convinced the proper and natural way of supporting Lagrange-like vector FEs embedded in higher dimensional spaces is to change FEGenericBase<RealGradient>::build() to take a vector dimension vdim. That'd imply changing the constructor FE<Dim,T>::FE(), from there the no. of dofs/functions to consider vdim, and from there shape() and derivative friends. It's going to be a bit of work...

So, I suggest we try to converge on a compromise here. It'll be a bit bizarre perhaps, having better support for ND/RT than classical FEs, but it's still a pure addition, with no loss in current functionality. Thoughts?

[roystgnr]

I'm still terrified of what happens when we have a curved but not C1 2D manifold in 3D space, but for cases where we're only caring about continuity between coplanar elements this looks great

[roystgnr]

I'm still terrified of what happens when we have a curved but not C1 2D manifold in 3D space

To be fair: I'm not talking about this PR in particular, I'm talking about a mistake that's easy to make in general that I'd love to protect against somehow but can't figure out how to. In KellyErrorEstimator we have the exact problem I'm worried about: instead of using the normal vectors on both sides of a face to compute flux jumps, we use the normal vectors on one side and just assume that the normals on the opposite side are their negative.

I'll see if I can cook up a unit test that demonstrates that for that case.