You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While reviewing #15141, I realized once more that https://github.com/dealii/dealii/blob/master/include/deal.II/matrix_free/constraint_info.h, i.e., internal::MatrixFreeFunctions::ConstraintInfo duplicates too much information from internal::MatrixFree::DoFInfo, to be usable in the context of multigrid algorithms. As posted in #13519 (review), we should really aim to see this class as an intermediate step towards a possible restructuring in the interfaces, not a long-term solution.
In view of #14968 (that unfortunately seems to be low-priority), this is also a serious performance concern. One possible solution to the performance aspects would be to try if some of the two-level transfer objects (essentially all non-geometric ones that use two DoFHandler objects based on the same triangulation) can use the MatrixFree objects directly and only link the two indices with each other. Now that we have
from #13260, this should be rather simple. Of course, we still have the code duplication aspects, that also need to addressed. However, I consider the performance aspects (and the associated memory consumption) even more important.
The text was updated successfully, but these errors were encountered:
While reviewing #15141, I realized once more that https://github.com/dealii/dealii/blob/master/include/deal.II/matrix_free/constraint_info.h, i.e.,
internal::MatrixFreeFunctions::ConstraintInfo
duplicates too much information frominternal::MatrixFree::DoFInfo
, to be usable in the context of multigrid algorithms. As posted in #13519 (review), we should really aim to see this class as an intermediate step towards a possible restructuring in the interfaces, not a long-term solution.In view of #14968 (that unfortunately seems to be low-priority), this is also a serious performance concern. One possible solution to the performance aspects would be to try if some of the two-level transfer objects (essentially all non-geometric ones that use two
DoFHandler
objects based on the same triangulation) can use theMatrixFree
objects directly and only link the two indices with each other. Now that we havedealii/include/deal.II/matrix_free/fe_evaluation.h
Lines 2144 to 2145 in aef0f70
The text was updated successfully, but these errors were encountered: