# How to construct the "solving strategies"

(→Description of the configuration class) |
|||

Line 6: | Line 6: | ||

As of now, each "solver", contained in the directory "python_scripts" of its application, provides the following public functions: | As of now, each "solver", contained in the directory "python_scripts" of its application, provides the following public functions: | ||

− | - AddDofs | + | -- AddDofs |

− | - | + | -- AddVariables |

− | - "class constructor" | + | -- "class constructor" |

− | - Initialize | + | -- Initialize |

− | - Solve | + | -- Solve |

since the class constructor is allowed in principle to have free format, it is not easy to perform an automatic construction mechanism. | since the class constructor is allowed in principle to have free format, it is not easy to perform an automatic construction mechanism. |

## Revision as of 07:12, 12 July 2013

How to use an unified construction format for the "solving strategies"

This document aims to provide guidelines for the construction of solver strategies in python, with the attempt of giving a unified "look and feel", to mantain backward compatibility, and to ease future maintenance

As of now, each "solver", contained in the directory "python_scripts" of its application, provides the following public functions:

-- AddDofs -- AddVariables -- "class constructor" -- Initialize -- Solve

since the class constructor is allowed in principle to have free format, it is not easy to perform an automatic construction mechanism. In order to solve this problem, each python solver class will be required to provide 3 additional functions:

- AddDofsUtility - AddVariablesUtility - ConstructSolver

each of them accepting a parameter "config" and the list of model_parts needed. The "config" class contains all of the information needed to construct the solver and to set the desired options.

## Description of the configuration class

the configuration class is expected to encapsulate the list of all of the parameters needed to construct the corresponding solver. The minimal configuration is something of the type

class SolverConfig: solver_type = "name_of_solver_python_file"

where "solver_type" is expected to be a string with the name of the file in which the desired solver is implemented.

alternative parameters can be prescribed in the same list, with the limitation that parameters MUST BE OF NATIVE PYTHON TYPE (that is, can NOT be Kratos-defined objects)

for example a suitable constructor for a fractional step solver could be something of the type

##here i give a possible configure for the fractional step solver class SolverSettings1: ##capital as it is a class name solver_type = "vms_fractional_step_solver" ##put it the name of the python script that encapsulates the solver domain_size = 3 predictor_corrector = False velocity_tolerance = 1e-6 pressure_tolerance = 1e-3 class velocity_linear_solver_config: solver_type = "BiConjugate gradient stabilized" scaling = False preconditioner_type = None max_iteration = 500 tolerance = 1e-6 class pressure_linear_solver_config: solver_type = "Conjugate gradient" scaling = True preconditioner_type = "DiagonalPreconditioner" max_iteration = 1000 tolerance = 1e-3