7 Adding new smoother and solver objects to MLD2P4

Developers can add completely new smoother and/or solver classes derived from the base objects in the library (see Remark 2 in Section 6.2), without recompiling the library itself.

To do so, it is necessary first to select the base type to be extended. In our experience, it is quite likely that the new application needs only the definition of a “solver” object, which is almost always acting only on the local part of the distributed matrix. The parallel actions required to connect the various solver objects are most often already provided by the block-Jacobi or the additive Schwarz smoothers. To define a new solver, the developer will then have to define its components and methods, perhaps taking one of the predefined solvers as a starting point, if possible.

Once the new smoother/solver class has been developed, to use it in the context of the multilevel preconditioners it is necessary to:

• declare in the application program a variable of the new type;
• pass that variable as the argument to the set routine as in the following:

  call p%set(smoother,info [,ilev,ilmax,pos])
  call p%set(solver,info [,ilev,ilmax,pos])

• link the code implementing the various methods into the application executable.

The new solver object is then dynamically included in the preconditioner structure, and acts as a mold to which the preconditioner will conform, even though the MLD2P4 library has not been modified to account for this new development.

It is possible to define new values for the keyword WHAT in the set routine; if the library code does not recognize a keyword, it passes it down the composition hierarchy (levels containing smoothers containing in turn solvers), so that it can be eventually caught by the new solver. By the same token, any keyword/value pair that does not pertain to a given smoother should be passed down to the contained solver, and any keyword/value pair that does not pertain to a given solver is by default ignored.

An example is provided in the source code distribution under the folder tests/newslv. In this example we are implementing a new incomplete factorization variant (which is simply the ILU(0) factorization under a new name). Because of the specifics of this case, it is possible to reuse the basic structure of the ILU solver, with its L/D/U components and the methods needed to apply the solver; only a few methods, such as the description and most importantly the build, need to be ovverridden (rewritten).

The interfaces for the calls shown above are defined using

The other arguments are defined in the way described in Sec. 6.2. As an example, in the tests/newslv code we define a new object of type mld_d_tlu_solver_type, and we pass it as follows: