Open cedricchevalier19 opened 2 years ago
Thoughts inspired from the 12 factors best practices (used in cloud computing,...)
Generic Alien Plugins should be configured either
configureFromEnv()
)configureFromFile(std::string const& filename)
)configure(int args, char*[] argv)
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
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.
Proposition of common generic keyword
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.
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.
Solver options
Algorithms
Control
Preconditioners
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.