Your approach might be more efficient if you use the HIERARCHIC edge dofs both for the traces and for the variables,
so that you can use just one basis function and pick only the dofs that you need for the traces.
However if the homogeneous trace are a source of trouble you can forget about efficiency and simply use two different basis
one for elements (of dimension dim) and one for faces (of dimension dim-1). For elements you can simply choose
one basis without homogeneous traces (at low orders MONOMIALS should work while if you need to go higher order you can implement
different HIERARCHIC L2 orthogonal basis without edge/faces/elements dofs decomposition.
You can take a look at the book of Karniadakis and Sherwin or the FIAT library included in the FENICS project).
For traces you can keep HIERARCHIC basis, do you need continuity at vertices here?
I wonder what happens if you remove bubbles, won't you lose the approximation properties of your basis
regarding to the variable approximation?
On Oct 21, 2011, at 5:23 PM, Truman Ellis wrote:
On 10/21/2011 03:43 AM, Lorenzo Alessio Botti wrote:
Maybe it would help if I explained what kind
of elements I need first. I basically have 2 kinds of of
variables. Field variables are defined only on element interiors
and thus need to be discontinuous between elements.
It seems that you are using HIERARCHIC basis functions with
interior/side dofs decomposition. These basis are in general
good for L^2 and C^0 spaces but might not be well suited for DPG.
I just guessing here, I'm not an expert of these kind of stabilized discretizations.
Why don't you simply switch to L^2 orthonormal HIERARCHIC basis
without interior/side dofs decomposition. With this latter choice
you can't impose C^0 continuity
but you don't have modes with homogeneous traces.
On Oct 21, 2011, at 12:30 AM, Roy Stogner wrote:
At first glance I don't think there's a good way to avoid defining a
new element to give us side-only (not edge-only in 3D, right?) bases;
but I'm Cc'ing to libmesh-devel in case someone has an idea I've
---------- Forwarded message ----------
Date: Thu, 20 Oct 2011 17:19:42 -0500
From: Truman Ellis <firstname.lastname@example.org>
To: Roy Stogner <email@example.com>
Subject: Trace Elements
I've got some degree of success with Convection-Diffusion with DPG, at least for first order. I am having an issue when it comes to second or
higher order representations of the variables, namely the trace variables. These are technically only defined on element edges, so any bubbles in
the basis never get constrained. It seems like I should define a new TRACE_HIERARCHIC element where I just remove any bubbles, but I'm not sure if
this is the most natural solution. Perhaps libMesh has some better way of implementing this like somehow prescribing edge based elements?
What do you think?
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
Libmesh-devel mailing list
variables are defined only on element edges and thus need to be C0
continuous between two elements.
My initial approach was to define a new finite element type
L2_HIERARCHIC for field variables where I just took the built in
HIERARCHIC and broke the connectivity at nodes and edges. For trace
variables I just used standard HIERARCHIC but only evaluated them
along edges. Of course, as I explained earlier, this approach fails
for second or higher order elements because of the homogeneous
traces of the bubbles. The only idea I have for how to fix this is
to define a new TRACE_HIERARCHIC element where I take the standard
HIERARCHIC and somehow remove the basis functions which correspond
Lorenzo, were you recommending SZABAB elements? I'm not intimately
familiar with the various element implementations we have in
libMesh, but from a quick Google search it looks like they don't get
any bubble modes until 4th order. Ideally I would like to push that
to higher order since I would like to do hp adaptivity, but this is
certainly a start.