Joshua,
> Test 2 looks at the interaction with the FEValues class, and also
> seems to be working. I modified the get_data function to return a
> default data object. Normal fe classes resize the data fields to
> represent the number of dofs in the element, but all these fields need
> to be empty since we have no dofs. Wolfgang, I understand your logic
> that we are trying to represent a zero-function space, but the current
> element has no support points at which to evaluate this zero-function,
> so it seems to me that it should return empty data structures rather
> than zero values, zero tensors, etc.
The question of support points is not the right one here -- you can consider
for example finite elements that are not defined by interpolation at support
points but that have integral values as degrees of freedom. The
Raviart-Thomas higher order elements can be defined that way, for example. In
these cases, all that's really relevant is: "can we evaluate a finite element
at a quadrature point". How the finite element space is defined is an
entirely separate matter.
We can re-visit this issue at a later time, however. This doesn't have to be
settled right now.
> Of course, if anyone ever tried
> to evaluate the value of this element at a specific point (e.g. a
> shape_value call) then I think we should throw an exception. Let me
> know if that makes sense, or if you have a different interpretation.
My vision for FE_Nothing is that it would allow us to solve multifield
problems. For example, what I'd like to be able to do is to solve a couple
fluid-structure problem using a
FESystem (FE_Q, dim,
FE_Nothing, dim+1)
in the structure part of the domain (the dim-component of the displacement
being the unknowns) and
FESystem (FE_Nothing, dim,
FE_Q(p+1), dim,
FE_Q(p), 1)
in the fluid part (using Taylor-Hood for the fluid). The variables that we
don't use in each of the subdomains have no degrees of freedom (and are
constant zero), but for many purposes we will still have to be able to ask
for the value of all 2*dim+1 vector components of the solution at quadrature
points on all cells -- for example to generate graphical output. In other
words, I think that for such things we will eventually have to think about
allowing the evaluation of FE_Nothing at quadrature points anyway.
But we don't have to have everything working right from the start :-)
> Test 3 looks at making hanging node constraints. The first issue I
> encountered was that the FENothing did not implemt the new way of
> handling hp constraints, so I added trivial implementations of the
> necessary get_face_interpolation_matrix calls.
This looks alright.
> The real issue I now am
> running into, for both tests 3 and 4, is that the other elements in
> the library don't know how to treat the FENothing. I know we
> originally set the FEQ to be the dominant element, but might it make
> sense to set the FENothing to always be dominant? The FENothing will
> always know how to handle constraints regardless of the other element
> type (i.e. just don't apply any constraints) but the reverse is not
> true unless we add additional if statements to all the other element
> definitions in the library.
Good point. Your suggestion sounds right, please change things back where
necessary and make the FENothing the master.
Best & thanks for continuing to work on this!
Wolfgang
PS: I've checked in your changes to fe_nothing.{h,cc} as well as the first two
testcases. In the future, when you make changes to files that are already in
svn, can you just send me the result of 'svn diff', rather than the whole
file?
-------------------------------------------------------------------------
Wolfgang Bangerth email: [email protected]
www: http://www.math.tamu.edu/~bangerth/
_______________________________________________
dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii
