Hi Lukas:
I still have one main point that I do not understand about both current
nedelec implementations in deal.II.
Instead of the approach to include the reorientation of Dofs in the
scatter-gather process of the DoF handler, both implementations include
the reorientation in the Finite element.
Yes. I think this is probably best understand not as a conscious design
decision, but in historic context: The first elements that were
implemented (for the first several years of deal.II) all had no issues
with orientations because they were scalar and/or only implemented for
2d meshes that could always be assumed to be correctly oriented. The
design of the DoFHandler and the scatter-gather process simply made no
accommodation for orientations because we did not foresee the issue :-(
I can't say that I remember why the people who implemented the first RT
or Nedelec elements made a conscious decision at the time that the
FiniteElement class would be the best place to handle this -- it may
simply be that that's a place they understood, and so put it in there.
This leads to a prolongation matrix that does not only depend on the
childindex, but also on the edge orientations of parent and children edges.
But the deal.ii interface for the finite elements does not reflect this
dependence, and I do not see how the user is supposed to access this
reorientation information.
Yes, that is true, and if you were to use these elements in schemes
where you actually require prolongation and restriction matrices, you
will probably get wrong results (or at least sub-optimal convergence).
That would specifically cover multigrid and the SolutionTransfer class,
and perhaps more. These are all clearly bugs.
Is there already a place in the multigrid code that adjusts for the
reorientation, or does multigrid not work for nedelec elements, or am I
missing something?
I don't know the multigrid code well, so don't know for sure -- but
would not at all be surprised if that just doesn't work on meshes that
are not consistently oriented.
From a pragmatic perspective, one can then of course ask how to move
forward. I think a reasonable approach would be to add an argument to
the functions that compute restriction and prolongation matrices that
refers to a specific cell from which one can obtain relative
orientations, and let these functions then return corrected information.
That might be a nice incremental approach because for most elements, the
answer is "same as before", and one just needs to fix the Nedelec and
RT-type elements. A next step would then involve finding all the places
where these functions are called and pass in whatever cell is currently
pertinent. We'd of course be very happy to take patches in this regard.
Perhaps if one had to re-write the DoFHandler today, moving this
functionality there might also be an option, but I think that is just
very difficult to add today. The DoFHandler only knows "on this edge, we
have 3 DoFs". It knows nothing of their properties, whether they are
associated with specific locations along the edge, have vector
transformation properties, etc. This sort of information is not
exchanged right now between FE and DoFHandler, and I imagine that
writing this sort of interface and getting this all right in DoFHandler
(plus using it in downstream code) is going to be a long project that is
difficult to get right and complete -- this is the sort of thing that
may perhaps be conceptually right to do, but in practice often leads to
"incomplete transitions". My preference would be to continue working in
the FiniteElement context where it is easier for me to see how one can
make progress without getting the whole cart stuck in the mud. Of
course, I have also been surprised at times by someone who tackles a
project that I thought was intractable with sufficient energy :-)
I hope all of this helps -- these are the practicalities of large
software projects where not everything has always been thought through
right from the beginning :-(
Cheers
W.
--
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 [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/dealii/ae0570ee-4f75-4f85-b6c1-616c206fff30%40colostate.edu.
