Open tamiko opened 10 months ago
I am opening this issue to get some consensus on how to fix this - before I touch about every finite element to switch over to the Lazy<>
wrapper for restriction/prolongation matrices. :smiley:
My gut feeling is that this method actually has very little utility... (and the documentation clearly states this as well).
I'm fine with just deprecating these functions. it's easy enough to duplicate the implementation in the tests if we really want it.
The functions don't appear to be used widely. I can only find these places:
1/dealii> grep -r prolongation_is_implemented tests
tests/fe/fe_prolongation_common.h: if (fe.isotropic_prolongation_is_implemented())
1/dealii> grep -r restriction_is_implemented tests
tests/fe/fe_restriction_common.h: if (fe.isotropic_restriction_is_implemented())
tests/bits/fe_tools_08.cc: if (!fe2.isotropic_restriction_is_implemented())
tests/mpi/fe_tools_extrapolate_common.h: if (!fe2.isotropic_restriction_is_implemented())
tests/mpi/fe_tools_extrapolate_common.h: if (!fe2.isotropic_restriction_is_implemented())
So yes, deprecation sounds reasonable if it's not easy to fix them.
When doing something like this:
I expect the program to simply print a
0
for false. Instead it throws an exception:This is due to the fact that we call this function in
FiniteElement<dim, spacedim>::restriction_is_implemented()
:because we base the decision whether we have restriction/prolongation matrices on the fact that they are initialized... This is a problem because
get_restriction_matrix(...)
has to be able to signal an error condition (which it happily does with a call toAssert(...)
.).