Interface of MultigridPreconditioner regarding Dirichlet boundaries

[nfehn]

Currently, the interface of the multigrid preconditioner contains the two data structures

std::map<dealii::boundary, dealii::Function>
std::map<dealii::boundary, dealii::ComponentMask>

(where the first map needs to include all boundary IDs and where we have the implicit convention in the code that a default component mask will be used if the corresponding boundary ID is not part of the second map).

The problem that I see is that dealii::Function in the first parameter above is never used, since multigrid applies only homogeneous Dirichlet boundary data. In this sense, it is a poor design.

I see the following options:

1. just remove the function and change the first parameter from map to set

std::set<dealii::boundary>
std::map<dealii::boundary, dealii::ComponentMask>

2. realize the logic deciding whether to use a default component mask or not outside multigrid, and pass only a single parameter to multigrid

std::map<dealii::boundary, dealii::ComponentMask>

The multigrid preconditioner implementation aims to be generic. There might be problems that do not use ComponentMask. Then, the design option 2. might be considered limitating as one is forced to use ComponentMask, while one could argue to hand over an empty map in case of design option 1.

3. Hence, the third alternative might be to introduce a new data structure

struct DirichletBoundaryData (whatever this looks like internally)

handed over to multigrid, in order to have full flexibility on the one hand, and avoid the need to change the multigrid interface again and again (as we observed in the past) when adding new functionality. Similar criticism holds as for option 2: Why should one use a more complicated data structure if the problem at hand is very basic, i.e. standard Dirichlet BCs with default component mask? Nevertheless, I wonder whether other function spaces (e.g. Hdiv) might call for option 3.

This issue originates from c3dc80b and will then probably initiate follow-up PRs for multigrid.

@kronbichler @bugrahantemur I am happy to hear your opinion.

[bugrahantemur]

I think the first option is elegant:

• we have a separate set of boundaries. This set has a clear meaning: just holding all possible boundary ids. No functions, nothing. This is also relevant for any type of problem, as you say.
• we also have a second data structure, a map of some boundary ids to component masks, which has a clearly different purpose from the set holding all boundary ids.

For me this is pretty good.

Of course, if problems with a different data type than component mask are looming on the horizon, option 3 may be inevitable and actually be a good abstraction. At first, very simply, it may even just be a wrapper around option 2, I guess. Unfortunately I am not able to say anything about the necessities from Hdiv, etc.