Open kronbichler opened 4 years ago
This is a good idea!
I guess then we can also eliminate this mess:
and maybe part of this:
Move the include/deal.II/matrix_free/shape_info.{h,templates.h} files to the fe/ subfolder, extract it from the internal namespace and give it a proper name. I was thinking along the lines FiniteElementTensorProductInformation. I would put a template for the number type on this class but not the dimension as a tensor product element is in principle not restricted to a particular dimension.
I just wanted to suggest the same!
I guess then we can also eliminate this mess: [some ugly code in the multigrid transfer]
I hope that we can do; however, this means we need to add another field to the ShapeInfo
class for the parent/child relation we use in GMG (which is useful information and cheap to obtain anyway).
@kronbichler Let me know if I can do something or try something out. I have simply copied those two code snippets to my new transfer operators, but I am not happy with that...
I will have a look at my code maybe I find some additional requirements!
The evaluator side also relates to #7039 that should be generalized/restructured in one go.
This PR will involve some time we don't have at the time. Adjusting the milestone.
In #14385 we noticed that the cases where we need special treatments, to be addressed by this PR, just keep increasing. I think we should aim for this effort before the next release.
This is a place where this would be useful:
since we could replace the full matrix-vector product by sum factorization.
The information for the tensor product information of certain
FiniteElement
classes is extracted in the structinternal::MatrixFreeFunctions::ShapeInfo
from a given finite element object and a 1D quadrature formula. We do this by some dynamic cast magic in https://github.com/dealii/dealii/blob/1f3f4df3cd5e84a140e453b227608d5e83079789/include/deal.II/matrix_free/shape_info.templates.h#L103-L128 but this is not a real solution and does not scale if we want to support more elements (and I want to add some tensor product evaluators for RT and Nedelec with appropriate basis functions). The real solution is to add this as an interface to theFiniteElement
classes and let them return tensor product information. I plan to do this in three steps:include/deal.II/matrix_free/shape_info.{h,templates.h}
files to thefe/
subfolder, extract it from the internal namespace and give it a proper name. I was thinking along the linesFiniteElementTensorProductInformation
. I would put a template for the number type on this class but not the dimension as a tensor product element is in principle not restricted to a particular dimension.FiniteElement<dim,spacedim>::extract_tensor_product_information(const Quadrature<1> &quadrature, const unsigned int base_element_index = 0)
that returns aFiniteElementTensorProductInformation<double>
. ForFESystem
, the data is filled partly by the children.MatrixFree
by copying to the chosenNumber
type there (e.g.VectorizedArray<float>
) and create an alias at the existingShapeInfo
place.What I want to discuss here before I start is the naming (any suggestions?) and how exactly we would like to set up the interface. One can think of this class/struct as a collection of arrays with evaluation of 1D shape functions along a 1D quadrature and for various combinations of faces/subfaces, so it is pretty low-level and a bit similar to the
InternalDataBase
objects inFiniteElement
, but without the inheritance within the class.