From: KIRK, BENJAMIN (JSC-EG) (NASA) <benjamin.kirk-1@na...> - 2004-02-03 14:29:48
I don't really see any problem with that. I think the implementation could
be handled just like everything else in the FE class, i.e. through template
The current (scalar) Finite elements could continue to work as they are,
they would just operate on the subset phi[i][qp] and get_phi() would
return a reference to phi.
I think this could easily handle the Raviart-Thomas part, and they should be
easy to implement. I think the Nedelec part might be more complicated, but
it should also fit into this framework.
On a related note, maybe the best way to handle this is to expand the
FEBase/FE setup. Perhaps a pure virtual base class FE with a range of
classes that inherit from it:
(this is where a whiteboard is handy).
So, we might re-examine the FE structure and think about improving it.
There is a fair amount of code in there, though...
From: John Peterson [mailto:peterson@...]
Sent: Sunday, February 01, 2004 9:36 PM
To: KIRK, BENJAMIN (JSC-EG) (NASA)
Subject: vector-valued shape functions
I've recently been asked about programming the Raviart-Thomas-Nedelec
elements in libMesh by someone I met at the Manchester conference from this
summer. Although I don't have the reference yet (J. C. Nedelec, 1980,
"Mixed finite elements in R3." Numerical Math. 35:315-341) I gather that
they are vector-valued shape functions, i.e. when you dot the governing PDE
with a vector shape function v, v is no longer simply (phi_i,0,0),
(0,phi_i,0), (0,0,phi_i), the components are dependent to enforce some
property such as divergence free, etc.
Wolfgang has a discussion on matrix assembly for these types of elements in
(search for assembling matrices on the page)
it seems like a very generic idea since the scalar-valued shape functions
now are simply a special case where only one component of the vector is
non-zero. We might add a function called "is_primitive" which returns
whether or not a particular FE instantiation has vector-valued shape
functions. Or we could do something fancier with virtual functions...
The functions get_phi, get_dphi would fail for non-primitive elements and
continue working for the current elements. For non-primitive elements you
would need to call for example:
which would return a reference to a vector of vectors of vectors. Then use
#defines as normal:
#define phix(i) phi_values[i][qp]
#define phiy(i) phi_values[i][qp]
#define phiz(i) phi_values[i][qp]
Do you see any big problems with that? It might lead to more users for the
library since many people solving Maxwell's equation often use H(curl)
conforming elements which fit into this framework.
From: John Peterson <peterson@cf...> - 2004-02-05 23:11:10
Daniel Dreyer writes:
> suggested by John. But why distinguish between C0_FE and C1_FE,
> then where should go the p-FEM like SZABAB go in? Why not this:
> FE <- InfFE
> FE <- ScalarFE
> FE <- VectorFE
> and ScalarFE is just templated as before FE<d,family>?
Actually I was thinking about this so I am glad somebody else
brought it up. This hierarchy seems to be a more general
distinction. Subclasses of the ScalarFE class are free to
be C0, C1, discontinuous, etc.