Lars,
I don't think anything particularly complicated is necessary -- you may
just have to copy the support points from the base elements (or
generalized points if the regular ones are not available) to the
FESystem's ones. The interleaving will work just like for all of the other
information being copied together.
I have implemented building the generalized support points, which is indeed
not hard.
Great. Do one step at a time -- make this into a pull request!
I have not had enough time to look into the interpolation functions.
Those seem to require some more work to adjust the input values before passing
them to the base element, for which I have to study a bit on how they work.
You mean the implementations of FiniteElement::interpolate in FESystem? I
would say hold on with this for a couple of weeks, the function is going to be
replaced soon:
https://github.com/dealii/dealii/issues/3810
It's a good question whether that will work. I have to admit that I don't
know -- it's quite possible that the function is only meant to be used for
primitive elements. But the patch is definitely not going to make anything
worse. Give it a try (in a separate pull request).
I als ochanged this, but it does not work. The problem is, that it trips over
'face_system_to_component_index', which does not work for non primitive
elements (like the RT-elements I'm using). That function is used to determine
which sets of dofs form components at the support points.
Yes, I was afraid that was going to happen. In hindsight, it makes sense that
the function doesn't actually work for non-primitive functions.
Furthermore, even if this could be fixed for non primitive elements, I have
some doubts that the rest of the function will work with generalized face
support points and non primitive elements.
I don't think it can be made to work with non-primitive elements. But it is
conceivable that it can be made to work with FESystem objects for which the
relevant vector components are primitive, but the whole FESystem is not and
for which the relevant vector components have face support points but the
whole system only has generalized face support points.
Though I have to say that my
experience with either of them is practically zero. The algorithm that the
function follows is, if I read it correctly, to find at each support point dim
dofs, which form the dim components of the vector at that support point.
Correct.
After
handling the sharing of points/dofs between cells, it enforces that the found
dofs should match the normal constraint. Now I think that for non primitive
elements it will probably not find the dim independent dofs which share the
support point. While for generalized support points the assumption that dofs
can be coupled to a single support point and then be constraint seems
incorrect. Though again, this is speculation due to my limited knowledge with
both deal ii and non primitive elements.
Your speculation is exactly right.
Please let me know if I can do something with it, like putting a warning above
the relevant function. For my own project I think I will, unfortunately, hate
to use some alternative (hacky) ways to enforce the constraint, due to time
constraints.
But there is an H-div conforming projection function in the same namespace
that should work for your case.
Best
W.
--
------------------------------------------------------------------------
Wolfgang Bangerth email: bange...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups "deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dealii+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
