Common interface to set generic solver parameters

[cedricchevalier19]

Generic solver parameters

Alien currently has options to specify solver parameters, but these options are specific for a given solver lib. The goal of this request is to design and implement a way to have generic options that works with all libraries.

• list solver and preconditioner options that we want to share between libraries,
• choose names for these options,
• describe an implementation to pass these options to solver libraries.

Solver options

Algorithms

• CG
• BiCGStab (which order ?)
• GMRES (size of the basis ? orthogonalization method ?)

Control

• maximum number of iterations
• residual tolerance (in which norm ? explicit ?)

Preconditioners

• Diagonal
• Incomplete factorization (IC, ILU [ILU(k) or ILU(t) ?])
• AMG (cycle, smoother, ?)

Implementation proposal: using converters

It would be great to handle parameters like we do with matrices and vectors. We do not need to specify a common parameters interface that would be inherited by solver libraries: we can write, in each plugin a specific converter that handle how to express the generic parameters with the specific option object.

If so, we can have very specific solver options in plugins (that match the external solver interface) and a common way to call solvers with very high level parameters.

Notes

Needs were formulated by end-users for direct use from C++, but it might be also a good way to provide a C API (see #35) and thus derive Alien's API for different languages like Python or Rust.

[gratienj]

Thoughts inspired from the 12 factors best practices (used in cloud computing,...)

Generic Alien Plugins should be configured either

• with environment varaibles (implement configureFromEnv())
• fron config file (implement configureFromFile(std::string const& filename))
• command line style (implement configure(int args, char*[] argv)
• generic tree parameter option object configureFromOptions(Alien::Option const& opt)

Environment , Configuration file, command line options, Alien::Options are a list of
(key, value) where key are string, value are builtin types (int, float, double, string) or recursive child option types

Example of Environment settings

export toto=3.14
export solver.name=CG
export solver.precond.name=ILU

Config file of type json

{
  toto: "3.14",
  solver: {
     name: "CG",
     tol: "1e-10",
     precond: {
        name: "ILU"
     }
}

command line

--toto=3.14 --solver.name="CG" --solver.tol=1.e-10 --solver.precond.name="ILU"

Code

Struct Options ;
Struct Options {
std::map<std::string,int> m_int_parameters ;
std::map<std::string,double> m_double_parameters ;
....
std::map<std::string,Options> m_option_parameters ;
}

Je passe en français
On peut définir des options générics pour configurer les packages, les instances solvers et controler les résolutions et avoir
des options spécifics à chaque plugins

C'est à chaque plugin d'implémenter l'interprétations des options ou de valider les options qu'on lui passe ( dire si il sait interpréter un jeu d'options ou pas, si des options sont required ou pas, si il propose des valeurs par défaut)

Enfin dans chaque plugin, chacun peut utiliser les outils qu il veut pour implémenter ces concepts comme il veut, sachant plein de system de génération de code peut permettre de générer des implémentations de type boost::program_options, ou des axl et service arcane ou le système d'options interne du plugin.

La grammaire des options génériques Alien peut rester pour l'instant limiter et réduite si il n y a pas consensus, sachant que le langage mathématiques permet de définir des concepts clairs et unifiés sans ambiguïtés

[cedricchevalier19]

To try to sum up:
basically, there is a need for a data structure that can be de-serialized from environment variables, json file, command line options, Arcane config file, ...

However, I would rather limit the common options. Specific solver options might have a similar interface, but I think we should limit, even hard code, options that are mandatory.

[gratienj]

Proposition of common generic keyword

• solver.name :[cg,bicgs,gmres,amg,lu] (in lowercase character)
• precond.name : diag,ilu,amg or any solver keywords with righ control parameters
• tol, max-iter, level for any iterative or multi-level algorythms (ex bicgs.tol gmres.max-iter, ilu.tol ilu.level,...) have to be use in a hierachical way (the value is related of the parent option keyword) for example bigcs.tol is related to solver bicgs, bicgs.amg.tol is related to amg as preconditioner of bicgs, bicgs.ilu.level is related to ilu as precond of bicgs

stop-criteria should be explicit L1'(r, r/b, r/r0)) or L2'(r, r/b, r/r0) or if using default, we shoud have the explicit default value

I thing these few common keywords can cover most of the usage in a strict and non ambiguous way for application users

It is up to each plugin to implement this grammar and convert it to the used package specific configuration system.