How to construct the "solving strategies"

Latest revision as of 11:26, 27 August 2013

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

 - ConstructSolver

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.AddVariables( 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.AddDofs( 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 [[1]].

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.