Common Python Interface of Applications for Users

ATTENTION, this is WORK IN PROGRESS

See current pull requests:

• https://github.com/KratosMultiphysics/Kratos/pull/2068
• https://github.com/KratosMultiphysics/Kratos/pull/2135

Overview

1. Introduction
2. AnalysisStage
   1. AnalysisStage: Overview
   2. AnalysisStage: Responsibilities and provided Functionalities
   3. Note for developers
3. PythonSolver
   1. PythonSolver: Overview
   2. PythonSolver: Responsibilities and provided Functionalities
4. Future Outlook

Introduction

Solving a problem with Kratos is divided into two Python-objects : The AnalysisStage and the PythonSolver.

The PythonSolver is responsible for everything related to the physics of the problem (e.g. how to setup the system of equations), whereas the AnalysisStage is related to everything that is not related to the physics (e.g. when and what output to write).

The PythonSolver is a member of the AnalysisStage, therefore the AnalysisStage can be seen as "outer" layer and the PythonSolver as "inner" layer.

AnalysisStage

AnalysisStage: Overview

The AnalysisStage is a python class located in the KratosCore, that serves as a common interface for the applications. The idea is that the applications derive from this object to implement things specific to each application. These derived classes replace the previously used MainKratos.py. This way the interface to the applications is unified.

Responsibilities of the AnalysisStage: Basically everything that is not related to the physics of a problem. Everything related to the physics of the problem is handled by the PythonSolver (see below)

This includes e.g.

• Managing and calling the PythonSolver
• Construction and handling of the Processes
• Managing the output (post-processing in GiD/h5, saving restart, ...)

as well as the User Scripting: Formerly the user-scripting was done directly in the MainKratos.py file. This had the disadvantage that it became outdated with internal updates of Kratos.

Now the intended use is that users derive their scripts from the AnalysisStage classes in the applications and override the functions in which they want to change/add some self-defined things. This way the user-scripts are less likely to become outdated since they only override a small portion of the entire class.

AnalysisStage: Responsibilities and provided Functionalities

The implementation of the AnalysisStage can be found here. It shall be referred to the implementation for an exact description of what the individual functions are doing, see their docstrings.

PythonSolver

PythonSolver: Overview

PythonSolver: Responsibilities and provided Functionalities

The implementation of the PythonSolver can be found here. It shall be referred to the implementation for an exact description of what the individual functions are doing, see their docstrings.

The responsibility of the PythonSolver is to solve the physical problem. This also involves the coupling of two or more PythonSolvers. I.e. and FSISolver would have a Fluid and a Structural solver as well as the data exchange (mapping) and the coupling logic.

The AnalysisStage Object is designed to solve an entire Simulation. This means that it sets up the Boundary conditions, IO, reading of the ModelPart and Materials, controlling the time-stepping etc. It does not know abt how to solve the physical problem. This is the task of the PythonSolver. This class implements everything that is related to solve the physical problem, e.g. it constructs Strategy, BuilderAndSolver,... Everything else (e.g. reading the ModelPart) is excluded form the Solver and part of the AnalysisStage.

Furthermore, it knows abt which Variables and DOFs it needs and adds them to the ModelPart It does NOT read the ModelPart, this is task of the AnalysisStage. After the ModelPart is read, the solver might need to perform some operations on it (e.g. create the ComputingModelPart), this is done with PrepareModelPartForSolver.

Base Class of the Solver Object (in Kratos Core):

Outlook (Kratos-Project, Multi-Stage Simulation)

Note This is a collection of ideas, to be done AFTER AnalysisStage and Solver are implemented in a first version. Please note that the following is in a very early design phase.

In the future the objects presented here can be used in a larger context, e.g. a Multi-Stage Analysis. This means that e.g. a FormFinding Analysis can be performed with doing a FSI-simulation afterwards. The above mentioned objects are already designed for this, e.g. a ModelPart can be passed from outside to the AnalysisStage, this means that it can be used in severals AnalysisStages.

The idea is that in the beginning all AnalysisStages are constructed (i.e. all necessary Variables are added to the ModelPart), then the ModelPart is being read. This can be done e.g. by a global ModelManager. For this to work the Model has to be enhanced, therefore it should be done later.

This could look like this:

import KratosMultiphysics

##construct all the stages  

Model = KratosMultiphysics.Kernel().GetModel() #if we want it to be somewhere else more than fine
list_of_analysis_stages = GenerateStages(Model, "ProjectParameters.json") #internally loads the applications needed

model_manager.Read(list_of_analysis_stages, Model)
for solver in list_of_solvers:
    solver.Initialize()
    solver.Run()
    solver.Finalize()