Skip to content

Reorganizing coarse space construction

Created by: searhein

@trilinos/shylu

Description

This pull request introduces several new features and some changes to existing code (to maintain one single framework for all SchwarzOperators).

  • Introduction of a new class that allows for the construction of coarse spaces from a partition of unity on interface of the nonoverlapping domain decomposition and the null space of the operator. Therefore, the class facilitates the construction of GDSW preconditioners for all kinds of problems for which the null space of the operator is known. The new class is called IPOUCoarseOperator for now. In fact, many coarse spaces, such as GDSW, RGDSW, and MsFEM coarse spaces can be constructed in that way.
  • The interface partition of unity is constructed from the partition of the interface into faces, edges, and vertices. Therefore, additional classes had to be introduced, such as CoarseSpace, InterfacePartitionOfUnity, and LocalPartitionOfUnityBasis.

So far, only the GDSW preconditioner can be constructed in that way. The implementation of the construction of the RGDSW coarse space will be the next step.

Motivation and Context

This is another step for providing a Stratimikos/Thyra adapter for FROSch. In order to obtain a general framework for all kinds of model problems, it is useful/necessary to be able to build the coarse space based on the null space of the problem, which should be provided by the user.

How Has This Been Tested?

It was simple to test the new implementation since the iteration counts have to be equal to the iteration counts of the existing implementation. This is the case for a Laplacian model problem and for linear elasticity. In order to test the linear elastic model problem, maps, vectors, and matrices exported from deal.II were used; cf. the test TwoLevelPreconditionerInputFiles.

The resulting iteration counts are equal to the ones obtained from the existing implementation of the GDSW preconditioner for a reasonable number of configurations (combination of the number of subdomains, subdomain size, overlap, dimension, etc.)

Checklist

  • My commit messages mention the appropriate GitHub issue numbers.
  • My code follows the code style of the affected package(s).
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly. The FROSch documentation will be subject of a separate PR.
  • I have read the code contribution guidelines for this project.
  • I have added tests to cover my changes.
  • All new and existing tests passed.
  • No new compiler warnings were introduced.
  • These changes break backwards compatibility.

Merge request reports