Kratos Structure: Basic Components
As a library, Kratos intends to help users develop easier and faster their own finite element code, taking advantage of the generic components provided by the Kratos Kernel or the features implemented in the different applications. As such, in the design of Kratos, the needs of three different types of potential users where considered:
- Finite Element Developers These developers are considered to be more expert in FEM, from the physical and mathematical points of view, than C++ programming. For this reason, Kratos has to meet their needs without involving them in advanced programming concepts.
- Application Developers These users are less interested in finite element programming and their programming knowledge may vary from very expert to higher than basic. They may use not only Kratos itself but also any other applications provided by finite element developers, or other application developers. Developers of optimization programs or design tools are the typical users of this kind.
- Package Users Engineers and designers are a third group of users of Kratos. They use Kratos and its applications to model and solve their problem as a closed package, without getting involved in its implementation details. For these users Kratos has to provide a flexible external interface to enable them use different features of Kratos without requiring them to modify its internal structure.
Object Oriented Design
Kratos follows an object oriented design philosophy, which is based on splitting a problem into multiple individual objects and defining their interactions through a common interface. In the case of Kratos, these objects tend to reproduce concepts from the finite element literature when possible, as seen in the following scheme.
Vector, Matrix, and Quadrature are designed by basic numerical concepts. Node, Element, Condition, and Dof are defined directly from finite element concepts. Model, Mesh, and Properties are coming from practical methodology used in finite element modeling completed by ModelPart, and SpatialContainer, for organizing better all data necessary for analysis. IO, LinearSolver, Process, and Strategy are representing the different steps of finite element program flow. and finally Kernel and Application are defined for library management and defining its interface.
These main objects are described below:
- Vector Represents the algebraic vector and defines usual operators over vectors.
- Matrix Encapsulate matrix and its operators. There are different matrix classes are necessary. The most typical ones are dense matrix and compressed row matrix.
- Quadrature Implements the quadrature methods used in finite element method. For example the gaussian integration with different number of integration points.
- Geometry Defines a geometry over a list of points or Nodes and provides from its usual parameter like area or center point to shape functions and coordinate transformation routines.
- Node Node is a point with additional facilities. Stores the nodal data, historical nodal data, and list of degrees of freedom. It provides also an interface to access all its data.
- Element Encapsulates the elemental formulation in one objects and provides an interface for calculating the local matrices and vectors necessary for assembling the global system of equations. It holds its geometry that meanwhile is its array of Nodes. Also stores the elemental data and interface to access it.
- Condition Encapsulates data and operations necessary for calculating the local contributions of Condition in global system of equations. Neumann conditions are example Conditions which can be encapsulated by derivatives of this class.
- Dof Represents a degree of freedom (dof). It is a lightweight object which holds the its variable, like TEMPERATURE, its state of freedom, and a reference to its value in data structure. This class enables the system to work with different set of dofs and also represents the Dirichlet condition assigned to each dof.
- Properties Encapsulates data shared by different Elements or Conditions. It can stores any type of data and provide a variable base access to them.
- Model Stores the whole model to be analyzed. All Nodes, Properties, Elements, Conditions and solution data. It also provides and access interface to these data.
- ModelPart Holds all data related to an arbitrary part of model. It stores all existing components and data like Nodes, Properties, Elements, Conditions and solution data related to a part of model and provides interface to access them in different ways.
- Mesh Holds Nodes, Properties, Elements, Conditions and represents a part of model but without additional solution parameters. It provides access interface to its data.
- SpatialContainer Containers associated with spacial search algorithms. This algorithms are useful for finding the nearest Node or Element to some point or other spacial searches. Quadtree and Octree are example of these containers.
- IO Provides different implementation of input output procedures which can be used to read and write with different formats and characteristics.
- LinearSolver Encapsulates the algorithms used for solving a linear system of equations. Different direct solvers and iterative solvers can be implemented in Kratos as a derivatives of this class.
- Strategy Encapsulates the solving algorithm and general flow of a solving process. Strategy manages the building of equation system and then solve it using a linear solver and finally is in charge of updating the results in the data structure.
- Process Is the extension point for adding new algorithms to Kratos. Mapping algorithms, Optimization procedures and many other type of algorithms can be implemented as a new process in Kratos.
- Kernel Manages the whole Kratos by initializing different part of it and provides necessary interface to communicate with applications.
- Application Provide all information necessary for adding an application to Kratos. A derived class from it is necessary to give kernel its required information like new Variables, Elements, Conditions, etc.
The main intention here was to provide a clear separation between the most basic components, such as the data structure and the IO, that are critical for perfomance and require a relatively advanced computer science background to design and implement efficiently, and the higher level components derived from finite element analysis, that are not as performance critical but are more involved from an engineering or mathemathical point of view.
Multi-Layered Design
Kratos uses a multi-layer approach in its design, in which each object only interacts with other objects in its layer or in a more basic layer. Layering reduces the dependency inside the program. It helps in the maintenance of the code and also helps developers to better understand the code and clarify their tasks.
In designing the layers of the structure, the different user types mentioned before are considered. The layering is done in a way that each user has to work in the minimum number of layers as possible. In this way the amount of the code to be known by each user is minimized and the chance of conflict between users in different categories is reduced. This layering also lets Kratos to tune the implementation difficulties needed for each layer to the knowledge of users working in it. For example the finite element layer uses only basic to average features of C++ programming but the main developer layer use advanced language features in order to provide the desirable performance.
Following these design principles, Kratos is organized in the following layers:
- Basic Tools Layer Holds all basic tools used in Kratos. In this layer using advance techniques in C++ is essential in order to maximize the performance of these tools. This layer is designed to be implemented by an expert programmer and with less knowledge of FEM. This layer may also provides interfaces with other libraries to take benefit of existing work in area.
- Base Finite Element Layer This layer holds the objects that are necessary to implement a finite element formulation. It also defines the structure to be extended for new formulations. This layer hides the difficult implementations of nodal and data structure and other common features from the finite element developers.
- Finite Element Layer The extension layer for finite element developers. The finite element layer is restricted to use the basic and average features of language and uses the component base finite element layer and basic tools to optimize the performance without entering into optimization details.
- Data Structure Layer Contains all objects organizing the data structure. This layer has no restriction in implementation. Advanced language features are used to maximize the flexibility of the data structure.
- Base Algorithms Layer Provides the components building the extendible structure for algorithms. Generic algorithms can also be implemented here to help developer in their implementation by reusing them.
- User's Algorithms Layer Another layer to be used by finite element programmers but at a higher level. This layer contains all classes implementing the different algorithms in Kratos. Implementation in this layer requires medium level of programming experience but a higher knowledge of program structure than the finite element layer.
- Applications' Interface Layer This layer holds all objects that manage Kratos and its relation with other applications. Components in this layer are implemented using high level programming techniques in order to provide the required flexibility.
- Applications Layer A simple layer which contains the interface of certain applications with Kratos.
- Scripts Layer Holds a set of IO scripts which can be used to implement different algorithms from outside Kratos. Package users can use modules in this layer or create their own extension without having knowledge of C++ programming or the internal structure of Kratos. Via this layer they can activate and deactivate certain functionalities or implement a new global algorithm without entering into Kratos implementation details.
The layers described here are summarised in the following figure
