How to construct the "solving strategies"
How to use an unified construction format for the "Solver"
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, a new function
accepting the parameter "config" and the list of model_parts needed has to be added to the Solver module. 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, SolverSettings) ... #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()
Description of the solver-side implementation
Existing python "Solver" implementations are required to modify the method
"AddDofs" and "AddVariables" by adding a parameter "config" defaulting to None.
furthermore a method ConstructSolver accepting the model part and the "config" shall be added. within this method the writer of the Solver shall read the required parameters from the config and assign them to the internals as required. An example can be found at the link [].
We remark that optional values may not be prescribed in the "config". The Solver writer shall hence check if they exist in config (method hasattr(config,parameter_name)) before actually assigning them to the internals. Compulsory values can be assigned directly.