# How to construct the "solving strategies"

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 | |

− | + | - 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. | 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: | In order to solve this problem, each python solver class will be required to provide 3 additional functions: | ||

− | - AddDofsUtility | + | - AddDofsUtility |

− | - AddVariablesUtility | + | - AddVariablesUtility |

− | - ConstructSolver | + | - 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 | 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 | ||

Line 31: | Line 31: | ||

where "solver_type" is expected to be a string with the name of the file in which the desired solver is implemented. | 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) | + | 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 | for example a suitable constructor for a fractional step solver could be something of the type | ||

Line 56: | Line 56: | ||

max_iteration = 1000 | max_iteration = 1000 | ||

tolerance = 1e-3 | tolerance = 1e-3 | ||

+ | |||

+ | this shows how the settings can include nested subclasses to be used in the construction process. | ||

+ | This "SolverSettings" shall be defined in the "project_settings.py" file, which shall be read by the | ||

+ | main python script. | ||

+ | |||

+ | Conceptually the solver can be then constructed within the main script by doing | ||

+ | |||

+ | #import applications as needed | ||

+ | from KratosMultiphysics import * | ||

+ | from KratosMultiphysics.FluidDynamicsApplication import * | ||

+ | from KratosMultiphysics.IncompressibleFluidApplication import * | ||

+ | ... | ||

+ | |||

+ | #construct the model part(s) needed | ||

+ | fluid_model_part = ModelPart( "fluid" ) | ||

+ | ... | ||

+ | |||

+ | #read solver settings from configuration file | ||

+ | #note that more than one solver can be defined in the project_settings! | ||

+ | import project_settings | ||

+ | SolverSettings = project_settings.SolverSettings1 | ||

+ | |||

+ | #import solver file | ||

+ | solver_constructor = __import__(SolverSettings.solver_type) | ||

+ | ... | ||

+ | |||

+ | #define variables to be stored -- note that this shall be done just after defining the model part and before the reading phase | ||

+ | solver_constructor.AddVariablesUtility( fluid_model_part, SolverSettings) | ||

+ | |||

+ | #define dofs to be stored - to be done after reading the model part and setting the buffer size | ||

+ | model_part.SetBufferSize( 3 ) #or to the required number | ||

+ | solver_constructor.AddDofsUtility( fluid_model_part, SolverSettings1) | ||

+ | ... | ||

+ | |||

+ | #construct the solver | ||

+ | fluid_solver = solver_constructor.CreateSolver( fluid_model_part, SolverSettings) | ||

+ | |||

+ | #between constructor and initialize one can force custom flags from the main file | ||

+ | ... | ||

+ | fluid_solver.Initialize() |

## Revision as of 07:24, 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

this shows how the settings can include nested subclasses to be used in the construction process. This "SolverSettings" shall be defined in the "project_settings.py" file, which shall be read by the main python script.

Conceptually the solver can be then constructed within the main script by doing

#import applications as needed from KratosMultiphysics import * from KratosMultiphysics.FluidDynamicsApplication import * from KratosMultiphysics.IncompressibleFluidApplication import * ...

#construct the model part(s) needed fluid_model_part = ModelPart( "fluid" ) ...

#read solver settings from configuration file #note that more than one solver can be defined in the project_settings! import project_settings SolverSettings = project_settings.SolverSettings1 #import solver file solver_constructor = __import__(SolverSettings.solver_type) ...

#define variables to be stored -- note that this shall be done just after defining the model part and before the reading phase solver_constructor.AddVariablesUtility( fluid_model_part, SolverSettings)

#define dofs to be stored - to be done after reading the model part and setting the buffer size model_part.SetBufferSize( 3 ) #or to the required number solver_constructor.AddDofsUtility( fluid_model_part, SolverSettings1) ... #construct the solver fluid_solver = solver_constructor.CreateSolver( fluid_model_part, SolverSettings) #between constructor and initialize one can force custom flags from the main file ... fluid_solver.Initialize()