An Object-Oriented Environment For Developing Finite Element Codes For Multi-Disciplinary Applications

Arch Comput Methods Eng (2010) 17: 253–297
DOI 10.1007/s11831-010-9045-2
O R I G I N A L PA P E R
An Object-oriented Environment for Developing Finite Element

Codes for Multi-disciplinary Applications
Pooyan Dadvand · Riccardo Rossi · Eugenio Oñate
Received: 15 December 2009 / Accepted: 15 December 2009 / Published online: 22 July 2010
© CIMNE, Barcelona, Spain 2010
Abstract The objective of this work is to describe the de- multidisciplinary problems are presented in order to demon-
sign and implementation of a framework for building multi- strate the applicability and efficiency of the new object ori-
disciplinary finite element programs. The main goals are ented environment.
generality, reusability, extendibility, good performance and
memory efficiency. Another objective is preparing the code
structure for team development to ensure the easy collab- 1 Introduction
oration of experts in different fields in the development of
multi-disciplinary applications. One of the open topics in the finite element method (FEM),
Kratos, the framework described in this work, contains is the combination of solvers in different fields (thermal,
several tools for the easy implementation of finite element fluid dynamics, structural, etc.) in order to solve multi-
applications and also provides a common platform for the disciplinary problems. The ideal approach to achieve this
natural interaction of different applications. To achieve this, goal is to develop a unified software environment. This re-
an innovative variable base interface is designed and imple- quires however a high investment in terms of software de-
mented. This interface is used at different levels of abstrac- velopment.
tion and showed to be very clear and extendible. A very Kratos, the object oriented framework described in cur-
efficient and flexible data structure and an extensible IO rent paper, has been designed from scratch to address such a
are created to overcome difficulties in dealing with multi- challenge.
disciplinary problems. Several other concepts in existing
works are also collected and adapted to coupled problems. 1.1 Problem
The use of an interpreter, of different data layouts and vari-
able number of dofs per node are examples of such ap- Conventional finite element codes encounter several diffi-
proach. culties in dealing with multi-disciplinary problems involv-
In order to minimize the possible conflicts arising in the ing the coupled solution of two or more different fields.
development, a kernel and application approach is used. The Many of these codes are designed and implemented for solv-
code is structured in layers to reflect the working space ing a certain type of problems, generally involving a single
of developers with different fields of expertise. Details are field. For example, to solve just structural, fluid mechanic,
given on the approach chosen to increase performance and or electromagnetic problems. Extending these codes to deal
efficiency. Examples of application of Kratos to different with another field of analysis usually requires large amounts
of modifications.
A common approach is to connect different solvers via
P. Dadvand () · R. Rossi · E. Oñate a master program which implements the interaction algo-
International Center for Numerical Methods in Engineering rithms and also transfers data from one solver to another.
(CIMNE), Technical University of Catalonia, Campus Norte
This approach has been used successfully in practice but
UPC, 08034 Barcelona, Spain
e-mail: [email protected] has its own problems. First of all having completely sepa-
url: http://www.cimne.com rate programs results in many duplicated implementations,
254 P. Dadvand et al.
which causes an additional cost in code maintenance. In code clarity. Let us consider as an example a thermal prob-
many cases the data transfer between different solvers is not lem for this purpose. In a classical approach one would de-
trivial and, depending on the data structure of each program, fine a variable, possibly named Conductivity to allow
may cause a redundant overhead of copying data from one the element to access its conductivity. This leads to follow-
data structure to another. Finally, this method can be used ing interface:
only for master and slave coupling and not for monolithic
coupling approaches. c = Conductivity()
Some newer implementations have used modern software

engineering concepts in their design to make the program Though this enhances code clarity, it is incompatible with
more extendible. They usually achieve extendibility to new extendibility to new fields. For example if we wish to add the
algorithms in their programs. However, extensions to new “permeability”, another method has to be defined for all ele-
fields is beyond their usual intent. ment class hierarchy. This is a point of conflict when adding
The typical bottlenecks of existing codes for dealing with new formulations.
multi-disciplinary problems are: Another bottleneck in extending the program to new
fields is IO. Each field has its sets of data and results, and
• Predefined set of dofs per node. a simple IO usually is unable to handle new set of data. This
• Data structure with fixed set of defined variables. can cause significant implementation and maintenance costs
• Global list of variables for all entities. that come from updating IO for each new problem to solve.
• Domain based interfaces. Finally introducing new algorithms to existing codes re-
• IO restriction in reading new data and writing new results. quires internal implementation. This causes closed programs
• Algorithm definition inside the code. to be nonextensible because there is no access to their source
These shortcomings require extensive rewriting of the code. For open source programs, this requires the external
code in order to extend it to new fields. developers learn about the internal structure of the code.
Many programs have a predefined set of degrees (dofs)
per node. For example, in a three dimensional (3D) struc- 1.2 Solutions
tural program each node has six dofs dx , dy , dz , wx , wy , wz
where d is the nodal displacement and w the nodal rota- Applying the object-oriented paradigm has shown to be very
tion. Assuming all nodes to have just this set of dofs helps helpful in increasing the flexibility and reusability of codes.
developers to optimize their codes and also simplifies their In this work, object-oriented design is used to organize dif-
implementation tasks. This assumption, however, prevents ferent parts of the code in a set of objects with clear inter-
the extension of the code to another field with a different set faces. In this way the flexibility of the code increases, and
of dofs per node. reusing an object in some other places also becomes more
Usually the data structure of FEM programs is designed practical.
to hold certain variables and historical values. The main rea- Design and implementation of a multi-disciplinary con-
sons for this are: easier implementation, better performance ceptual interface is another solution for previous problems.
of data structure and less effort in maintenance. In spite of In the Kratos design, interfaces are defined in a very generic
these advantages, using rigid data structures usually requires way and independent from any specific concept. The vari-
important changes revision to include new variables from able base interface resulting from this design is very general
other fields. and solves the interface problems arising when extending
Another problem arises when the program’s data struc- the program to new fields.
ture is designed to hold the same set of data for all entities. A flexible and extendible data structure is another solu-
In this case adding a nodal variable to the data structure im- tion to guarantee the extendibility of the code to new con-
plies adding this variable to all the nodes in the model. In cepts. The proposed data structure is able to store any type
the Kratos implementation adding variables of one domain of data associated to any concept. It also provides different
to data structure causes redundant spaces to be allocated for ways for global organization of data required when dealing
them in another domain. For example, in a fluid-structure in- with multi-domains problems. The same strategy is applied
teraction problem, this design requires each structural node to give flexibility in assigning any set of dofs to any node for
to have pressure values and all fluid nodes to have displace- solving new problems.
ment values stored in memory. Even though this is not a An interactive interface is provided in order to increase
restriction, it severely affects the memory efficiency of pro- the flexibility of the code when implementing different al-
gram. gorithms. In this way a new algorithm can be introduced
Additionally, in single purpose programs, it is usual to without the need to be implemented inside the program.
create domain specific interfaces in order to increase the This gives a high level of extendibility to the code and it
An Object-oriented Environment for Developing Finite Element Codes for Multi-disciplinary Applications 255
is very useful for the implementation of optimization and Constrain are added to them in order to handle boundary
multi-disciplinary interaction algorithms. conditions. He also defines a Material class with ability
An automatic configurable IO module is added to these to handle both linear and nonlinear materials. The Assem-
components providing the complete set of solutions neces- blage class holds all these components and encapsulates
sary for dealing with multi-disciplinary problems. This IO the time history modeling of structure.
module uses different component lists to adjust itself when Zimmermann et al. [24, 25, 90] designed a structure for
reading and writing new concepts originating from different linear dynamic finite element analysis. Their structure con-
fields of analysis. sists of three categories of objects. First the FEM objects
which are: Node, Element, Load, LoadTimeFunc-
tion, Material, Dof, Domain, and LinearSolver.
2 Background The second includes some tools like GaussPoint, and
Polynomial. The third category refers to the collection
The history of object-oriented design for finite element pro- classes like: Array, Matrix, String, etc. They imple-
grams turns back to the early 1990’s or even earlier. In 1990, mented first a prototype of this structure in Smalltalk and
Forde et al. [33] published one of the first detailed descrip- after that an efficient one in C++. The latter version pro-
tions of applying object-oriented design to finite element vides a comparable performance versus to a Fortran code.
programs. They used the essential components of FEM to In their structure Element calculates the stiffness ma-
trix K e , the mass matrix M e , and the load vector f e in
design the main objects. Their structure consists of Node,
global coordinates for each element. It also assembles its
Element, DispBC, ForcedBC, Material, and Dof as
components in the global system of equations and updates
finite element components and some additional objects like
itself after its solution. Node holds its position and manages
Gauss, and ShapeFunction for assisting in numerical
dofs. It also computes and assembles the load vector and fi-
analysis. They also introduced the element group and the list
nally updates the time dependent data after the solution. Dof
of nodes and elements for managing the mesh and construct-
holds the unknown information and also the dofs values. It
ing system. Their approach has been reused by several au-
stores also its position in the global system and provides
thors in organizing their object-oriented finite element pro-
information about boundary conditions. TimeStep imple-
gram structures. This approach focused on structural analy-
ments the time discretization. Domain is a general manager
sis only and the objects’ interfaces reflect this fact.
for components like nodes and elements and also manages
In those years other authors started to write about the the solution process. It also provides the input-output fea-
object-oriented paradigm and its applications in finite ele- tures for reading the data and writing the results. Finally
ment programming. Filho and Devloo [32] introduced ob- LinearSystem holds the system of equation components:
ject oriented design in FEM codes and applied it to element left hand side, right hand side and solution. It also performs
design. Mackie [53] gave another introduction to the object- the equation numbering and implements the solver for solv-
oriented design of finite element programs by designing a ing the global system of equations.
brief hierarchial element. Later he published a more detailed They also developed a nonlinear extension to their struc-
structure for a finite element program providing a data structure which made them redefined some of their original
ture for entities and also introduced the use of iterators [54]. classes like Domain, Element, Material, and some
Pidaparti and Hudli [69] published a more detailed object LinearSystems [57].
oriented structure with objects for different algorithms in dy- Lu et al. [49, 50] presented a different structure in their
namic analysis of structures. Raphael and Krishnamoorthy finite element code FE++. Their structure consists of small
[71] also used object-oriented programming and provided number of finite element components like Node, Element,
a sophisticated hierarchy of elements for structural applica- Material, and Assemble designed over a sophisticated
tions. They also designed some numerical expressions for numerical library. In their design the Assemble is the cen-
handling the common numerical operations in FEM. The tral object and not only implements the normal assembling
common point of all these authors was their awareness about procedure but also is in charge of coordinate transforma-
the advantages of object oriented programming with respect tion which in other approaches was one of the element’s
to traditional Fortran approaches and their intention to use responsibilities. It also assigns the equation numbers. The
these advantages in their finite element codes. Element is their extension point to new formulations.
Miller [58–60] published an object-oriented structure for Their effort in implementing the numerical part lead to an
a nonlinear dynamic finite element program. He introduced object-oriented linear algebra library equivalent to LAPACK
a coordinate free approach to his design by defining the [8]. This library provides a high level interface using object-
geometry class which handles all transformations from local oriented language features.
to global coordinates. The principal objects in his design are Archer et al. [10, 11] presented another object-oriented
Dof, Joint, and Element. TimeDependentLoad and structure for a finite element program dedicated to linear and
nonlinear analysis structures under static and dynamic loads. based on the FEM and can be used for developing finite el-
They reviewed features provided by other designs on that ement programs for different fields like heat transfer, fluid
time and combined them in a new structure adding also some flow, solid mechanics and electromagnetics.
new concepts. Node, Element, Side, Material, Shape and Mesh
Their design consists of two level of abstractions. In are the main components of its structure and different prob-
the top level, Analysis encapsulates the algorithms and lem solver classes implement the algorithms. This library
Model represents the finite element components. Map re- also provides different classes to form a FEEqua class
lates the dofs in the model, to unknowns in the analysis which implements formulations for different fields of analy-
and removes the dependency between these objects. It also sis. It uses a static Material class in which each parameter
transforms the stiffness matrix from the element’s local co- is stored as a member variable. Element just provides the
ordinate to the global one and calculates the responses. Ad- geometrical information and the finite element implemen-
tation is encapsulated via FEEqua classes. Element pro-
ditional to these three objects, different handlers are used
vides several features which makes it useful for even com-
to handle model dependent parts of algorithm. Reorder-
plex formulations but keeping all these members data makes
Handler optimizes the order of the unknowns. Matrix-
it too heavy for industrial implementations.
Handler provides different matrices and construct them
Bangerth et al. [12, 14, 15] created a library for imple-
over a given model. Finally ConstraintHandler pro-
menting adaptive meshing finite element solution of partial
vides the initial mapping between the unknowns of analysis differential equations called Differential Equations Analysis
and the dofs in the model. Library (DEAL) II [13]. They were concerned with flexibil-
In another level there are different finite element com- ity, efficiency and type-safety of the library and also wanted
ponents representing the model. Node encapsulates a usual to implement a high level of abstraction. All these require-
finite element node, its position and its dofs. ScalarDof ments made them to use advanced features of C++ lan-
and VectorDof are derived from the Dof class and guage to achieve all their objectives together.
represent the different dof’s types. Element uses the Their methodology is to solve a partial differential
ConstitutiveModel and ElementLoad to calculate equation over a domain. Triangulation, Finite-
the stiffness matrix K e , the mass matrix M e and the damp- Element, DoFHandler, Quadrature, Mapping, and
ing matrix C e in the local coordinate system. LoadCase FEValues are the main classes in this structure.
includes loads, prescribed displacements and initial element Triangulation, despite its name, is a mesh generator
state objects and calculates the load vector in the local coor- which can create line segments, quadrilaterals and hexahe-
dinate system. dra depending on given dimensions as its template parame-
Cardona et al. [17, 42, 43] developed the Object Ori- ter. It also provides a regular refinement of cells and keeps
ented Finite Elements method Led by Interactive Execu- the hierarchical history of the mesh. FiniteElement en-
tor (OOFELIE) [66]. They designed a high level language capsulates the shape function space. It computes the shape
and also implemented an interpreter to execute inputs given function values for FEValues. Quadrature provides
in that language. This approach enabled them to develop a different orders of quadratures over cells. Mapping is in
very flexible tool to deal with different finite element prob- charge of the coordinate transformation. DoFHandler
lems. In their structure a Domain class holds data sets like: manages the layout of dofs and also their numbering in
a triangulation. FEValues encapsulates the formulation
Nodeset, Elemset, Fixaset, Loadset, Materset,
to be used over the domain. It uses FiniteElement,
and Dofset. Element provides methods to calculate the
Quadrature and Mapping to perform the calculations
stiffness matrix K e , the mass matrix M e , etc. Fixaset and
and provides the local components to be assembled into the
Loadset which hold Fixations and Loads handle the
global solver.
boundary conditions and the loads.
Extensive use of templates and other advanced features of
They used this flexible tool also for solving coupled prob- C++ language increases the flexibility of this library with-
lems where their high level language interpreting mech- out sacrificing its performance. They created abstract classes
anism provides an extra flexibility in handling different in order to handle uniformly geometries with different di-
algorithms for coupled problems. They also added mensions. In this way, they let users create their formulation
Partition and Connection classes to their structure in in a dimension independent way. Their approach also con-
order to increase the functionality of their code in handling sists of implementing the formulation and algorithms and
and organizing data for coupled problems. Partition is sometimes the model itself in C++. In this way the library
defined to handle a part of domain and Connection pro- configures itself better to the problem and gains better per-
vides the graph of dofs and also sorts them out. formance but reduces the flexibility of the program by re-
Touzani [83] developed the Object Finite Element Li- quiring it to be used as a closed package. In their struc-
brary (OFELI) [82]. This library has an intuitive structure ture there is no trace of usual finite element components like
node, element, condition, etc. This makes it less familiar for their code. However the structure results from this design
developers with usual finite element background. can be unfamiliar to usual finite element programmers. For
Patzák et al. [68] published an structure used in the instance, in the latter design there are no objects to repre-
Object Oriented Finite Element Modeling (OOFEM) [67] sent nodes and elements, which are the usual components
program. In this structure Domain contains the complete for finite element programmers.
problem description which can be divided into several In this work the standard finite element objects like
Engineering Models which prepare the system of nodes, elements, conditions, etc. are reused from previous
equations for solving. Numerical Method encapsulates designs but modified and adapted to the multi-disciplinary
the solution algorithm. Node, Element, DOF, Boundary analysis perspective. There are also some new components
condition, Initial condition, and Material like model part, process, kernel and application which are
are other main object of this structure. This program is ori- added to account for new concepts mainly arising in multi-
ented to structural analysis. disciplinary problems. A new variable base interface is de-
signed providing a uniform interface between fields and in-
2.1 Discussion creasing the reusability of the code. The idea of using an in-
terpreter is applied by using an existing interpreter. A large
A large effort has been done to organize finite element codes effort has also been invested to design and implement a fast
trying to increase their flexibility and reducing the mainte- and very flexible data structure enabling to store any type
nance cost. Two ways of designing finite element program of data coming from different fields and guarantee the uni-
can be traced in literature. One consists of using the finite form transformation of data. An extendible IO is also created
element methodology for the design which leads to objects to complete the tools for dealing with the usual bottlenecks
like element, node, mesh, etc. Another approach is to deal when working with multi-disciplinary problems.
with partial differential equations which results in object In the following sections we start with a brief descrip-
functions working with matrices and vectors over domains. tion of FEM in Sect. 3 and continues in Sect. 4 with a
The work of Zimmermann et al. [24, 25, 90] is one of short presentation of common techniques for the solution of
the classical approaches in designing the code structure on multi-disciplinary problems. Section 5 gives an overview of
the basis of the finite element methodology. However there the Kratos environment and its general structure. The new
is no geometry in their design and new components like Variable Base Interface is described in Sect. 6. Section 7
processes, command interpreter etc. are not addressed. is dedicated to the data structures. The next two sections
The effort of Miller et al. to encapsulate the coordinate describe the parts related to finite element method and the
transformation in geometry is useful for relaxing the depen- input output. Finally some validation examples of the pos-
dency of elemental formulation to an specific geometry. sibility of Kratos for solving multidisciplinary are presented
Cardona et al. [17, 42, 43] added an interpreter to manage in Sect. 11.
the global flow of the code in a very flexible way. The inter-
preter was used for introducing new solving algorithms to
the program without changing it internally. This code is also 3 Finite Element Method
extended to solve coupled problems using the interpreter for
introducing interaction algorithms which gives a great flexi- 3.1 Basic Concepts of FEM Discretization
bility to it. The drawback of their approach is the implemen-
tation of a new interpreter with a newly defined language The finite element method typically solves problems gov-
beside binding to an existing one. This increases the main- erned by differential equations with the appropriate bound-
tenance cost of the interpreter itself and makes it difficult to ary conditions. The more general setting can be expressed
using other libraries which may have interfaces to chosen as:
script languages.
Touzani [83] designed an structure for multi-disciplinary – Solve the set of different equations
finite element programs. His design is clear and easy to
understand but uses field specific interfaces for its compo- A(u) = 0 in (1)
nents which are not uniform for all fields. This reduces the
subjected to the boundary conditions
reusability of the algorithm from one field to the other.
The approach of Lu et al. [49, 50] is in line with design- B(u) = 0 in (2)
ing a partial differential solver with emphasizes on numer-
ical components. Archer et al. [10, 11] extended this ap- where A and B are matrices of differential operators defined
proach to make it more flexible and extendible. More re- over the analysis domain and its boundary and u(x, t) is
cently Bangerth et al. used the same approach for designing the vector of problem unknowns which may depend on the
space dimension and the time. Indeed, for multidisciplinary we will focus in describing the details of the implementa-
problems A and B define the equations in the different in- tion of the FEM equations into an object-oriented environ-
teracting domains and their boundaries. Details of the form ment with the aim of solving problems of multidisciplinary
of the operators A and B for each particular problem can be nature, where the differential operators A and B are defined
found in standard FEM books [89]. over adjacent or overlapping domain, therefore leading to
The FEM solution is found by approximating the un- a coupled solution strategy. Typical examples of these situa-
known polynomial expansions defined within each element tions are thermal-mechanical problems, fluid-structure inter-
discretizing the analysis domain , i.e. action problems, electro-magnetic problems, aeroacoustic,
etc.

N
u uh = N i ui (3) 3.2 Solution of FEM Equations
i=1
3.2.1 Calculating Components
where N is the number of nodes in the mesh, Ni is the shape
functions matrix and ui are the approximate values of u at This step consist of calculating the elemental integrals usu-
each node. Typically, (3) is written on an element by element ally using the Gaussian Quadrature method. The integrand
form. function contains the shape functions and their derivatives,
The matrix system of equation is obtained by substituting which should be computed for each element. A common
(3) into (1) and (2) and using the Galerkin weighted residual technique is to calculate these functions in local coordinates
form which can be written as of the element and transform the result to global coordinates.

3.2.2 Creating the Global System
Ni r d + Ni r d = 0, i = 1, N (4)

Once the elemental matrices and vectors Ke and f e have
where been computed, they are assembled in the global system of
equations. This requires finding the position of each elemen-
r = A(uh ), r = B(uh ) (5) tal component in the global equations system and adding its
value to its position.
are the so called “residuals” of the governing equations over This procedure first assigns a sequential numbering to all
the domain and the boundary, respectively. Indeed (4) can dofs. Sometimes is useful to separate the prescribed dofs,
be adequately transformed by integration by parts of many those with Dirichlet conditions, from the others. This can be
terms over the analysis domain, to give the so called weak done easily at the time of assigning indices to dofs. After
integrals form which is more convenient for some prob- that, the procedure goes element by element and adds their
lems [89]. In any case, the element structure of the FEM local matrices and vectors to the global equations system
allows computing and assembling the integrals of (4) on an using the assembly operator , i.e.:
element by element manner. The resulting system of dis-
Kij Keij = KIei Iej + Keij (8)
cretized equation can be written (for the static case) as
Ie

Ka = f (6) fi fie = fIei + fie (9)
Ie
where
where Ie is the vector containing the global position, which
is the index of the corresponding dof, of each row or col-
K = AK(e) , f = Af(e) (7)
umn.
Another task to be done when building the global sys-
where A denotes the assembly operation which allows to
tem of equations is the application of essential boundary
obtaining the global stiffness matrix K and the equivalent conditions by eliminating prescribed dofs or using a penalty
nodal force vector f from the element contributions. In (7) a method [74].
is the vector of unknowns which lists the values of ui at all The global system matrix obtained in the FEM typically
the nodes in the mesh. has many zeros in it. So it is convenient to use structures
The solution of the system of (6) requires prescribing the which hold a useful portion of the matrix to be solved like
value of the unknown variables ui at specific points (the so compressed sparse row (CSR) [80]. Another common struc-
called Dirichlet boundary condition). ture is the symmetric matrix structure that uses the symme-
It is not the objective of this paper to explain the basis try property of the matrix to hold approximately half of the
of the FEM which can be found in many text books. Instead elements.
3.2.3 Solving the Global System 4 Multi-disciplinary Problems
There are two categories of solvers: direct solvers and itera- In this work a multi-disciplinary problem, also called cou-
pled problem, is defined as solving a model which consists
tive solvers.
of components with different formulations and algorithms
Direct solvers solve the equation system by transform-
interacting together. It is important to mention that this dif-
ing the coefficient matrix in an upper triangular form, lower
ference may come not only from the different physical na-
triangular, a diagonal form. Solvers like Gaussian elimina-
ture of the problems, but also from their different type of
tion [70], frontal solution [16], LU decomposition [70] are
mathematical modeling or discretization.
examples of this category.
A field is a subsystem of a multi-disciplinary model rep-
Iterative solvers start with some initial values for the un- resenting a certain mathematical model. Typical examples
known and find the correct solution by calculating the resid- are a fluid field and a structure field in a fluid-structure inter-
ual and minimize it over a number of iterations. Conjugate action problem. In a coupled system a domain is the part of a
gradient (CG) [80], Biconjugate gradient (BCG) [80], Gen- modeled space governed by a field equation, i.e. a structure
eralized minimal residual method (GMRES) [80] are exam- domain and a fluid domain.
ples of this category of solvers.
It is common to use a reordering procedure for reduc- 4.1 Categories
ing the bandwidth of the system matrix or make it more
cache efficient. In practice these algorithms can be applied One may classify multi-disciplinary problems by the type
to renumber the dofs in an optimum way once they are cre- of coupling between the different subsystems. Consider a
ated and then solve the system as usual. The Cuthill McKee problem with two interacting subsystem as shown in Fig. 1.
[80] algorithm is a classical example of this type of algo- The problem is calculating the solutions u1 and u2 of sub-
rithms. systems S1 and S2 under applied forces F (t). There are two
Sometimes it is recommended to transform the system of types of dependency between the subsystems:
equations to and equivalent but better conditioned one for Weak Coupling Also called one-way coupling where one
using iterative solvers. This procedure is called precondi- subsystem depends on the other but this can be solved in-
tioning. Diagonal and Incomplete LU preconditioners [80] dependently. Figure 2 shows this type of coupling.
are examples of preconditioners. Unfortunately, finding the Strong Coupling Also referred as two-way coupling when
best combination of solver and preconditioner for a certain each system depends on the other and hence none of them
problem is a matter of experience and there is not a single can be solved separately. Figure 3 shows this type of cou-
best combination for all problems. pling.
3.2.4 Calculating Additional Results
This step consist of calculating some additional results from

the primary ones obtained by solving the global system. For
example, calculating the stresses from the displacements in
a structural problem.
These additional results can be discontinuous over the
domain. This means that, for example, the stresses at a node
are different for each of the element corrected to it. Differ- Fig. 1 A general multi-disciplinary problem with two subsystems
ent averaging methods are typically implemented to smooth
the discontinuous results. An alternative is to use recovery
methods which try to reproduce continuous gradient results
with a better approximation [89].
3.2.5 Iterating
Several algorithms in FEM contain iterations in different

ways. Some examples are Newton method, Modified Newton
method, Line search [89], etc. for solving nonlinear prob- Fig. 2 A weak coupled system where subsystem S2 depends on the
lems. solution of subsystem S1
Advancing Calculating the next time step of a subsystem

using the calculated or predicted solution of the other sub-
system.
Substitution Using the calculated value of one field in an-
other field for solving it separately.
Correction Substituting the obtained result in place of the
predicted value and solve it again for obtaining a better
result. This procedure can be repeated several times.
Fig. 3 A strong coupled system where not only subsystem S2 depends More information about staggered methods and their
on the solution of subsystem S1 but also subsystem S1 depends on S2 techniques can be found in [30, 31]. Staggered approaches
often use less resources than the monolithic approaches be-
Another classification can be done by looking not on how cause in each step solve only one part of problem. Another
the subsystem interact but where they interact with each advantage is the possibility of reusing existing single field
other. There are two categories of multi-disciplinary prob- codes for solving multi-disciplinary problems using mas-
lems within this criteria [89]: ter and slave technique. This approach also enables the use
of different discretizations for each field. Beside all these
Class I In this category the interaction occurs at the bound- advantages this approach requires a careful formulation to
ary of the domains. avoid instability and obtain an accurate solution. In general,
Class II This category include problems where domains staggered methods are less robust than monolithic one and
can overlap totally or partially. need more attention and time for modeling and solving.
4.2 Solution Methods
5 Programming Concepts
The solution of one-way coupled problems is straightfor-
ward. Considering the problem of Fig. 2 with two subsys- This section describes different software engineering solu-
tems S1 and S2 , where S2 depends on u1 (the solution of S1 ). tions and programming techniques useful for designing a fi-
This problem can be solved by solving S1 first and using its nite element program.
solution u1 for solving S2 . There are several classical problems that appear during
Monolithic and staggered methods can be used for solv- the design and can be solved easily by applying existing De-
ing two-way coupled problems. The monolithic approach sign Patterns [34]. Several patterns are used in this work
consists of modeling the interacting fields together in one in order to increase the quality of the design. Examples are
global system of equations and solve them together. Con- Strategy Pattern, Bridge pattern, Composite Pattern, Tem-
sider the problem with strong coupling in Fig. 3 where not plate Method Pattern, Prototype Pattern, Interpreter Pat-
only S2 depends on S1 , but also S1 depends on S2 . Using tern, Visitor Pattern and Curiously Recursive Template Pat-
the monolithic approach results in the following system of tern. Description of other patterns and also more detailed
equations: explanation of the patterns mentioned above can be found
in [34].
K 1 H 1 u1 f1 (t)
= (10) Performance and memory efficiency are two crucial re-
H 2 K 2 u2 f2 (t) quirement for finite element programs. It has been shown
that an optimized implementation of numerical methods in
where K1 and K2 are the field system matrices correspond-
C++ can provide the same performance as Fortran imple-
ing to the field variables and H1 and H2 are the field sys-
mentations [86] and that usually the inefficiency of C++
tem matrices corresponding to the interaction variables. The
codes comes from the developer’s misunderstanding of the
monolithic approach is robust and stable but introduces a
language [43]. For this reason we briefly review some tech-
difficulty of the formulation, larger size matrices and an in-
niques used for implementing high performance and effi-
crease in the bandwidth of the global system.
cient numerical algorithms in C++. These techniques are
Staggered approach aim to solving each field separately
used extensively in the Kratos to improve its efficiency while
and deal with the interaction by applying different tech-
providing a clear and easy-to-use interface.
niques for transferring variables from one field to another.
Expression Templates is a technique used to transfer ex-
Some common techniques used for staggered methods are
pressions to a function argument in a very efficient way [84].
described below:
For example passing a function to an integration module
Prediction Predicting the value of the dependent variables for its integration. The idea is to create a template object
in the next step. for each operator and constructing the whole expression by
combining these templates and their relative variables. This Finally it has to provide different levels for developers
technique is also used in high performance linear algebra to contribute to the Kratos system, and match their require-
libraries to evaluate vectorial expressions [85]. In this way ments and difficulties in the way they extend it. Developers
expressions consisting of operations over matrices and vec- may not want to make a plug-in extension, create an appli-
tors can be evaluated without creating any temporary object cation over it, or using IO scripts to make Kratos perform a
and in a single loop. certain algorithm. Some potential profiles for Kratos users
Templates were added to C++ for a better alternative to are:
existing macros in old C. Eventually they did not eliminate
Finite Element Developers These developers are consid-
the use of macros but performed much better than anyone
ered to be more experts in FEM, from the physical and
could expect. An example is template meta programming.
mathematical points of view, than C++ programmers.
Everything began when Erwin Unruh tricked the compiler
For them, Kratos has to provide solution to their require-
to print a list of prime numbers at compile time. This ex-
ments without involving them in advanced programming
tends the algorithm writing from standard form in C++ to a
concepts.
new form which makes the compiler run the algorithm and
Application Developers These users are less interested in fi-
results in a new specific implementation to run.
nite element programming and their programming knowl-
The Template Metaprogramming technique can be used
edge may vary from very expert to higher than basic. They
to create an specialized algorithm at the time of compil-
may use not only Kratos itself but also any other appli-
ing. This technique makes the compiler interpret a subset
cations provided by finite element developers, or other
of the C++ code in order to generate this specialized algo-
application developers. Developers of optimization pro-
rithm. Different methods are used to simulate different pro-
grams or design tools are typical users of this kind.
gramming statements, like loops or conditional statements,
Package Users Engineers and designers are other users of
at compiling time. These statements are used to tell the com-
Kratos. They use the complete Kratos package and its ap-
piler how to generate the code for an specific case.
plications to model and solve their problem without get-
This technique uses recursive templates to encourage the
ting involved in internal programming of this package. For
compiler into making a loop. When a template calls itself
these users, Kratos has to provide a flexible external inter-
recursively, the compiler has to make a loop for instantiat-
face to enable them use different features of Kratos with-
ing templates until a specialized version used as stop rule is
out changing its implementation.
reached.
Template specialization can also be used to make com- Kratos has to provide a framework such that a team of
piler simulate conditional statements or switch and cases. developers with completely different fields of expertise as
These statements can be used to generate different codes ac- mentioned before, can work on it in order to create multi-
cording to some conditions. For example an assignment op- disciplinary finite element applications.
erator for matrices may change its algorithm depending on
the row or column majority of a given matrix. 6.1 Object Oriented Design
History of object-oriented design for finite element pro-

6 General Structure of Kratos grams turns back to early 90’s, and even more. Before that,
time many large finite element programs were developed in
Kratos is designed as a framework for building multi- modular ways. Industry demands for solving more complex
disciplinary finite element programs [21]. Generality in de- problems from one side, and the problem of maintaining
sign and implementation is the first requirement. Flexibility and extending the previous programs from the other side,
and extensibility are other key points in this design, enabling has lead developers to target their design strategy towards
developers to implement very different formulations and an object-oriented one [32, 33, 53, 69, 71].
algorithms involving in the solution of multi-disciplinary The main goal of an object-oriented structure is to split
problems. the whole problem into several objects and to define their
Kratos as a library must provide a good level of reusabil- interfaces. There are many possible ways to do this for each
ity in its provided tools. The key point here is to help users kind of problem we want to program and the functional-
develop easier and faster their own finite element code us- ity of the resultant structure depends largely on it. In the
ing generic components provided by Kratos, or even other case of finite element problems there are also many ap-
applications. proaches such as constructing objects based on partial dif-
Another important requirements are good performance ferential equations solvers methods [15] or in the FEM itself
and memory efficiency. This features are necessary for en- [24, 25, 33, 90].
abling applications implemented using Kratos, to deal with In Kratos we have chosen the second approach and have
industrial multi-disciplinary problems. constructed our objects based on a finite element general
Fig. 4 Main classes defined in

Kratos. The basic components
in the rightmost column. FEM
related objects in the second
column from the right. The FEM
modeling objects in the third
column. The algorithms in
fourth column below and library
interface objects are above them
methodology. This approach was selected because our goal Element encapsulates the elemental formulation in one
was to create a finite element environment for multidiscipli- object and provides an interface for calculating the local
nary problems. Also our colleagues were, in general, more matrices and vectors necessary for assembling the global
familiar with this methodology. In addition, this approach system of equations. It holds its geometry that meanwhile
has given us the necessary generality in the objectives of is its array of Nodes. Also stores the elemental data and
Kratos mentioned above. Within this scope main objects are the interface to access it.
taken from various parts of the FEM structure. Then, some
Condition encapsulates data and operations necessary
abstract objects are defined for implementation purposes. Fi-
for calculating the local contributions of Condition to
nally their relations are defined and their responsibilities are
the global system of equations. Neumann conditions are
balanced. Figure 4 shows the main classes in Kratos.
Vector, Matrix, and Quadrature are designed by example of Conditions which can be encapsulated by
basic numerical concepts. Node, Element, Condition, derivatives of this class.
and Dof are defined directly from finite element con- Dof represents a degree of freedom (dof). It is a lightweight
cepts. Model, Mesh, and Properties are coming from object which holds its variable, like TEMPERATURE, its
practical methodology used in finite element modeling. state of freedom, and a reference to its value in the data
These classes are completed by ModelPart, and structure. This class enables the system to work with dif-
SpatialContainer, for organizing better all data nec- ferent set of dofs and also represents the Dirichlet condi-
essary for analysis. IO, LinearSolver, Process, and tion assigned to each dof.
Strategy are representing the different steps of finite el- Properties encapsulates data shared by different
ement program flow. Finally, Kernel and Application Elements or Conditions. It can store any type of data
are defined for library management and defining its inter- and provides a variable base access to them.
face.
Model stores the whole model to be analyzed. All Nodes,
These main objects are described below:
Properties, Elements, Conditions and solution
Vector represents the algebraic vector and defines usual data. It also provides an access interface to these data.
operators over vectors. ModelPart holds all data related to an arbitrary part of
Matrix encapsulate matrix and its operators. Different model. It stores all existing components and data like
matrix classes are necessary. The most typical ones are
Nodes, Properties, Elements, Conditions and
dense matrix and compressed row matrix.
solution data related to a part of model and provides inter-
Quadrature implements the quadrature methods used in
face to access them in different ways.
finite element method. For example the Gaussian integra-
tion with different number of integration points. Mesh, Node, Properties, Elements, Conditions
Geometry defines a geometry over a list of points or and represents a part of model but without additional so-
Nodes and provides basic parameters, like area or center lution parameters. It provides access interface to its data.
point, to shape functions and coordinate transformation SpatialContainer includes associated with spacial
routines. search algorithms. This algorithms are useful for finding
Node It is a point with additional facilities. Stores the nodal the nearest Node or Element to some point or other spa-
data, historical nodal data, and list of degrees of freedom. cial searches. Quadtree and Octree are example of these
It provides also an interface to access all its data. containers.
IO provides different implementation of input output pro- Basic Tools Layer Holds all basic tools used in Kratos. In
cedures which can be used to read and write with different this layer the use of advanced C++ techniques is essen-
formats and characteristics. tial in order to maximize the performance of these tools.
LinearSolver encapsulates the algorithms used for This layer is designed to be implemented by an expert
solving a linear system of equations. Different direct programmer and with less knowledge of FEM. This layer
solvers and iterative solvers can be implemented in Kratos may also provide interfaces with other libraries to benefit
as a derivatives of this class. from existing work in the field.
Strategy encapsulates the solving algorithm and general Base Finite Element Layer This layer holds the objects that
flow of a solving process. Strategy manages the building are necessary to implement a finite element formulation.
of equation system and then solve it using a linear solver It also defines the structure to be extended for new formu-
and finally is in charge of updating the results in the data lations. This layer hides the difficult implementations of
structure. nodal and data structure and other common features from
Process is the place for adding new algorithms to Kratos. the finite element developers.
Mapping algorithms, Optimization procedures and many Finite Element Layer The extension layer for finite element
other type of algorithms can be implemented as a new developers. The finite element layer is restricted to use the
process in Kratos.
basic and average features of language and uses the com-
Kernel manages the whole Kratos by initializing different
ponent base finite element layer and basic tools to opti-
parts of it and provides the necessary interface to commu-
mize the performance without entering into optimization
nicate with applications.
details.
Application provides all the information necessary for
Data Structure Layer contains all objects organizing the
adding an application to Kratos. A derived class from it
data structure. This layer has no restriction in implemen-
is necessary to give a kernel its required information, like
tation. Advanced language features are used to maximize
new Variables, Elements, Conditions, etc.
the flexibility of the data structure.
The main intention here was to hide all difficult but com- Base Algorithms Layer provides the components building
mon finite element implementations, like data structure and the extendible structure for algorithms. Generic algo-
IO programming, from developers. rithms can also be implemented to help developer in their
implementation by reusing them.
6.2 Multi-layers Design User’s Algorithms Layer This is another layer to be used
by finite element programmers but at a higher level. This
Kratos uses a multi-layer approach in its design. In this ap- layer contains all classes implementing the different al-
proach each object only interfaces with other objects in its gorithms in Kratos. Implementation in this layer requires
layer or in layers below its layer. There are some other lay- medium level of programming experience but a higher
ering approaches that limit the interface between objects of knowledge of the program structure than the finite ele-
two layers but in Kratos this limitation is not applied. ment layer.
Layering reduces the dependency inside the program. It Applications’ Interface Layer This layer holds all objects
helps in the maintenance of the code and also helps devel- that manage Kratos and its relation with other applica-
opers in understanding the code and clarifies their tasks. tions. Components in this layer are implemented using
In designing the layers of the structure different users high level programming techniques in order to provide the
mentioned before are considered. The layering is done in required flexibility.
a way that each user has to work in the less number of lay- Applications Layer A simple layer which contains the inter-
ers as possible. In this way the amount of the code to be face of certain applications with Kratos.
known by each user is minimized and the chance of conflict Scripts Layer holds a set of IO scripts which can be used
between users in different categories is reduced. This layer- to implement different algorithms from outside Kratos.
ing also lets Kratos to tune the implementation difficulties Package users can use modules in this layer or create
needed for each layer to the knowledge of users working their own extension without having knowledge of C++
in it. For example, the finite element layer uses only basic programming or the internal structure of Kratos. Via this
to average features of C++ programming, but the main de- layer they can activate and deactivate certain functionali-
veloper layer uses advanced language features in order to ties or implement a new global algorithm without entering
provide the desirable performance. into Kratos implementation details.
Following the design mentioned before, Kratos is orga-
nized in the following layers: Figure 5 shows the multi-layer nature of Kratos.
Fig. 5 Dividing the Kratos

structure into layers reduces the
dependency
6.3 Kernel and Applications minimized. The Application class provides the inter-
face for introducing an application to the kernel of Kratos.
In the first implementation of Kratos all applications were Kernel uses the information given by Application
implemented in Kratos and also were compiled together. through this interface to mange its components, configure
This approach at that time produced several conflicts be- different part of Kratos, and synchronize the application
tween applications and was requiring many unnecessary re- with other ones. The Application class is very sim-
compiling of the code for changes in other applications. All ple and consists of registering the new components like:
these problems lead to a change in the strategy and to sepa- Variables, Elements, Conditions, etc. defined in
rating each application, not only from others, but also from Application. The following code shows a typical
Kratos itself. Application class definition:
In the current structure of Kratos each application is cre-
ated and compiled separately and just uses a standard inter- // Variables definition
KRATOS_DEFINE_VARIABLE(Matrix, MY_NEW_VARIABLE)
face to communicate with the kernel of Kratos. In this way
the conflicts are reduced and the compilation time is also class KratosNewApplication
: public KratosApplication
{
public:
virtual void Register();
private:
const NewElementType mMyElement;

};
Here Application defines its new components and

now its time to implement the Register method:
// Creating variables
KRATOS_CREATE_VARIABLE(MY_NEW_VARIABLE)
void KratosR1StructuralApplication::Register()
{
// calling base class register
// to register Kratos components Fig. 6 Structure of the variable classes
KratosApplication::Register();
// registering variables in Kratos. • A variable encapsulate all information needed by differ-

KRATOS_REGISTER_VARIABLE(MY_NEW_VARIABLE)
ent objects to work in a generic way over different vari-
KRATOS_REGISTER_ELEMENT("MyElement",mMyElement); ables. Doing this helps to simplifying the module inter-
}
faces. Consider, for instance, a PrintNodalResult
module which normally needs a result name, an index to
This interface enables Kratos to add all these retrieve nodal results and a zero value if some Nodes do
Variables, Elements and Conditions in the list of not have results. All this information can be passed by one
components. Kratos also synchronizes the variables num- variable in this design.
bering between different applications. Adding new compo- • Each module must configure itself in terms of variable or
nents to Kratos, enables IO to read and write them and also variables passed to it.
configures the data structure to hold these new variables. • Type-safety is reached by statically typing variables.
• Each of variable class has the same name as its repre-
sented variable name. This is a great added value to code
7 Variable Base Interface readability.
This interface can be used in different situations. Pass-
Connecting different modules and solvers in different fields ing data from one domain to other or reusing modules in
of FE analysis has been always a challenge for program- a multi-disciplinary applications always requires a generic
mers in the multi-disciplinary problem field.There are many and extensible interface. This can be achieved by defining
successful examples using file interface or libraries like generic interfaces for modules like data structures, input-
CORBA [87] or omniORB, though using them can cause output, mapping and interpolating algorithms, etc. using the
big overheads in the code performance [47]. Also in this ap- VBI.
proach the level of reusability is respectively low. The rea-
son is that in this manner we can reuse the whole module but 7.2 Kratos Variable Base Interface Implementation
not a part of it. This is the motivation to establish a variable
base interface (see Fig. 6) which can be used at high and low In Kratos VariableData and its derivatives Variable
levels in the same manner. and VariableComponent represent interface informa-
tion.
7.1 The Variable Base Interface Definition 7.2.1 VariableData
In many connecting points between different parts of a fi- VariableData is the base class which contains two ba-
nite element program we are asking for the value of some sic informations about the variable it represents; Its name
variable or the mapping of some variables and so on. The mName, and its key number mKey. VariableData has
methodology to design this interface is sending each request trivial access methods for these two attributes while also
with the variable or variables it involves. has virtual and empty methods for raw pointer manipula-
In this variable base interface (VBI): tion. The reason of not implementing these methods here
is the fact that VariableData has not any information with the memory allocated to it. So it is very useful in
about the variable type it represents. Lack of type informa- case of reallocating a part of the memory.
tion in VariableData makes it unsuitable and less us- • Print is an auxiliary method to produce output of given
able to pass it in many parts of the interface. The idea of variable knowing its address. For example writing an het-
this class, however, is to provide a lower level of informa- erogenous container in an output stream can be done us-
tion which is common to all types of variables and their ing this method. Point assumes that the streaming opera-
components, and use it as a place holder when there is no tor is defined for the variable type.
distinction between variables and their components. Also in
All these methods are available for low level use. They
this implementation we use a virtual method base to dis-
are useful because they can be called by a VariableData
patch various operations on raw pointers. This may result
pointer and equally for all type of data arranged in memory.
in a poor performance for some cases as the function call
However, maintaining typesafety using these methods is not
overhead may be considerable.
straightforward and needs special attention.
Zero value is another attribute of Variable, stored in
7.2.2 Variable
mZero. This value is important specially when a generic al-
gorithm needs to initialize a variable without losing general-
Variable is the most important class in this structure. It
ity. For example an algorithm to calculate the norm of a vari-
has information represented by VariableData which is
able for some Elements must return a zero value if there
derived from it plus the type of the variable it represents.
is no Element at all. In case of double values there is no
Variable has its data type as a template parameter. In this
problem to call default constructor of variable type but ap-
manner, the interface can be specialized for each type of data
plying same algorithm to vector or matrix values can cause
and also type-safety can be achieved. Another important ad-
a problem because default constructor of this types will not
vantage of having variable in template form with its data
have the correct size. Returning a zero value instead of a
type as template parameter is to have a restriction form in the
default constructed value keeps generality of the algorithms
interface. If we want to restrict a method to accept just matri-
even for vectors and matrices, assuming that variables are
ces for instance, then by passing a variable<Matrix>
defined properly.
as its argument we can prevent users from passing another
A method is StaticObject. This method just returns
type by mistake. This feature is particularly important for
None which is an static variable that can be used in case of
cases when there are different types representing the same
undefined variable (like null for pointers). It is just an auxil-
variable. The constitutive matrix and its corresponding vec-
iary variable to help managing undefined, no initialized, or
tor is a good example of this situation.
exceptional cases.
In Variable by knowing the data type raw pointer ma-
nipulating methods are implemented. These methods use
7.2.3 VariableComponent
raw pointers to perform basic operations over its type:
• Clone creates a copy of the object using a copy con- As mentioned before, there are situations that we want to
structor of the class. It is useful to avoid shallow copying deal with just component of a variable but not all of them.
of complex objects and also without actually having in- VariableComponent is implemented to help in these
formation about the variable type. situations.
• Copy is very similar to Clone except that it also the des- VariableComponent is a template taking an adaptor
tination pointer also passed to it. It is a helpful method as its argument. An adaptor is the extending point of a com-
specially to create a copy of heterogeneous data arrays . ponent mechanism. For any new component a new adaptor
• Assign is very similar to Copy. It just differs in using an (see Fig. 7) needs to be implemented. The adaptor type re-
assignment operator besides the copy constructor. Copy quirements are:
creates a new object while Assign does the assignment
• GetSourceVariable method to retrieve parent vari-
for two existing objects.
able.
• AssignZero is a special case of Assign for which
• GetValue method to convert extract a component value
variable zero value used as source. This method is use-
from a source variable value.
ful for initializing arrays or resetting values in memory.
• StaticObject is used to create none component.
• Delete removes an object of variable type from mem-
ory. It calls a destructor of objects to prevent memory leak Unlike Variable, VariableComponent has not
and frees the memory allocated for this object assuming been implemented to have zero value or raw pointer ma-
that the object is allocated in heap. nipulators. A zero value can be extracted from the source
• Destruct eliminates an object maintaining the memory value so there is no need implement it. Operations over raw
it is using. However, the unlike Delete it does nothing pointers are not allowed on purpose. This interface manages
Fig. 7 Adaptor class virtual void SomeElement::CalculateLocalSystem(

MatrixType& rLeftHandSideMatrix,
VectorType& rRightHandSideVector,
ProcessInfo& rCurrentProcessInfo)
{
// Getting process information
double time = rCurrentProcessInfo[TIME];
// Calculating local matrix and

// vector ...
}
variables entirely and not just some part of them. In fact a
part of an object cannot be copied, cloned, deleted or de- Writing output files can be generalized using the VBI.
stroyed. So these methods are not implemented to protect In this way any new extension to the library can write its
objects from unsafe memory operations. results using existing output procedures. Here is an example
Having adaptor as template parameter helps the com- of using the VBI to write a generic output procedure for GiD
piler to optimize the code and eliminating overheads. In [72, 73]:
this manner adaptor’s GetValue method will be inlined in
VariableComponent’s one so there won’t be any over- void GidIO::WriteNodalResults(
Variable<double> const& rVariable,
head due to decomposition while extensibility reached. NodesContainerType& rNodes,
double SolutionTag,
std::size_t SolutionStepNumber)
7.3 Examples {
// Beginning results using variable’s name
A very first example is to access nodal values in a finite ele- GiD_BeginResult((rVariable.Name().c_str()),
"Kratos", SolutionTag, GiD_Scalar,
ment program: GiD_OnNodes, NULL, NULL, 0, NULL );
// Getting a reference // Writing procedure ...

template<class TVariableType>
typename TVariableType::Type& GiD_EndResult();
Node::GetValue(TVariableType const&) { }
// Accessing to database and
// returning value ... void GidIO::WriteNodalResults(
} Variable<Vector> const& rVariable,
NodesContainerType& rNodes,
double SolutionTag,
Overwriting the [] operators makes the syntax easier to std::size_t SolutionStepNumber)
{
use: // Writing procedure for vectors ...
}
template<class TVariableType>
typename TVariableType::Type&
Node::operator[](const TVariableType&) { In above examples the GiD interface has different rules
return GetValue(rThisVariable); for scalar and vectorial variables. Knowing the type of vari-
}
able helps to implement customized versions of Write-
NodalResults for each type of variable. This is an im-
Now it is easy to use Node in the code and access any
portant feature of this interface which can handle excep-
variable through the interface:
tional cases for certain types with a uniform syntax for users:
// Getting pressure of the center node
double pressure = center_node[PRESSURE]; // Writing temperature of all the nodes
gid_io.WriteNodalResults(TEMPERATURE,
// Setting velocity of node 1 mesh.Nodes(), time, 0);
Nodes[1][VELOCITY] = calculated_velocity; // Writing velocity of all the nodes
gid_io.WriteNodalResults(VELOCITY,
// Printing temperature of the nodes mesh.Nodes(), time, 0);
for(IteratorType i_node = mNodes.begin() ;
i_node != mNodes.end() ; i_node++)
std::cout << "Temperature of node #" Finally, writing an error estimator is another example of
<< i_node->Id() << " = " making a generic and reusable code using the VBI. Here is
<< i_node->GetValue(TEMPERATURE)
<< std::endl; an example of a simple recovery error estimator [89] imple-
mented in a generic way:
The next example shows the use of the VBI for pass-
void
ing additional parameters needed for calculating local con- EstimateError(const VariableType& ThisVariable,
tributions for each Element. Here a helper class named ModelPart& rModelPart)
{
ProcessInfo is used to pass parameters like time step,
current time, delta time and so on: // initializing ...
Fig. 8 Combining containers

for(i_element = rModelPart.ElementsBegin(); for holding doubles, vectors,
i_element != rModelPart.ElementsEnd(); matrices and complex numbers
++i_element)
i_element->GetValue(ERROR) =
CalculateError(ThisVariable,*i_element);
}
double
CalculateError(const VariableType& ThisVariable,
Element& rElement) types is to take different containers and put them together
{ as a new container. Figure 8 shows an example of this con-
typedef typename VariableType::type data_type;
tainer.
// initializing ...
for(i_node = element_nodes.begin() ;
Advantages for Combining Containers
i_node != element_nodes.end() ; ++i_node)
{ • Fast and easy implementation. Standard containers can be
error = i_node->GetValue(ThisVariable) - reused.
rElement.Calculate(ThisVariable, *i_node);
• Very rigid and errorless structure. Everything relies on
result += sqrt(error * error); C++ static type checking without dangerous type cast-
}
return result * area / element_nodes.size();
ing and raw pointer manipulation.
} • Keeping separated different types of data allows more
specialization for each case. For example in time of copy-
In this manner the error estimator is not depending on the ing the containers for built in types.
domain and can work in the same way for a thermal flow or • Less searching time as the number of data in each con-
a pressure gradient. tainer is less than the total number of data in container.
Disadvantages of Combining Containers

8 Data Structure • Extra memory overhead is needed for supporting any new
type. Supporting any new data type still increases more
The data structure is one of the main parts of a finite el- this overhead.
ement program. Many restrictions in functionality of finite • Adding new types needs modifying the container. A good
element codes comes from their data structure design. Usu- implementation can minimize this modification.
ally several classical containers like static and dynamic ar-
rays, link lists and trees are used to construct a data structure Implementation There are different ways to implement
[7, 35, 44]. In Kratos beside these containers some new this type of container. One way is implementing the contain-
containers suitable for multi-disciplinary finite element pro- ers with sub-containers as its attributes. A better approach
gramming are designed and implemented. The organization is to use multiple hierarchy to group different containers in
of the data is also prepared for storing multi-disciplinary a combined one. In this way supporting any new variables
data. only needs another parent class to be added and modification
in some other methods like copy constructor to incorporate
8.1 Designing New Containers the new base class. Figure 9 shows this approach. Finally,
the VBI provides a uniform template model for accessing
Standard C++ containers are homogeneous due to the sta- an element by variable.
tic typing of C++ language. In this section some hetero-
geneous containers capable to store different types of data 8.1.2 Data Value Container
are introduced. Also the VBI is used to make their interface
more generic, more clear and easier to use. A data value container is a heterogeneous container with a
variable base interface designed to hold the value for any
8.1.1 Combining Containers type of variable.
Usually a container needs to do some basic operations
Finite element developers usually work with integers and over its data like: creating, copying, deleting, etc. which
real numbers, vectors, matrices and sometimes complex may vary from one type to other. A heterogenous container
numbers as their data. So making a new container capable to therefore needs a mechanism to handle each different type
hold just these data types can cover a large part of finite ele- with its corresponding process. A common way to deal with
ment programming needs. A very fast an easy way to imple- this problem is to encapsulate all necessary operations into
ment a quasi heterogeneous containers holding above data a handler object and associate it to its corresponding data. In
Fig. 9 Combining different

containers using multiple
hierarchy
Fig. 10 Data value container

uses the Variable class to
process its data
our approach the variables are used as the handlers to help Implementation The first step to implement a data value
the container in its data operations. The data value container container is designing the structure of data in memory. One
uses the Variable class not only to understand the type of approach is to group each data with a reference to its variable
data but also to operate over it via its raw pointer methods. and put them in a dynamic array as shown in Fig. 11.
Figure 10 shows the relationship between a container and Having a pointer to each variable and not copying it is
the Variable class. necessary for eliminating the unnecessary overhead of du-
plicated variables.
Data Value Container Advantages Another approach is to allocate each data separately and
keep the pointer to its location in the container. Figure 12
• Extendibility to store any type of data without any imple-
shows a container with this structure in memory.
mentation cost. One can store virtually any type of data,
The first approach is typically more efficient in use of
from simple data like an integer to a complex one like a
cache but adding new data to it may invalidate all the ref-
dynamic array of pointers to neighbor elements.
erences to its elements. The second approach lets user to
• Usually extensive use of void pointers and down casting
get a reference of its data once and use it several times
make heterogeneous container open to type crashing. Us-
ing the VBI protects users from unwanted type conversion without worrying about its validness. In this work the sec-
and guarantees the type-safety of this container. ond approach is used because of its advantage in reducing
the repeated accesses to the container which can increase
significantly its overall performance in practice. Finally, a
Data Value Container Disadvantages
brute-force search over unsorted containers has been used
• Heterogeneous containers are typically slower than ho- for searching the keys as this has given the best performance
mogeneous ones, at least in some of their operations. in practice (Fig. 13).
Fig. 11 A data value container

with continuous memory
Variables List Container Advantages

• The accessing and finding processes are very efficient.
• Extendibility to store any type of data without any imple-
mentation cost.
• Using the VBI protects users from unwanted type conver-
sion and guarantees the type-safety of this container.
Variables List Container Disadvantages

• Having a shared variable list imposes an extra effort to
Fig. 12 A data value container with discontinuous memory group related containers and manage them in different
groups which makes them practically less independent.
• Erasing a variable from this container is a complex and
Now a VBI completes our design. Access methods use
difficult task.
Variable or VariableComponent as data informa-
tion as described for the VBI. Each access consist of a find
Implementation The first approach to implement this con-
process for given variable key and then convert the data to
tainer is to encapsulate everything in the container and tak-
the given variable type. It is important to mention here that
ing a simple list of variables to work. This approach looks
using the VBI not only increases the readability of the code
attractive but requires recalculation of the offset for each ac-
but also protects users from unwanted type crashing.
cess which imposes an unacceptable overhead.
8.1.3 Variables List Container Another approach is to divide the mechanism in two
parts. One part for calculating the position and another for
In finite element programs it is common to store the same handling the memory. In this design the VariablesList
set of data for all Nodes of a domain. For example in a class keeps the list of variables to be stored and also pro-
fluid domain each Node has to store velocity and pressure. vides their local position by giving the necessary offset for
The previous heterogeneous container can be used to store each one. The container is in charge of allocating memory,
these data but the searching procedure in order to access data copying itself and clearing the data in a correct way using a
makes it inefficient. So another container is designed which variables list. Figure 15 shows this structure.
stores only a specific set of data but with an efficient access An important decision here is to let the container add new
mechanism. variables to the shared list or not? When each container is
The main idea is to use an indirection mechanism to ac- enable to add a new variable to the list of stored variables,
cess the elements of the container. A shared variable list this list also changes for all other containers sharing it. This
gives the position of each variable in the containers sharing change implies that for each access to a container, it must
it. The mechanism is very simple. There is an array which check if the list is changed or not and, in the case of new
stores the local offset for each variable in the container and variables, update itself. This procedure introduces an over-
assigns the value −1 for the rest of the variables. Offsets head in all accesses to the container’s elements. Also this up-
are stored in the position of variables key using a zero base dating invalidates all references to its elements which com-
indexing. In other words, if the key of a variable is k, then plicates more its use and increases the number of accesses
its offset is stored as the k + 1’th element of this array. This to its data.
offset can be used to access the data in memory by offsetting In Kratos the inserting strategy was enabled to make this
the data pointer. For example to find temperature in this con- container compatible with previous ones. In practice the
tainer, the key of the TEMPERATURE variable in example 2 problem was not only the check and updating overhead. The
indicates that the third element of the offset array contains updating makes debugging a difficult task. References are
the offset for temperature which is 1. Then this offset is used not reliable because there is no guarantee that some other
to get the value of temperature in the data array. Figure 14 container has not changed the list. This can be even worse in
shows this procedure. case of parallel computation because this change can happen
Fig. 13 Time comparison for different searching algorithms over vector<double> with binary search. (b) Comparing performance
sorted and unsorted small containers. (a) Comparing perfor- of vector<pair<int,double> > with brute-force key finding,
mance of vector<double> with brute-force, list<double> list<pair<int, double> > with brute-force key finding and
with brute-force, set<double> binary tree search and sorted map<int,double> binary tree search
Fig. 14 Accessing to a value in

the variables list container
Fig. 15 The
VariablesList class
provides the list of variables and
their local positions for the
VariablesListData-
ValueContainer
in another thread just after a reference is taken. So finally the can be stored in different categories representing domains or
inserting feature was removed from this container to reduce other model complexities. In this section the global distrib-
problems using it. ution of data in Kratos will be discussed.
8.2 Organization of Data 8.2.1 Global Organization of the Data Structure
In a finite element program several categories of data has to Kratos is designed to support an element-based formulation
be stored. Nodal data, elemental data with their time histo- for multi-disciplinary finite element applications. Also han-
ries and process data are examples of these categories. Also dling mesh adaptivity is one of its goals. So the entity based
in a multi-disciplinary applications, Nodes and Elements data structure becomes the best choice. First because ele-
Fig. 16 ModelPartholds
Mesh with some additional data
referred as ProcessInfo
mental algorithms are usually entity based and can be opti- The next container is ModelPart which is a complete
mized better using this type of structure. The second reason set of all entities and all categories of data in the data struc-
is the good performance and flexibility this structure offers, ture. It holds Mesh with some additional data referred as
in order to add or remove Nodes and Elements. Beside ProcessInfo. Any global parameter related to this part
this entity base structure, Kratos also offers different levels of the model or data related to processes like time step, iter-
of containers to organize and group geometrical and analy- ation number, current time, etc. can be stored in Process-
sis data. These containers are helpful in grouping all the data Info. Each ModelPart can hold more than one Mesh
necessary to solve some problems and for simplifying the which can be used to keep trace of different categories of
task of applying a proper algorithm to each part of the model entities like interface, local, ghost etc. ModelPart also
in multi-disciplinary applications. Figure 16 shows the con- manages the variables to be hold in Nodes. For example, all
tainers in the Kratos data structure. the Nodes belonging to one ModelPart sharing its nodal
Nodal, elemental and conditional data containers are the variables list. ModelPart is the nearest container to the
basic units of this entity base structure. In Kratos each Node domain concept in the multi-disciplinary FEM.
and Element has its own data. In this manner an Element Finally Model is a group of ModelPart’s and repre-
can access easily the nodal information just by having sents the finite element model to be analyzed. It can be use-
a reference to its Node and without any complications. ful for some procedures that require the whole data structure
Properties is also a block of this structure, as a shared like saving and loading procedures. As processes in Kratos
data between Elements or Conditions. use ModelPart as their work domain, this container is not
Separate containers for Nodes, Properties, implemented yet but it is necessary to complete the data
Elements and Conditions are the first level of contain- structure of Kratos.
ers defined in Kratos. These containers are just for grouping Spatial containers are separated so can be used just when
one type of entity without any additional data associated to they are needed. This strategy also allows Kratos to use ex-
them. These containers can be used not only to work over ternal libraries implementing general spatial containers like
a group or entities but also to modify their data while each Approximate Nearest Neighbor (ANN) library [62].
entity has access to its own data. These containers are useful
when we want to select a set of entities and process them. 8.2.2 Nodal Data
For example giving a set of Nodes to a nodal data initializa-
tion procedure, sending a set of Elements to assembling The first implementation of Kratos had a buffer of data value
functions, or getting a set of Conditions from a contact containers to hold all the nodal variables. This nodal con-
procedure. tainer was very flexible but with considerable memory over-
Mesh is the second level of abstraction in the data struc- head for nonhistorical variables. For example for saving two
ture which hold Nodes, Elements and Conditions and time steps in history (a buffer with size 3) there were two
their Properties. In other words, Mesh is a complete redundant copies of all nonhistorical variables in memory as
pack of all type of entities without any additional data as- shown in Fig. 17. It also had fair access performance due to
sociated with them. So a set of Elements and Condi- the searching process of the container. All these made us to
tions with their Nodes and Properties can be grouped redesign the way data are stored in Nodes.
together as a Mesh and send to procedures like mesh refine- The new structure is divided into two different con-
ment, material optimization, mesh movement or any other tainers: nodal data and solution step nodal
procedure which works on entities without needing addi- data. A data value container is used for the nodal data
tional data for their processes. (no historical data) and a buffered variables list container is
Fig. 17 Using buffer for all

variables results in memory
overhead due to redundant
copies of no historical variables
Fig. 18 The current structure

allocates all buffer data in a
block of memory to reduce the
cache misses produced by
memory jumps and also to
provide a compatible data with
other libraries
used for the solution step nodal data (historical data). In this do not need to search in the data value container and also
way the memory overhead is eliminated because no redun- give error for logical errors in the code.
dant copy is produced. Also accessing to historical variables • Methods for accessing no historical data only. Another
is much faster than before due to the indirecting process of set of methods are implemented to give access only to
accessing the variables list container instead of the search- no historical data. Due to the flexibility of the data value
ing process in the data value container. This structure of- container any variable can be added at any time as a nodal
fers good performance and also is memory efficient, but is variable using these methods.
slightly less robust and somehow less flexible to use. • Hybrid accessing also can be done using another set of
Using the variables list container for historical variables, methods. These methods try to find the variable in the so-
requires the user to define its historical variables in order lution steps container and if it does not exist, then they
to construct the nodal data container. For example a fluid provide access to the nodal data container. These methods
application must define velocity and pressure as its historical are helpful for accessing to some input variables that may
variables at the program startup. The rest of variables can come from input files as nodal data, or variables which are
be added any time during the program execution, as a no calculated in another domain and stored as a solution step
historical variable, but not as a historical one. variable. For example temperature for structural problem
In this implementation the buffer was introduced inside can be a parameter coming from the input data or calcu-
the variables list data value container instead of using a lated by the thermal elements and stored in Node. This
buffer of this containers. In this way cache misses are re- method guarantees the access to the proper temperature
duced and the data array can be given to other application
stored at each Node.
without any conversion. Figure 18 shows this structure.
Dividing the nodal data in two categories also changes
8.2.3 Elemental Data
the access interface to data. Now the user has to know were
to put each variable, and more important, where to retrieve
them from afterwards. A sophisticate interface is needed in Another basic unit of Kratos data structure is the elemen-
order to provide a clear and complete control over these two tal data. Elemental data is divided into three different cate-
categories of data. In general, three type of accessing meth- gories:
ods are necessary: properties These are all parameters that can be shared be-
• Methods for accessing only historical data. These meth- tween Element. Usually material parameters are com-
ods guarantee to give the value of the variable if and only mon for a set of element, so this category of data is re-
if it is defined as a historical variable and produce error if ferred as properties. But in general it can be any common
it is not defined. These methods are very fast because they parameter for a group of Elements. Sharing these data
Fig. 19 Different elements or

conditions use Properties as
their share data container. This
avoids redundant copies of data
in memory
as properties reduces the memory used by the application For Conditions, historical data is considered to be an
and also helps updating them if necessary. internal data as is related to its formulation and usually is
data includes all variables related to an Element and used only by formulation inside and not from outside. So
without history keeping. Analysis parameters and some to minimize unnecessary overhead and also to increase the
inputs are elemental but there is no need to keep their his- performance, no general container is provided for historical
tory. These variables can be added any time during the data and each Condition has to implement one for itself
analysis. if necessary.
historical data are data stored with historical information
which may be needed to be retrieved. Historical data in
8.2.5 Properties
integration points are fall in this category. These data must
be stored with a specific size buffer.
As mentioned before Properties is a shared data con-
As mentioned above Properties are shared between tainer between Elements or Conditions. In finite ele-
elements. For this reason Element keeps a pointer to its ment problems there are several parameters which are the
Properties. This connection lets several elements to use same for a set of elements and conditions. Thermal conduc-
the same properties. tivity, elasticity of the material and viscosity of the fluid are
A DataValueContainer holds no historical data examples of these parameters. Properties holds these
in Element. Using a DataValueContainer provides
data and is shared by elements or Conditions. This elim-
flexibility and robustness which is useful in transferring el-
inates memory overhead due to redundant copies of these
emental data from one domain to another. As an example,
data for each element and Condition as shown in Fig. 19.
one may want to set a flag over elements say active or inac-
Properties also can be used to access nodal data if
tive. The DataValueContainer can be used easily for
it is necessary. It is important to mention that accessing the
this purpose. On the other hand a damage function may need
nodal data via Properties is not the same as accessing
history of some internal variable. This second result is best
achieved by implementing an application specific data base it via Node. When user asks Properties for a variable
inside Element. data in a Node, the process starts with finding the variable
in the Properties data container and if it does not exist
8.2.4 Conditional Data then get it from Node. This means that the priority of data
is with the one stored in Properties and then in Node.
Conditional data is very similar to elemental data and is
also divided into three different categories: properties, data 8.2.6 Entities Containers
and historical data. It is also keeps a pointer to its shared
Properties and uses a DataValueContainer to
Let us go one level higher in the Kratos data structure. The
hold all data without keeping its history. Any Condition
next level consists of four entities containers:
derived from this class can use this container to hold its data
without any additional implementation. This base class also • Nodes Container
provides an standard interface to these data which helps for • Properties Container
transferring some data from one Condition to another, • Elements Container
for example in the interaction between two domains. • Conditions Container
Fig. 20 Iterating time for 109 steps of iterations with different paring the performance of vector<pair<int,double> >,
containers. (a) Comparing the performance of double*, vec- list<pair<int, double> > and map<int,double>
tor<double>, list<double> and set<double>. (b) Com-
These containers are created to help users in grouping a anymore will be deallocated from memory automatically. So
set of entities and work with them. For example to put all a container of smart pointers to entities is used.
Nodes in the boundary into a Nodes container and change Arrays are very efficient in time of iterating as shown in
some of their data in each step. As mentioned earlier, each Fig. 20. So using an array to hold pointers to entities can
entity has access to its data, so having a set of entities in a increase the iteration speed. In contrary, trees are very slow
container also gives access to their data which make these in time of iterating but efficient for searching by index and
containers more useful in practice. a suitable container for using them can increase the searching performance of the
holding entities must provide the following features: code. A good solution to this conflict can be an ordered ar-
ray. It is fast in iteration like an array and also fast in search-
Sharing Entities There are some situations when an entity
ing like a tree as shown in Fig. 21. Its only draw back is that
may belong to more than one set of entities. For exam-
its less robust and its construction it can take considerable
ple a boundary Node belongs to the list of all Nodes
time depending on the order of input data. For example con-
and also to the list of boundary Nodes. So the Nodes
structing an array of Nodes with Nodes given by inverse or-
Container has to share some its data with other Nodes
der can take a very long time. However a buffer of unordered
Containers. In general, sharing entities is an important
data can significantly reduce the construction overhead. So
feature of these containers.
an ordered array can fit properly into our problem.
Fast Iterating Several procedures have to make a loop over
PointerVectorSet is a template implementation of
all the elements of a given container and use each element
an ordered array of pointers to entities. This template is used
or its data in some algorithms. So these containers must
to create different containers to hold different type of enti-
provide a fast iterating mechanism in order to reduce the
ties.
time of element by element iteration.
Search by Index Finding an entity by an index is a usual
8.2.7 Mesh
task in finite element programs. So entities containers
must provide an efficient searching mechanism to reduce
The next level in Kratos’ data structure is Mesh. It contains
the time of these tasks.
all the entities containers mentioned before. This structure
Sharing entities is the first feature to be provided by makes it a good argument for procedures that work with dif-
these containers. Holding pointers to entities and not entities ferent entities and their data. For example an optimizer pro-
themselves can solve this problem. Different lists can point cedure can take a Mesh as its argument and change geome-
to the same entity without problem. Using an smart pointer tries, nodal data or properties. Mesh is a container of con-
[26] instead of a normal pointer increases the robustness of tainers with a large interface that helps users to access each
the code. In this way entities that do not belong to any list container separately.
Fig. 21 Time comparison for different searching algorithms vector<double> with binary search. (b) Comparing the perfor-
over sorted and unsorted containers. (a) Comparing the performance of vector<pair<int,double> > with brute-force key
mance of vector<double> with brute-force, list<double> finding, list<pair<int, double> > with brute-force key find-
with brute-force, set<double> binary tree search and sorted ing and map<int,double> binary tree search
of Kratos which makes it useful as an argument of global

procedures in Kratos. The second task is managing the vari-
ables lists of its components.
ModelPart can hold any category of data and all type
of entities in Kratos. It can hold several Meshes. Usually
just one Mesh is assigned to it and used in the computations.
However this ability can effectively used for partitioning the
model part and send it for example to a parallel process.
Beside holding different Meshes, it also stores the solution
information encapsulated in the ProcessInfo object.
ProcessInfo holds not only the current value of dif-
ferent solution parameters but also stores their history. It can
be used to keep variables like time, solution step, non lin-
ear step, or any other variable defined in Kratos. Its variable
Fig. 22 Different Meshes can share their entities’ containers base interface provides a clear and flexible access to these
data. ProcessInfo uses a linked list mechanism to hold
its history as shown in Fig. 23.
First of all Mesh provides a separate interface for each ModelPart uses pointers to its Meshes. In this way it
type of entity it stores. can share them with any other model parts if necessary, so
Mesh holds a pointer to its container. In this way several that the same node or element can be part of two different
Meshes can share for example a Nodes or an Elements ModelParts. A typical use of this feature is defining two
Container. This helps in updating Meshes of different different domains over the same Meshes. Figure 24 shows
fields in multidisciplinary applications but over the same do- this sharing mechanism.
main. Figure 22 shows this ability of sharing components ModelPart manages the variables lists of its compo-
between Meshes. nents. In Sect. 8.1.3 the mechanism of the variables list
container was described. These we also mentioned that a
8.2.8 Model Part shared variables list specifies the data which can be stored
in them. ModelPart holds this variables list for all its en-
ModelPart is created with two different tasks in mind. tities. In other words, all entities belonging to a model part
The first task is encapsulating all entities and data categories sharing the same list of variables. For example all Nodes in
Fig. 23 ProcessInfo’s
linked list mechanism for
holding the history of solution
Fig. 24 ModelPart can share

its Meshes with other model
parts
Fig. 25 ModelPart manages

the variables list for its entities
ModelPart can store the same set of variables in their so- In Kratos an Element is an object which holds its data
lution steps container. It is important to mention that this and calculates elemental matrices and vectors to be assem-
variables list is assigned to the entities which belong to the bled and also can be used to calculate local results after the
model part and is not changed when that model part share analysis. For example a thermal element calculates the lo-
them with other model parts. Figure 25 shows this scheme. cal stiffness matrix and the mass matrix (if necessary) and
give it to Kratos for assembly process. Also it can be used
8.2.9 Model to calculate a thermal flow after solving the problem. This
definition provides a good isolation for Element related to
Model is the representation of the whole physical model to rest of the code which is helpful for the proper encapsulation
be analyzed with the FEM. The main purpose of defining of Element.
Model is to complete the levels of abstraction in the data The strategy [34] pattern is used to design Element
structure and a place to gather all data and also hold global structure as can be seen in Fig. 26. Using this pattern each
information. This definition makes it useful for performing Element encapsulates one algorithm separately and lets
global operations like save and loading. It holds references new algorithms to be added easily to Kratos without chang-
to model parts and provides some global information like ing other parts. Also this pattern keeps them compatible with
the total number of entities and so on. each other in order to let users interchange them, or even mix
them together in a complex model.
In Kratos Geometry holds a set of points or Nodes and
9 Finite Element Implementation provides a set of common operations to ease the implemen-
tation of Elements and Conditions. The bridge pattern
9.1 Elements is used to connect Geometry with Elements. Introducing
this pattern to our Element’s structure design results in the
Elements and Conditions are the main extension points structure shown in Fig. 27.
of Kratos. New formulations can be introduced into Kratos This pattern allows each Element to combine its for-
by implementing a new Element and its corresponding mulation with any geometry. In this way less implementa-
Conditions. This makes Element an special object in tion is needed. Also having a pointer to geometry allows an
our design. Element to share its geometry with other ones. The only
Fig. 26 Elements’ structure

using strategy pattern
Fig. 27 Element’s structure

using the bridge pattern
drawback of this structure is the time overhead comes from pattern. However this structure is not implemented yet in
pointer redirection in memory. Having a pointer to geometry Kratos.
beside deriving from it creates a small overhead in accessing The finite element methodology is used for designing
geometrical data respect to an Element derived directly. a generic interface for Element. According to the fi-
Though efficiency in Element is crucial, the complexity nite element procedure, the Strategy asks Element to
of the first approach which one’s the first and which one is provide its local matrices and vectors, its connectivity in
the second approach imposes accepting the small different in form of equation id, and after solving also calls Element
to calculate the elemental results. So Element
performance and therefore we have implemented this second
provides three sets of methods. Calculate-
approach. A better solution is to make Element a template
LocalSystem, CalculateLeftHandSide and
of its geometry. Using templates provides good performance
CalculateRightHandSide for calculating local sys-
and also enough flexibility but it was considered to be too
tem matrices and vectors. EquationIdVector and
complex to be used by finite element users. As mentioned GetDofList are designed to provide assembling informa-
earlier an Element has to be easy to program with the less tion for Strategy. Finally, Calculate and
possible advanced features of programming language. So fi- CalculateOnIntegrationPoints are devoted to
nally the bridge pattern structure was selected. calculating elemental variable which are used mainly for
There are some designs in which different Elements calculating post-analysis results.
can be composed to create a more complex Element [58]. A VBI is used to provide a clear but flexible interface
This approach can be simulated here using a Composite for these methods.To ensure the extensibility of these meth-
Fig. 28 Process structure

using strategy pattern
ods a ProcessInfo is passed to these methods. In this 9.3 Processes

way users can pass any parameter like time, time increment,
time step, non-linear iteration number, some global norms
which are calculated over the domain, etc. to these methods. Creating a finite element application consists of implement-
Using ProcessInfo guarantees the flexibility which is ing several algorithms for solving different problems. In
necessary for Element to be an extension point of Kratos. practice, each set of problems has their own solving al-
In these methods passing the resulting matrices or vectors gorithms. A possible approach to handle algorithms in a
by reference as additional arguments improves the perfor- finite element code is to provide some high level classes
mance. to handle different tasks in the code [23]. In Kratos, the
Providing an standard way to access neighbors of an ele- Process class and its derived classes are defined to imple-
ment can be very useful for some algorithms. The problem is ment different algorithms and handle different tasks. Dif-
that for the rest of algorithms keeping the list of neighbors ferent processes may be used to handle a very small task
results in large overhead in total memory used. In Kratos like setting a nodal value to some complex one, like solv-
neighbor nodes and elements are stored inside the elemental ing a fluid structure interaction problem. Grouping some
data container exactly if they were standard variables. This processes in a larger one is also helpful, specially to make a
is indeed an interesting example of the flexibility of the VBI. pack of small processes for handling a complex algorithm.
In this way the overhead of empty containers is eliminated Process can be considered as a function class.
and the existing container is reused to hold this information. Process is created and executed just like calling a func-
This solution can be used for any other feature that must be tion. The strategy pattern is used to design the family
provided optionally but without any overhead for other ele-
of processes. Figure 28 shows this pattern applied to the
ments.
Process structure.
Applying this pattern allows Process to encapsulate
9.2 Conditions an algorithm independently and also provide an standard
interface which makes them to be replaceable with each
Condition is defined to represent the conditions applied other. Encapsulating each algorithm in one Process with-
to boundaries or to the domain itself. Neumann conditions out modifying other parts of the code makes adding a new
and interfaces between domains in multi-disciplinary prob-
Process very easy and increases the extendibility of the
lems are represented by Condition. The only exception
library to new algorithms. The compatibility of processes
is the Dirichlet condition which is applied by dof due to
with each other helps to customize the program flow and is
the applying procedure described in Sect. 3.2.2. In Kratos
useful in cases when user wants to interchange some algo-
Condition is designed very similar to Element. They
rithms.
interact with Strategy in the same way as Elements.
The reason of using a different type and not Element itself The process interface is relatively simple. Execute is
is to clarify the different purpose of these two objects. In a used to execute the Process algorithms. While the pa-
usual finite element model, there are much more Elements rameters of this method can be very different from one
than Conditions. For this reason some features that are Process to other there is no way to create enough over-
considered to be too expensive in performance or memory ridden versions of it. For this reason this method takes no
consuming for Elements can be used for Conditions. argument and all Process parameters must be passed at
Making Element and Condition two independent types construction time. The reason is that each constructor can
allows additional features to be added to Condition with- take different set of arguments without any dependency to
out affecting Element. other processes or the base Process class.
9.4 Solving Strategies
After designing Process and its derived classes, we will

focus in an important family of processes which manage the
solution task in the program.
The SolvingStrategy is the object demanded to im-
plement the “order of the calls” to the different solution
phases. All the system matrices and vectors will be stored
in the strategy, which allows to deal with multiple LHS
and RHS. Trivial examples of these strategies are the linear
Fig. 29 Template method pattern applied to the solving strategy
solver strategy and the Newton-Raphson iterative strategy.
SolvingStrategy is derived from Process and use
the same structure. Deriving SolvingStrategy from this structure. Different steps for solving template meth-
Process lets users to combine them with some other ods are deferred to two other objects which are not derived
processes using composition in order to create a more com- from Strategy: BuilderAndSolver and Scheme.
plex Process. Figure 30 shows this structure.
Like for Process users can combine different strate- The main idea of using these two additional set of objects
gies in one. For example a fractional step strategy can is to increase the reusability of the code and prevent users
be implemented by combining different strategies used from implementing a new Strategy from scratch. In prac-
for each step in one composite strategy. The interface of tice this structure can support usual cases in finite element
SolvingStrategy reflects the general steps in usual methodology but still advanced developers have to config-
finite element algorithms like prediction, solving, conver- ure their own Strategy without using BuilderAnd-
gence control and calculating results. This design yields in Solver or Scheme. For this reason in the current Kratos
the following interface: structure both approaches can be used to implement a solu-
tion algorithm.
Predict: A method to predict the solution. If it is not
called, a trivial predictor is used and the values of the so-
9.4.1 BuilderAndSolver
lution step of interest are assumed equal to the old values.
Solve implements the solving procedure. This means
The BuilderAndSolver is the object demanded to per-
building the equation system by assembling local com-
form all of the building operations and the inversion of the
ponents, solving them using a given linear solver and up-
resulting linear system of equations. The choice of grouping
dating the results.
together the solution and the building step is not necessarily
IsConverged is a post-solution convergence check. It
univocal. This choice was made in order to allow a future
can be used for example in coupled problems to verify
parallelization of the code, which should involve both the
if the solution has converged or not.
linear system solution and the Building Phase.
CalculateOutputData calculates non trivial results
Due to its features BuilderAndSolver covers the
like stresses in structural analysis.
most computational intensive phases of the overall solution
Strategies sometimes are very different from each other process. This will clearly require low level tuning in order
but usually the global algorithm is the same and only to ensure high performance. A typical user is not required to
some local steps are different. The template method pat- understand the implementation details for this class. Never-
tern helps to implement these cases in a more reusable theless the comprehension of the role of this object is neces-
form. As mentioned before, this pattern defines the skele- sary.
ton of an algorithm separately and defers some steps to In order to give the possibility of assigning any lin-
subclasses. In this way the template method pattern lets ear solver to any BuilderAndSolver a bridge pattern
subclasses redefine certain steps of an algorithm without is used to connect these two sets of classes. In this way
changing the algorithm’s structure. Applying this pattern to BuilderAndSolver can use any linear solver available.
SolvingStrategy results in the structure shown in The interface of BuilderAndSolver provides a com-
Fig. 29. plete set of methods to build the global equation system
This structure is suitable when the algorithm is not or its components separately. It also provides methods for
changing at all. However, in our case the algorithm varies building the system and solving it or rebuilding just the
from one category of strategies to another. For this reason left hand side or the right hand side and solve the up-
in order to reduce the dependency of the algorithm and its dated equation system. BuildLHS, BuildRHS, Build,
steps, a modified form of the bridge pattern is applied to ApplyDirichletConditions, SystemSolve,
Fig. 30 Deferring different

parts of the algorithm to
BuilderAndSolver and
Scheme
BuildAndSolve and CalculateReactions are pro- order to automatize this process can be found in literature
vided for this purpose. There are also several other meth- [27–29, 48, 91].
ods for initializing the internal system matrices and vectors Nowadays several computer algebra systems like Matlab
and also to remove them from memory if it is necessary. [56], Mathematica [88], and Maple [55] can do this type of
Strategy can use this interface to implement its algo- symbolic derivations. In Kratos the first part of changing the
rithm using any of the procedures defined above. variational equation to weak form is dedicated to previous
tools and only a set of tools is designed and implemented
9.4.2 Scheme to help users converting their weak form to matrix form as
elemental contributions.
Scheme is designed to be the configurable part of Elemental expressions are designed and implemented
Strategy. It encapsulates all operations over the local to help users in writing their weak form expressions in
system components before assembling and updating of re- Element. The main idea is to create a set of classes and
sults after solution. This definition is compatible with time overloaded operator to understand a weak form formulation
integration schemes, so Scheme can be used for example to and calculate the local matrices and vectors according to it.
encapsulate the Newmark scheme. The definition of scheme For example in a simple heat conduction problem with
is quote general and can be used to encapsulate other similar isotropic coordinates, the elemental stiffness matrix S e can
operation over a solution component. be calculated as follows:
According to the template method pattern the impor-
tant steps of the solving procedure in standard finite ele- S ij = k (∇Ni )T I∇Nj d
e

ment strategies is used to design the interface of scheme.
Usually a finite element solving strategy consists of several or:
steps like: initializing, initializing and finalizing solution
S e ij = k(∇i Nl , ∇j Nl )
steps, initializing and finalizing non linear iterations, pre-
diction, update and calculating output data. Initialize, This equation can be implemented in Element by the
InitializeSolutionStep, FinalizeSolution- following code:
Step, InitializeNonLinIter-ation, Finalize-
NonLinIteration and Update represent these main for(int i=0 ; i < nodes_number ; i++)
for(int j=0 ; j < nodes_number ; j++)
steps. for(int l=0 ; l < gauss_points_number ; l++)
{
Matrix const& gn=shape_functions_gradients[l];
9.5 Elemental Expressions
for(int d=0 ; d < dimension ; d++)
The finite element methodology usually consists of first rLeftHandSideMatrix(i,j) += k*gn(i,d)
*gn(j,d)*wdj;
converting the governing differential equation to its weak }
form. This is discretized over an appropriate approximation
space, and finally global system of matrix equation is built Using elemental expressions the same formulation can be
from the elemental contributions. Different approaches in written in a simpler form as:
KRATOS_ELEMENTAL_GRAD_N(i,l) grad_Nil(data); with new variables and data types. Also providing some ad-
KRATOS_ELEMENTAL_GRAD_N(j,l) grad_Njl(data);
ditional features like multi format and media support, seri-
rLeftHandSideMatrix = k*(grad_Nil, grad_Njl)*wdj; alization [1] and script language support are very useful.
It can be seen that the later form is conforming with the 10.1 IO Structure Design
symbolic notation of equations which makes it much easier
to implement. The overloading operators provided in C++ The Strategy pattern is used to encapsulate each format sep-
is the start point for implementing the code. Simple over- arately and make it extensible to any new format easily. The
loading results in poor performance due to the redundant same structure can be used for supporting different media
temporary objects that creates. Expression template tech- separately. Then the Bridge pattern can be used to
nique can be used to convert above expression to previous connect them to the format structure. However a simpler ap-
hand written form automatically. Template metaprogram- proach is to treat the media like formats and use the same
ming also is used to impose the tensorial notation. All these structure for both and enrich it via templates or several lev-
techniques are used to evaluate the symbolic notation and els of hierarchy as shown in Fig. 31.
generate an specialized code for each case. There are different concepts (like temperature, displace-
In the current version of Kratos, element expressions are ment, viscosity, etc.) and data types in a FEM data. Support-
still in experimental phase. However some benchmarks have ing different concepts and data type is very important for a
shown that their efficiency is comparable with hand coded multi-disciplinary code. Here the VBI comes handy and it is
Elements as supposed to be. used to generalize the IO.
The first step is providing IO extendibility to new con-
9.6 Formulations cepts. This can be done by introducing a lookup table which
relates the concept names and their internal handlers. A sim-
Kratos has been designed to support element approaches in ple list of Variables is enough for IO to take as its
finite element methods. For some problems an element ap- lookup table. Each Variable knows its name and also
proach is less suitable than other approaches like nodal for- its reference number. In time of reading IO reads a tag and
mulations. Formulation is defined as a place for imple- searches in the list for the Variable whose name coin-
menting all these approaches. Formulation is not imple- cides with the tag. Then use the variable to store the tagged
mented yet, but will be one of the future features of Kratos. value in the data structure. For example, when IO reads
a "NODES[29](TEMPERATURE,0)=418.651" state-
ment from input, it takes the "TEMPERATURE" tag and
10 Input-Output searches in the list to find the TEMPERATURE variable.
Having this variable is enough to use the variable base in-
In general most finite element applications have to commu- terface of the data structure to store the value in it. For writ-
nicate with pre and post processors, except in some special ing results there is no need to search in the table. IO can use
cases for which the application generates its own input. This the variable to get its value in the database and use its name
makes the input-output (IO) operation an essential part of as the tag. Here is an example of WriteNodalResults
the application. For a multi-disciplinary code IO must deal method.
Fig. 31 Extended Multi format

and Medium IO structure
Fig. 32 Using
KratosComponents in IO
template<class TDataType> our structure. KratosComponents class encapsulates a

void WriteNodalResults(
Variable<TDataType> const& rVariable,
lookup table for a family of classes in a generic way. Proto-
NodesContainerType& rNodes, types must be added to this table by unique names to be
std::size_t SolutionStepNumber) accessible by IO. These names can be created automati-
{
NodesContainerType::iterator i; cally using C++ RTTI or given manually for each com-
for(i=rNodes.begin() ; i!=rNodes.end() ; ++i) ponent. In this design the manual approach is chosen, so
Output << rVariable.Name() << "="
<< i->GetSolutionStepValue(rVariable, shorter and more clear names can be given to each compo-
SolutionStepNumber)) nent and also there is a flexibility to give different names
<< std::endl;
}
to different states of an object and create them via different
prototypes. For example having TriangularThermal-
Element and QuadrilateralThermalElement both
Each new Element or Condition also is a new type as different instances of 2DThermalElement, initializing
which implies that IO does not know how to create it. with a Triangle or a Quadrilateral.
Here we need a table for each Element or Condition This structure allows us to create any registered object
and their relative factory method. Prototype pattern helps to just by knowing its representative name. But sometimes it
manage this situation in a generic way. Here we reuse each is useful to know the family which an object belongs to.
object as its prototype by adding a Clone method to it. For example at the time of reading Elements there is no
IO uses a lookup table to find the object prototype for need to search in Variables and Conditions and to put
any component name. This table consists of representative all of them together can slow down the parsing process un-
names and their corresponding prototype. Encapsulating this necessarily. Dividing the lookup table into three family of
table introduces the new KratosComponents class to classes: Variables, Elements and Conditions helps
to distinguish them in the time of search. Doing this also Table 1 Some typical tokens with examples of matching sequences
eliminates unnecessary type casting and makes the imple- Token’s Type Examples
mentation easier and clearer. Figure 32 shows the resulting
structure. INTEGER 1 34 610
Finally an interpreter is necessary to provide the script REAL 4.57 2e-4
language input feature for this module. This feature provides IF if
a high level of extensibility in algorithms which is very use- FOR for
ful in order to deal with different algorithms as is typical in LPARENTHESES (
multi-disciplinary applications. RPARENTHESES )
10.1.1 IO Interface Design

tokens in different categories depending on the grammar
The input interface is quite straightforward and consists working with. Table 1 shows some examples of tokens.
of methods to read Nodes, Properties, Elements, If more than one sequence of input characters matches to
a token then this token must provide a value field to store the
Conditions, initial values, Meshs and ModelParts.
input data represented by it.
The two latter ones are useful for reading multi-disciplinary
The second part is the parser. A parser does the syntax
data for various domains.
analysis. It takes the tokens from the lexical analyzer and
The output interface consists of methods for writing
tries to find their relation and meaning due to its grammar.
Nodes, Properties, Elements, Conditions, Meshs
A parser produces a parse tree by putting together recog-
and ModelParts and also results for postprocessing. The
nized statements and their sub-operations. This tree can be
VBI is used to define the result methods interface in a
used to execute the given source. For example passing the
generic way.
above sequence of tokens to a C parser would result in a
parse tree as presented in Fig. 34.
10.2 Writing an Interpreter There are several reasons to separate the lexical analyzer
from the parser. The first one is simplifying the design and
In modern applications an interpreter is used to read the in- reducing the parser complexity. Creating a parser over sepa-
put file and understand the input grammar [43, 66]. An inter- rated tokens without any comments or whitespaces is easier
preter usually is divided into two parts as shown in Fig. 33. than a parser over input characters. The second reason is
The first part is the lexical analyzer. This part reads the improving the performance of the interpreter. Large amount
input characters, for example a source file or given com- of interpreter time spent in the lexical analysis, separating
mand line statement, and converts it to a sequence of to- it and using techniques like buffering can decrease signifi-
kens, like digits, names, keywords, etc., usable for parser. cantly the performance. Another reason is related to porta-
Since white spaces (like blank, tab and newline characters) bility and reuse ability of the interpreter. Any problem due
and comments are not used in parsing the code, there is a to the different character maps in different devices can be
secondary task for a lexical analyzer to eliminate all white encapsulated in the lexical analyzer without changing the
spaces and also the comments during the analysis. The lexi- parser.
cal analyzer may also provide additional information for the In some cases, the lexical analyzer is divided into two
parser to produce more descriptive error messages. phases. A scanner which does simple tasks like removing
A token is a sequence of characters having a logical comments and whitespaces, and an analyzer which does the
meaning or making a unit in our grammar. One can divide real complex job.
Fig. 33 Global structure of an

interpreter
Fig. 34 Parse tree for an if

statement
There are various ways to implement a lexical analyzer From the long list of languages first some of more pop-
and a parser in the literature [5, 6, 9]. Also there are some ular ones were selected: Lisp, Perl, Ruby, Tcl and Python.
tools to generate them. Some classical ones are Lex and Python was finally selected due to some details and also our
Yacc, and their derivatives like Fast lexical analyzer genera- background. Tcl was a good choice as it is already used at
tor (Flex) and Bison and their C++ variations Flex++ and CIMNE for example in GiD [72, 73] and a large amount of
Bison++. experience was available. Lack of object-oriented features
The first interpreter for Kratos was implemented using however prevented this choice. Perl also was considered for
Flex++ and Bison++. They are great tools to generate an its maturity and performance, but again it is less object-
interpreter but they have been put aside from this work for oriented than Python and does not support multi-threading.
mainly two reasons. The first was changes in the strategy Ruby at that time was completely new to us and also was
of code development creating a sophisticated interpreter to considered to be somehow young. An existing well designed
using an existing one. For reading data still a simple parser interface to Python and some practical use of Python in finite
was necessary, but these tools were too heavy to be used for element applications [3, 4] were another reasons for choos-
this case. The other reason was portability and maintainabil- ing Python.
ity issues, specially in Windows, due to the incompatibili- Binding Kratos to Python makes it extremely flexible and
ties between the Linux and Windows compilations of these extendible. New algorithms can be implemented using ex-
tools. The current interpreter is implemented using Spirit. isting Kratos tools and methods without even recompiling
Spirit is an object-oriented parser generator framework the code. Interaction between domains and planning differ-
implemented in C++ using template meta-programming ent staggered strategies to solve a coupled problem also can
techniques which enable us to write the context free gram- be performed easily at this level without changing Kratos
mar directly in C++ code and compile it with a C++ code or its applications. Also Python it can be used as a small
to generate the parser. In this way the translation step from lab for testing new algorithms and formulations before pro-
context free grammar to a parser implemented in C++ by gramming it into the Kratos. The list of added features is
an external tool is omitted. This interpreter can be used to unlimited and many complex tasks can be done easily using
read a data file containing nodes, elements, properties, con- this interface.
ditions, and initial values and automatically reads any new
variable in the variables list. 10.3.1 Binding to Python
10.3 Using Python as Interpreter
Boost Python library is used for binding Kratos to Python.
Implementing an interpreter is a hard work. From the man- This library provides an easy but powerful way to connect a
agement point of view, it introduces a significant overhead C++ code to Python.
to project cost and time. Maintaining it is even harder and re-
sults in more overhead in the code cost. Also implementing
an interpreter requires knowledge of different concepts like 11 Validation Examples
grammar notations, some tools and libraries usage and com-
piler implementation techniques. Finite element program- In this chapter some applications developed using Kratos are
mers usually are not familiar with most of these concepts presented to test the desired flexibility and extensibility of
and in many cases even do not like to deal with them. So in the framework.
developing a finite element program it is not easy to share
the implementation and maintenance of an interpreter with 11.1 Incompressible Fluid Solver
others due to this lack of experience. In practice, this can
lead to longer implementation times and extra cost. The Kratos features an incompressible CFD solver, im-
During the development of Kratos all these facts affected plemented in an “incompressible fluid application”. Both
the implementation of an interpreter and made its develop- monolithic and fractional step solvers (see [22]) are imple-
ment more and more difficult to the point that it became one mented in the same application. Most of the examples de-
of the bottlenecks of the project. Consequently, the strategy scribed in the following section were run using a Fractional-
changed by stop writing an interpreter and looking for an Step type approach, in order to achieve maximal efficiency.
existing one.
For selecting a script language, the following require- 11.1.1 Implementation in Kratos
ments are used as selection criteria: interface to C++ or
at least to C. Portability. To be object-oriented. Language The main CFD solvers of the Kratos are based on an Ar-
syntaxes and its readability. Flexibility and extendibility and bitrary Lagrangian Eulerian (ALE) formulation. The solver
popularity used in the examples is based on a fractional step method
[18] using equal order pressure-velocity elements stabilized AssignInitialStepValues();

by Orthogonal SubScales (OSS) [19], or Finite Increment // solve first step for
Calculus (FIC) [63]. // fractional step velocities
SolveStep1(mvelocity_toll, mMaxVelIterations);
The fractional step method chosen consists of four so-
lution steps, of which the first one involves a nonlinear loop // solve for pressures
for solving the nonlinearity in the convection term, while the // (and recalculate the nodal area)
double Dp_norm = SolveStep2();
rest are linear and the third one involves the explicit calcu-
lation of projection terms. ActOnLonelyNodes();
This method was implemented by creating a new //calculate projection terms

SolvingStrategy combining existing ones for different SolveStep3();
steps. The strategy was hard coded in C++, however the //correct velocities
implementation was such that all the different steps could SolveStep4();
be solved separately. This allowed the definition of a flex- return Dp_norm;

ible Python interface which in turn permits the end-user to }
control the flow of the program. This flexibility in particular

provides major advantages in defining new fluid structure This strategy can be exported to Python without loss of
interaction coupling strategies based on the existing ALE performance, by providing access to the specific methods
solver. implementing each step. We can write in Python an equiva-
For the present application a combined Strategy is lent solution step as shown in Table 2.
created to handle the solution process. The following code It can be seen that the Python code is self explanatory and
shows the Solve method of this Strategy which calls simple. Providing this interface also has the great advantage
other methods for implementing different steps: of allowing users to customize the global algorithm without
accessing the internal implementation in Kratos.
double Solve() In order to implement the elemental formulation a new
{ Element has to be created. This Element should pro-
// Assign the correct fractional step
// coefficients vide different contributions for each solution step. This is
InitializeFractionalStep(m_step, mtime_order); achieved by passing the current fractional step number as a
double Dp_norm;
variable of the ProcessInfo to the calculation method of
// predicting the velocity Element. Interestingly, this can be done without any mod-
PredictVelocity(m_step,mprediction_order);
ification of the standard elemental interface. This is one of
// initialize projections at the first steps the cases where the generality of the interface helps to inte-
InitializeProjections(m_step); grate new types of formulations. The following code shows
// Assign Velocity To Fract Step Velocity the structure of the calculation method for Element:
// and Node Area to Zero
AssignInitialStepValues(); void Fluid3D::CalculateLocalSystem(
MatrixType& rLeftHandSideMatrix,
if(m_step <= mtime_order) VectorType& rRightHandSideVector,
Dp_norm = IterativeSolve(); ProcessInfo& rCurrentProcessInfo)
else {
{ KRATOS_TRY
if(mpredictor_corrector == false)
Dp_norm = FracStepSolution(); int FractionalStepNumber =
else //iterative solution rCurrentProcessInfo[FRACTIONAL_STEP];
Dp_norm = IterativeSolve();
} if(FractionalStepNumber <= 3)
{
if(mReformDofAtEachIteration == true ) Stage1(rLeftHandSideMatrix,
Clear(); rRightHandSideVector,
rCurrentProcessInfo,
m_step += 1; FractionalStepNumber - 1);
}
else if (FractionalStepNumber == 4)
mOldDt = {
GetModelPart().GetProcessInfo()[DELTA_TIME]; Stage2(rLeftHandSideMatrix,
rRightHandSideVector,
return Dp_norm; rCurrentProcessInfo);
} }
KRATOS_CATCH("")
double FracStepSolution() }
{
// setting the fractional velocity to
// the value of the velocity Where Stage1 and Stage2 are private methods.
Table 2 The fractional step strategy written in Python
def SolutionStep1(self):
normDx = Array3(); normDx[0] = 0.00; normDx[1] = 0.00; normDx[2] = 0.00;
is_converged = False
iteration = 0
while(is_converged == False and iteration < self.max_vel_its):

(self.solver).FractionalVelocityIteration(normDx);
is_converged = (self.solver).ConvergenceCheck(normDx,self.vel_toll);
print iteration,normDx
iteration = iteration + 1
def Solve(self):
if(self.ReformDofAtEachIteration == True):
(self.neighbour_search).Execute()
(self.solver).InitializeFractionalStep(self.step, self.time_order);
(self.solver).InitializeProjections(self.step);
(self.solver).AssignInitialStepValues();
self.SolutionStep1()
(self.solver).SolveStep2();
(self.solver).ActOnLonelyNodes();
self.step = self.step + 1
if( self.ReformDofAtEachIteration == True):

(self.solver).Clear()
11.1.2 Benchmark for the cylinder. Figure 36 shows a view of velocity field
obtained.
Kratos is a general purpose code. Therefore, it is expected to The results showed an excellent agreement with the val-
show a slightly lower performance than codes optimized for ues calculated by FEFLO both in term of peak values and of
a single purpose. A well optimized implementation can re- shedding frequency, as can be seen in Fig. 37. Note that the
duce the performance overhead to the amount introduced by initiation of the shedding is not deterministic and may hap-
Kratos. An effort was made to optimize the implementation pen at any time which justifies the phase difference between
mentioned above, so it is interesting to compare its perfor- the two codes.
mance against existing fluid solvers in order to estimate the The timing results are interesting. FEFLO appeared to be
order of performance overhead introduced by Kratos. 50% faster than Kratos. This is considered a good result tak-
As usual it is not trivial to perform a good benchmark ing in account that FEFLO features a highly optimized edge
as each program implements a slightly different formula- based data structure while Kratos is purely element based.
tion. Nevertheless a comparison was possible here with the On the other hand, Zephyr features an element based for-
code Zephyr, an in house program developed at UPC, and mulation and implements the same fractional method step.
with FEFLO a highly optimized fluid solver developed at The main difference was the treatment of the projection
the Laboratory for Computational Physics and Fluid Dy- terms and the use of four integration points for the calcu-
namics (LCPFD) in George Washington University at Wash- lation of the element contributions in Zephyr. The results
ington, DC [45]. For the first case the formulation is exactly showed that Kratos is about twice as faster than Zephyr.
the same with only minor differences in the implementation.
The second solver is an edge based formulation and the only 11.2 Fluid-structure Interaction
possible comparison was with a predictor corrector scheme.
The benchmark represents the analysis of a three dimen- Coupled problems can be naturally implemented inside
sional cylinder at Reynolds number Re = 190. Figure 35 Kratos via the Python interface. The fluid solver and the
shows the model used. The no slip boundary condition is structural solver can be implemented separately and coupled
used at the walls of the cylinder, while slip conditions are using this interface. The first action required to solve a fluid
used everywhere else. The inflow velocity is set to 1 m/s. structure interaction (FSI) problem is to load the different
The mesh generated by FEFLO has a resolved boundary applications involved. The code in Table 3 shows this step
layer and contains 30000 nodes and 108000k tetrahedral el- in Python. Then a very simple explicit coupling procedure
ements. The values computed were the lift and drag history can be expressed by a Python script as shown in Table 4.
Fig. 35 (a) Geometry of cylinder example, domain dimension

19.0 × 8.0 × 0.2 and Rc = 0.5. (b) Detail of the mesh used for the
cylinder example
Of course many different alternative coupling schemes

exist, see for example [40, 77]. Many of them can be imple-
mented without making changes to the single field solvers.
An example of fluid-structure interaction is given in Fig. 38.
11.3 Particle Finite Element Method

Fig. 36 Velocity at different time steps
The Particle Finite Element Method (PFEM) [37–39, 64, 65]
is a method for the solution of fluid problems on varying This reusability allows the fast development of new formu-
domains in time. The basic concept is that each particle is lations which can be tested by solving large scale real-life
followed in a Lagrangian way and the mesh is regenerated problems. Examples of simulations done with the PFEM im-
at each time step. plemented in Kratos can be found in [46].
The main computational challenges faced are the efficient Figure 39 shows an object (an unmanned vehicle) which
regeneration of the mesh and the optimized recalculation of floats on the surface of the water after landing. This is a
all element contributions. Good performance is achieved by good example of application of the PFEM for dealing with
linking with an external mesh generation library and by us- a Fluid-Structure Interaction problem.
ing the optimized Kratos fluid solver. The solution sequence Two validation examples showing the impact of wedges
is controlled by the Python interface. A part of the Python with different shapes on the surface of the water are showed
script is given in Table 5. in Fig. 40 on the top of the experimental results. These last
This example shows how a previously implemented fluid two examples were run in Kratos using a different CFD
solver can be reused when implementing a new algorithm. solver as described in [78].
Fig. 37 (Color online) The comparison of results obtained by Kratos (red line) using a predictor corrector scheme and FEFLO (blue line). (a) Lift
calculated for the cylinder. (b) Drag calculated for the cylinder
Table 3 Importing different applications involved in solving the FSI coupled problem
#including kratos path

kratos_libs_path = ’kratos/libs/’
kratos_applications_path = ’kratos/applications/’
import sys
sys.path.append(kratos_libs_path)
sys.path.append(kratos_applications_path)
#importing Kratos main library

from Kratos import *
kernel = Kernel() #defining kernel
#importing applications
import applications_interface
applications_interface.Import_ALEApplication = True
applications_interface.Import_IncompressibleFluidApplication = True
applications_interface.Import_StructuralApplication = True
applications_interface.Import_FSIApplication = True
applications_interface.ImportApplications(kernel, kratos_applications_path)
11.4 Thermal Inverse Problem specified functional. By a functional, we mean a correspon-

dence which assigns a number to each function belonging
Inverse problems are found in many areas of science and to some class. Also, inverse problems might be ill-posed in
engineering. They can be described as being opposite to di- which case the solution might not meet existence, unique-
rect problems. In a direct problem the cause is given, and ness or stability requirements.
the effect is determined. In an inverse problem the effect is While some simple inverse problems can be solved ana-
given, and the cause must be estimated [41]. There are two lytically, the only practical technique for general problems is
main types of inverse problems: input estimation problems, to approximate the solution using direct methods. The fun-
in which the system properties and output are known and damental idea underlying the so called direct methods is to
the input is to be estimated; and properties estimation prob- consider the variational problem as a limit problem for some
lems, in which the system input and output are known and function optimization problem in many dimensions. Unfor-
the properties are to be estimated [41]. tunately, due to both their variational and ill-posed nature,
Mathematically, inverse problems fall into the more gen- inverse problems are difficult to solve.
eral class of variational problems. The aim of a variational Neural networks is one of the main fields of artificial in-
problem is to find a function which minimizes the value of a telligence [36]. There are many different types of neural net-
Table 4 A very simple explicit FSI coupling procedure implemented in Python
class ExplicitCoupling:
def Solve(self):
# solve the structure (prediction)

(self.structural_solver).Solve()
## map displacements to the structure

(self.mapper).StructureToFluid_VectorMap(DISPLACEMENT,DISPLACEMENT)
## move the mesh

(self.mesh_solver).Solve()
## set the fluid velocity at the interface to

## be equal to the corresponding mesh velocity
self.CopyVectorVar(MESH_VELOCITY,VELOCITY,self.interface_fluid_nodes);
## solve the fluid

(self.fluid_solver).Solve()
## map displacements to the structure

(self.mapper).FluidToStructure_ScalarMap(PRESSURE,POSITIVE_FACE_PRESSURE)
# solve the structure (correction)

(self.structural_solver).Solve()
works, of which the multilayer perceptron is an important training algorithm will evaluate the performance function
one [81]. Neural networks provide a direct method for the f (a) many times.
solution of general variational problems and, consequently,
This algorithm provides an example of how Kratos can be
inverse problems [20].
embedded into an optimization application in which differ-
In this example neural networks are used to solve thermal ent steps of finite element analysis are necessary to achieve
inverse problems. In order to solve this problem we need to the solution.
solve the heat transfer equation. The Flood library [51] de- Kratos has been embedded inside the Flood library as its
veloped at CIMNE is an open source neural networks library solving engine in order to calculate the solution of partial
written in C++. Flood was used to create the neural network differential equations.
necessary for solving this problem. While the Flood library Here this methodology is applied to solve two different
does not include utilities for solving partial differential equa- thermal inverse problems.
tions, it uses Kratos and its thermal application to solve the
thermal problem. This example validates the integrability of 11.4.2 Implementation
Kratos as a library into another project. It also demonstrates
its robustness due to the fact that the Neural Network algo- The Flood library uses Kratos to solve a thermal problem
rithm runs Kratos to analyze the same model several times. several times with different properties and boundary condi-
In this situation any small problem (for example, in memory tions. In order to do this it access the internal data of Kratos
management) might cause an execution error. and change the boundary conditions assigned to the different
Nodes. This is done without any file interface which would
11.4.1 Methodology dramatically reduce the performance. The first task is imple-
ment the interface for the direct solution using Kratos. The
The general solution of variational problems using Neural following code shows the main part of this interface:
networks consists of three steps [20]:
// Initializing Kratos kernel
Kernel kernel;
• Definition of the functional space. The solution here is kernel.Initialize();
represented by a multilayer perceptron.
// Initializing Kratos thermal application
• Formulation of the variational problem. For this perfor- KratosThermalApplication thermal_application;
mance functional F (y(x, a)) must be defined. In order kernel.AddApplication(thermal_application);
to evaluate the functional we solve a partial differential // Read mesh
equation using the FEM within Kratos. GidIO gidIO("thermal_problem");
• Solution of the reduced function optimization problem gidIO >> mesh;
f (a). This is achieved by the training algorithm. The // Set properties to optimization values d,c,k
Fig. 38 Flag flatter simulation using fluid structure interaction with mesh movement
Properties& r_properties = mesh.GetProperties(1);

r_properties[DENSITY] = d; double mu = 0.5;
r_properties[SPECIFIC_HEAT_RATIO] = c; double sigma = 0.05;
r_properties[THERMAL_CONDUCTIVITY] = k;
double numerator = exp(-pow(time[i]-mu,2)
// Assign initial temperature to nodes numerator /= (2.0*pow(sigma,2)));
// with fixed temperature double denominator = 8*sigma*sqrt(2.0*pi);
MeshType::NodeIterator i_node;
for(i_node = mesh.NodesBegin() ; boundaryTemperature[i] = numerator/denominator;
i_node != mesh.NodesEnd() ; i_node++)
if(!(i_node->IsFixed(TEMPERATURE))) // Assign boundary temperature
i_node->SetSolutionStepValue(TEMPERATURE, for(i_node = mesh.NodesBegin() ;
initialTemperature); i_node != mesh.NodesEnd() ; i_node++)
if(i_node->IsFixed(TEMPERATURE))
// Creating solver i_node->SetSolutionStepValue(TEMPERATURE,
// ... boundaryTemperature[i]);
// Main loop // Solving using thermal solver

for(int i = 1; i < numberOfTimeSteps; i++) { Solve();
// Obtain time
time[i] = time[i-1] + deltaTime; // Now updating the nodal temperature values
// by result of solved equation system.
// Obtain boundary temperature Update();
// Gaussian function
Table 5 Implementation in Kratos of particle finite element method ible but clear and intuitive interface that Kratos provides
(PFEM)
for other applications to communicate with it. First, applica-
tion changes the Element properties to its prescribed val-
def Solve(self,time,gid_io):
ues. Then, it changes the temperature value for all Nodes
self.PredictionStep(time) to some initial value. Afterwards it tries to solve the FEM
self.FluidSolver.Solve()
problem using different boundary conditions assigning fixed
def PredictionStep(self,time): values of temperature to Nodes. Finally it retrieves the tem-
domain_size = self.domain_size
perature at a specific Node. It can be seen that some steps
# performing a first order prediction are directly inside the time loop. This restrict us from solv-
# of the fluid displacement
(self.PfemUtils).Predict(self.model_part)
ing the problem using usual time integration algorithms.
self.LagrangianCorrection() The inverse problem also involves similar steps but in the
(self.MeshMover).Execute();
form of performance functions of the Flood library. In this
(self.PfemUtils).MoveLonelyNodes(self.model_part) case Kratos is adapted to the working methodology of Flood
without any problem.
## ensure that no node gets too close to the walls The tool obtained by combining these two application has
(self.ActOnWalls).Execute();
been successfully used for solving boundary temperature es-
## move the mesh timation problems and diffusion coefficient estimation prob-
(self.MeshMover).Execute(); lems [20, 52].
## smooth the final position of the nodes to Some results can be seen in Fig. 41 which shows the
## homogenize the mesh distribution agreement between the estimated diffusion coefficient and
(self.CoordinateSmoother).Execute();
the diffusion coefficient estimated by the neural network for
## move the mesh a square domain problem.
The results of a different inverse problem are shown in
# regenerate the mesh Fig. 42. The graphs shown distribution a comparison of the
self.Remesh()
actual boundary temperature and the one estimated by the
neural network for a square domain.
Full details of the examples, as well as a complete de-
scription of the theory used can be found in [52].
Further applications and other class of problems imple-
mented in Kratos can be found in [2, 61, 74–76, 79].
12 Conclusions and Future Work
12.1 Conclusions
Kratos, a framework for developing multi-disciplinary FEM

programs has been designed and implemented. This frame-
work provides a high level of flexibility and generality
which is required for dealing with multi-disciplinary prob-
lems. Developers in different areas can adapt Kratos for their
needs without altering the standard interface used to com-
Fig. 39 An unmanned vehicle floats on the surface of the water after
municate with other fields in coupled analysis. The applica-
landing
tions already implemented in the Kratos framework can be
used for solving multi-disciplinary problems using any mas-
// Obtain center node temperature ter and slave strategies or even by solving simultaneously.
nodeTemperature[i] =
center_node.GetSolutionStepValue(TEMPERATURE); Finally a python interface gives extra flexibility in handling
nonstandard algorithms.
equation_system.ClearData();
} Several reusable components are provided to help de-
velopers allowing easier and faster implementation of their
The part initializing the solver has been removed to make applications. Data structure, IO, linear solvers, geometries,
the sample code shorter and only the parts that Flood uses quadrature tools, and different strategies are examples of
to interact with Kratos are kept. This code shows the flex- these reusable components. Use of these components makes
Fig. 40 Impact of wedges with different shapes on the surface of the water
the application development not only faster, but also ensures tainers are used alternatively in places where performance or
compatibility with other tools for solving multi-disciplinary flexibility are more important. Being able to store even the
problems. list of neighbor Nodes or Elements shows their flexibility
Kratos is also extensible at different levels of implemen- in practice.
tation. Each application can add its variables, degrees of An entity base data structure has been developed in
freedom, Properties, Elements, Conditions, and Kratos. This approach gives more freedom in partition-
solution algorithms to Kratos. The object-oriented structure ing the domain or in creating and removing Nodes and
and appropriate patterns used in its design make these ex- Elements. Several levels of abstraction like Mesh,
tensions easy while reducing the need for modifications. MoldePart and Model are provided to help users group
Last but not least, the performance of Kratos is compa- model and data information in different ways. These objects
rable even to single purpose programs and different bench- are effectively used for separating domains information in
marks has shown this in practice. This makes Kratos a prac- multi-disciplinary problems or sending a single part to a
tical tool for solving industrial multi-disciplinary problems. process.
All these objectives were achieved not only by a num- The Element and Condition classes are designed
ber of innovative development, but also by collecting and as the extension points of Kratos. Their generic interfaces
reusing several existing works. Some of these aspects are as provide all information necessary for calculating their local
follow: components and also are flexible enough for handling new
Kratos has an object-oriented and multi-layer structure arguments in the future.
which reduces the dependency between different parts of Several processes and strategies has been developed to
program. It helps in maintenance of the code and also helps handle standard procedures in finite element programming.
developers in understanding the code. These layers are de- These components increase the reusability of the code and
fined in a way such as each user has to work in the smallest decrease the effort needed to implement new finite element
number of layers as possible. The implementation difficul- application using Kratos.
ties needed for each layer are also tuned for the knowledge Some experimental work has been done to handle ele-
of users. mental expression using a higher level of abstraction. In this
A new variable base interface has been designed and im- way elemental expressions can be written in C++ but with
plemented. This interface is used at different levels of ab- a meta language very similar to mathematical notations and
straction and has proven to be clear, flexible, and extensible. then can be compiled with the rest of the code using the
New heterogeneous containers have been implemented C++ compiler. These expressions have been successfully
in order to hold different types of data without any modi- tested and their performance is comparable to manually im-
fications. The DataValueContainer is designed to be plemented codes.
very flexible while the VariablesListContainer is A flexible and extensible IO module for finite element
designed to be fast but less robust. In Kratos these two con- programs has been developed. Any application built with
Fig. 41 Actual diffusion

coefficient (a) and estimated
diffusion coefficient (b) for the
diffusion coefficient estimation
problem
Kratos can use IO for reading and writing its own concepts 12.2 Future Work
without making any change to it. An interpreter is also im-
plemented to handle Kratos data files but the major inter- Parallelization of Kratos framework is the main task to be
preting task is given to the Python interpreter. This flexi- undertaken in the future. The growing size of problems and
ble interpreter with its object-oriented high level language the increase of available parallel computing machines (even
can be used to implement and execute new algorithms us- in the personal computers sector), stress the importance for
ing Kratos. In this way the implementation and maintenance parallelization of numerical codes. Fortunately, several as-
cost of a new sophisticated interpreter is eliminated. pects of Kratos become useful in this process.
4. ABAQUS Inc. ABAQUS Scripting User’s Manual

5. Aho AV, Sethi R, Ullman JD (1986) Compilers principles, tech-
niques and tools. Addison-Wesley, Reading
6. Aho AV, Ullman JD (1978) Principles of compiler design.
Addison-Wesley, Reading
7. Aho AV, Ullman JD, Hopcroft JE (1983) Data structures and algo-
rithms. Addison-Wesley, Reading
8. Anderson E, Bai Z, Bischof C, Blackford S, Demmel J, Don-
garra J, Croz JD, Greenbaum A, Hammarling S, McKenney A,
Sorensen D (1995) LAPACK users’ guide, 2nd edn. Society for
Industrial and Applied Mathematics, Philadelphia
9. Appel AW, Ginsburg M (1999) Modern compiler implementation
in C. Cambridge University Press, Cambridge
10. Archer GC (1996) Object-oriented finite element analysis. PhD
thesis, University of California at Berkeley
11. Archer GC, Fenves G, Thewalt C (1999) A new object-oriented
finite element analysis program architecture. Comput Struct
70(1):63–75
12. Bangerth W (2000) Using modern features of C++ for adaptive
Fig. 42 (Color online) Actual boundary temperature (red), estimated finite element methods: Dimension-independent programming in
boundary temperature (green) and measured temperature at the center deal.II. In: Deville M, Owens R (eds) Proceedings of the 16th
of the square (blue) for the boundary temperature estimation problem IMACS World congress 2000, Lausanne, Switzerland, Document
Sessions/118-1
13. Bangerth W, Hartmann R, Kanschat G. deal.II Dif-
Creating new processes and strategies can increase the ferential equations analysis library, Technical reference.
reusability of the code and also the completeness of Kratos. http://www.dealii.org
This can be done also by revising the processes and strate- 14. Bangerth W, Hartmann R, Kanschat G (2006) deal.II—a general
purpose object oriented finite element library. Technical Report
gies implemented in different applications and adding a ISC-06-02-MATH, Institute for Scientific Computation, Texas
generic version of them to Kratos which could be usable A&M University
for a wider set of applications. Also new solvers and pre- 15. Bangerth W, Kanschat G (1999) Concepts for object-oriented
conditioners should be added to extend the solving abilities finite element software—the deal.II library. Preprint 99-43
(SFB 359), IWR Heidelberg, Oct. 1999
of Kratos. 16. Bathe K-J (1996) Finite element procedures. Prentice-Hall, New
Implementing missing components for elemental expres- York
sion and practically use them can help the fast development 17. Cardona A, Klapka I, Geradin M (1994) Design of a new finite
of finite element formulations in Kratos, At the same time, it element programming environment. Eng Comput 11(4):365–381
can be used to optimize the new formulations or even trans- 18. Codina R (2001) Pressure stability in fractional step finite element
methods for incompressible flows. J Comput Phys 170:112140
form them automatically to parallel codes. Formulations are 19. Codina R (2002) Stabilized finite element approximation of tran-
another part of Kratos to explore. Adding nodal or edge sient incompressible flows using orthogonal subscales. Comput
based formulations to Kratos can be a good way to refine Methods Appl Mech Eng 191(39):4295–4321
its design in practice. 20. Dadvand P, Lopez R, Oñate E (2006) Artificial neural networks
for the solution of inverse problems. In: ERCOFTAC
Serialization for automatization of problem loading and
21. Dadvand P, Mora J, González C, Arraez A, Ubach P, Oñate E
saving and passing data over network is another line of ex- (2002) Kratos: An object-oriented environment for development
tensions. Supporting binary format for input can reduce sig- of multi-physics analysis software. In: Proceedings of the WCCM
nificantly the data reading time. V fifth world congress on computational mechanics, July 2002
22. Donéa J, Huerta A (2003) Finite element methods for flow prob-
Acknowledgements We would like to thank the whole Kratos team lems. Wiley, New York
for their contributions and valuable feedback that was decisive for 23. Dubois-Pélerin Y, Pegon P (1997) Improving modularity in object-
the evolution of Kratos. In particular thanks to Pavel Ryzhakov and oriented finite element programming. Commun Numer Methods
Dr. Roberto Lopez for providing some of the examples. This work was Eng 13:193–198
partially supported by XPRES project of the Spanish government. 24. Dubois-Pèlerin Y, Zimmermann T (1993) Object-oriented finite
element programming: Iii. an efficient implementation in C++.
Comput Methods Appl Mech Eng 108(1–2):165–183
25. Dubois-Pèlerin Y, Zimmermann T, Bomme P (1992) Object-
References oriented finite element in programming: Ii. a prototype program
in smalltalk. Comput Methods Appl Mech Eng 98(3):361–397
1. Boost serialization library. http://www.boost.org/libs/serialization/ 26. Edelson DR (1992) Smart pointers: They’re smart, but they’re not
doc/index.html pointers. Technical report, Santa Cruz, CA, USA
2. Papadrakakis M, Oñate E, Schrefler B (eds) (2007) Updated La- 27. Eyheramendy D, Zimmermann T (1996) Object-oriented finite
grangian formulation of a quasi-incompressible fluid element, element programming: an interactive environment for symbolic
Ibiza, Spain, Proceedings. CIMNE, Barcelona derivations, application to an initial boundary value problem. Adv
3. ABAQUS Inc. ABAQUS Scripting Reference Manual Eng Softw 27(1–2):3–10
28. Eyheramendy D, Zimmermann T (1996) Object-oriented finite el- 53. Mackie RI (1992) Object oriented programming of the finite ele-
ements ii. a symbolic environment for automatic programming. ment method. Int J Numer Methods Eng 35(2):425–436
Comput Methods Appl Mech Eng 132(3):277–304(28) 54. Mackie RI (1997) Using objects to handle complexity in finite el-
29. Eyheramendy D, Zimmermann T (1998) Object-oriented finite ement software. Eng Comput 13(2):99–111
elements iii. theory and application of automatic programming. 55. Maplesoft. Maple’s documentation
Comput Methods Appl Mech Eng 154(1):41–68(28) 56. MathWorks. Matlab’s documentation
30. Felippa CA, Geers TL (1988) Partitioned analysis of coupled me- 57. Menetrey P, Zimmermann T (1993) Object-oriented non-linear fi-
chanical systems. Eng Comput 5:123–133 nite element analysis: application to j2 plasticity. Comput Struct
31. Felippa CA, Park KC, Farhat C (2001) Partitioned analysis of 49(5):767–773
coupled mechanical systems. Comput Methods Appl Mech Eng 58. Miller G (1991) An object-oriented approach to structural analysis
190:3247–3270 and design. Comput Struct 40(1):75–82
32. Filho JRA, Devloo PRB (1991) Object oriented programming in 59. Miller G (1994) Coordinate-free isoparametric elements. Comput
scientific computations: the beginning of a new era. Eng Comput Struct 49(6):1027–1035
8(1):81–87 60. Miller GR, Banerjee S, Sribalaskandarajah K (1995) A framework
33. Forde BWR, Foschi RO, Stiemer SF (1990) Object-oriented finite for interactive computational analysis in geomechanics. Comput
element analysis. Comput Struct 34(3):355–374 Geotech 17(1):17–37
34. Gamma E, Helm R, Johnson R, Vlissides J (1995) Design patterns: 61. Mora J, Otín R, Dadvand P, Escolano E, Pasenau MA, Oñate E
elements of reusable object-oriented software. Addison-Wesley, (2006) Open tools for electromagnetic simulation programs.
Reading COMPEL 25(3):551–564
35. Gonnet GH, Baeza-Yates R (1991) Handbook of algorithms and 62. Mount D, Arya S (1997) Ann: A library for approximate nearest
data structures: in Pascal and C, 2nd edn. Addison-Wesley, Read- neighbor searching. citeseer.ist.psu.edu/mount97ann.html
ing 63. Oñate E (2004) Possibilities of finite calculus in computational
36. Haykin S (1994) Neural networks: A comprehensive fundation. mechanics. Int J Numer Methods Eng 60(1):255–281
Prentice Hall, New York 64. Oñate E, Idelsohn S, Celigueta M, Rossi R (2008) Advances in the
37. Idelshon SR, Oñate E (2006) To mesh or not to mesh. That is the particle finite element method for the analysis of fluid-multibody
question. Comput Methods Appl Mech Eng 195:4681–4696 interaction and bed erosion in free surface flows. Comput Methods
38. Idelsohn SR, Oñate E, Calvo N, Pin FD (2003) The meshless finite Appl Mech Eng 197:1777–1800
element method. Int J Numer Methods Eng 58:893–912 65. Oñate E, Idelsohn S, Pin FD, Aubry R (2004) The particle finite
39. Idelsohn SR, Oñate E, Pin FD (2004) The particle finite element
element method. An overview. Int J Comput Methods 1(2):267–
method: a powerful tool to solve incompressible flows with free-
307
surfaces and breaking waves. Int J Numer Methods Eng 61:964–
66. Open Engineering. OOFELIE
989
67. Patzák B. OOFEM documentation. Czech Technical University,
40. Idelsohn SR, Pin FD, Rossi R, Oñate E (2009) Fluid-structure in-
Faculty of Civil Engineering, Department of Structural Mechan-
teraction problems with strong added-mass effect. Int J Numer
ics
Methods Eng 80:1261–1294. doi:10.1002/nme.2659
68. Patzák B, Bittnar Z (1999) Object oriented finite element model-
41. Kirsch A (1996) An introduction to the mathematical theory of
ing. Acta Polytech 39(2):99–113
inverse problems. Springer, Berlin
69. Pidaparti RMV, Hudli AV (1993) Dynamic analysis of structures
42. Klapka I, Cardona A, Geradin M (1998) An object oriented im-
using object-oriented techniques. Comput Struct 49(1):149–156
plementation of the finite element method for coupled problems.
Rev Eur Elements Finis 7(5):469–504 70. Press WH, Vetterling WT, Teukolsky SA, Flannery BP (2002) Nu-
43. Klapka I, Cardona A, Geradin M (2000) Interpreter oofelie for merical recipes in C++: the art of scientific computing. Cam-
pdes. In: European congress on computational methods in applied bridge University Press, Cambridge
sciences and engineering (ECCOMAS 2000), Barcelona 71. Raphael B, Krishnamoorthy CS (1993) Automating finite ele-
44. Knuth DE (1998) The art of computer programming: sorting and ment development using object oriented techniques. Eng Comput
searching, vol 3, 2nd edn. Addison-Wesley, Reading 10(3):267–278
45. Laboratory for Computational Physics and Fluid Dynamics 72. Ribó R, Pasenau M, Escolano E, Ronda JSP. GiD user manual.
(LCP&FD). FEFLO project CIMNE, Barcelona
46. Larese A, Rossi R, Oñate E, Idelsohn SR (2008) Validation of 73. Ribó R, Pasenau M, Escolano E, Ronda JSP, González LF. GiD
the particle finite element method (pfem) for simulation of free reference manual. CIMNE, Barcelona
surface flows. Eng Comput 25:385–425 74. Rossi R (2005) Light weight structures: structural analysis and
47. Lindemann J, Dahlblom O, Sandberg G (2006) Using Corba mid- coupling issues. PhD thesis, University of Bologna
dleware in finite element software. Future Gener Comput Syst 75. Rossi R, Idelsohn SR, Oñate E (2006) On the possibilities and
22(1–2):158–193 validation of the particle finite element method (pfem) for complex
48. Logg A (2007) Automating the finite element method. Arch Com- engineering fluid flow problems. In: Proceedings of ECCOMAS
put Methods Eng 14(2):93–138 CFD 2006, Egmond aan Zee, The Netherlands
49. Lu J, White D, Chen W-F (1993) Applying object-oriented de- 76. Rossi R, Oñate E (2010) Validation of a fsi simulation
sign to finite element programming. In: SAC ’93: proceedings of procedure—bridge aerodynamics modelproblem. Eng Comput
the 1993 ACM/SIGAPP symposium on applied computing. ACM, (to appear)
New York, pp 424–429 77. Rossi R, Oñate E (2010) Analysis of some partitioned algo-
50. Lu J, White DW, Chen W-F, Dunsmore HE (1995) A matrix class rithms for fluid-structure interaction. Eng Comput 27:20–56.
library in C++ for structural engineering computing. Comput doi:10.1108/02644401011008513
Struct 55(1):95–111 78. Rossi R, Ryzhakov P, Oñate E (2009) A monolithic fe formula-
51. López R. Flood: an open source neural networks C++ library. tion for the analysis of membranes in fluids. Int J Space Struct
CIMNE 24(4):205–210
52. López R, Balsa-Canto E, Oñate E (2008) Neural networks for 79. Rossi R, Vitaliani R (2004) Numerical coupled analysis of flexible
variational problems in engineering. Int J Numer Methods Eng structures subjected to the fluid action. In: 5th PhD symposium in
75(11):1341–1360 civil engineering, Delft
80. Saad Y (2003) Iterative methods for sparse linear systems. Society in object-oriented parallel environments (ISCOPE’97). Springer,
for Industrial and Applied Mathematics, Philadelphia Berlin, Heidelberg, New York, Tokyo
81. Šíma J, Orponen P (2003) General-purpose computation with 87. Vinoski S (1997) CORBA: integrating diverse applications within
neural networks: A survey of complexity theoretic results. Neural distributed heterogeneous environments. IEEE Commun Mag,
Comput 15(12):2727–2778 14(2)
82. Touzani R. OFELI documentation 88. Wolfram Research. Mathematica’s documentation
83. Touzani R (2002) An object oriented finite element toolkit. In: 89. Zienkiewicz OC, Taylor RL, Zhu JZ (2007) Finite element
Proceedings of the fifth world congress on computational mechan- method: its basis and fundamentals. Butterworth-Heinemann,
ics (WCCM V) Stoneham
84. Veldhuizen TL (1995) Expression templates. C++ Rep 7(5):26– 90. Zimmermann T, Dubois-Pèlerin Y, Bomme P (1992) Object-
31 oriented finite element programming: I: Governing principles.
85. Veldhuizen TL (1998) Arrays in blitz++. In: Proceedings of the Comput Methods Appl Mech Eng 98(2):291–303
2nd international scientific computing in object-oriented parallel 91. Zimmermann T, Eyheramendy D (1996) Object-oriented finite el-
environments (ISCOPE’98). Lecture notes in computer science. ements i. principles of symbolic derivations and automatic pro-
Springer, Berlin gramming. Comput Methods Appl Mech Eng 132(3):259–276
86. Veldhuizen TL, Jernigan ME (1997) Will C++ be faster than For- (18)
tran? In: Proceedings of the 1st international scientific computing

An Object-Oriented Environment For Developing Finite Element Codes For Multi-Disciplinary Applications

Uploaded by

Document Informationclick to expand document information

Document Informationclick to expand document information

Copyright:

Available Formats

An Object-Oriented Environment For Developing Finite Element Codes For Multi-Disciplinary Applications

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

An Object-Oriented Environment For Developing Finite Element Codes For Multi-Disciplinary Applications

Uploaded by

Copyright:

Available Formats

Arch Comput Methods Eng (2010) 17: 253–297

An Object-oriented Environment for Developing Finite Element

Some newer implementations have used modern software

3.2.3 Solving the Global System 4 Multi-disciplinary Problems

3.2.4 Calculating Additional Results

This step consist of calculating some additional results from

Several algorithms in FEM contain iterations in different

Advancing Calculating the next time step of a subsystem

History of object-oriented design for finite element pro-

Fig. 4 Main classes defined in

Fig. 5 Dividing the Kratos

const NewElementType mMyElement;

Here Application defines its new components and

// registering variables in Kratos. • A variable encapsulate all information needed by differ-

7.1 The Variable Base Interface Definition 7.2.1 VariableData

Fig. 7 Adaptor class virtual void SomeElement::CalculateLocalSystem(

// Calculating local matrix and

// Getting a reference // Writing procedure ...

Fig. 8 Combining containers

Disadvantages of Combining Containers

Fig. 9 Combining different

Fig. 10 Data value container

Fig. 11 A data value container

Variables List Container Advantages

Variables List Container Disadvantages

Fig. 14 Accessing to a value in

8.2 Organization of Data 8.2.1 Global Organization of the Data Structure

Fig. 17 Using buffer for all

Fig. 18 The current structure

Fig. 19 Different elements or

of Kratos which makes it useful as an argument of global

Fig. 24 ModelPart can share

Fig. 25 ModelPart manages

Fig. 26 Elements’ structure

Fig. 27 Element’s structure

Fig. 28 Process structure

ods a ProcessInfo is passed to these methods. In this 9.3 Processes

9.4 Solving Strategies

After designing Process and its derived classes, we will

Fig. 30 Deferring different

Fig. 31 Extended Multi format

template<class TDataType> our structure. KratosComponents class encapsulates a

10.1.1 IO Interface Design

Fig. 33 Global structure of an

Fig. 34 Parse tree for an if

[18] using equal order pressure-velocity elements stabilized AssignInitialStepValues();

This method was implemented by creating a new //calculate projection terms

be solved separately. This allowed the definition of a flex- return Dp_norm;

control the flow of the program. This flexibility in particular

Table 2 The fractional step strategy written in Python

while(is_converged == False and iteration < self.max_vel_its):

if( self.ReformDofAtEachIteration == True):

Fig. 35 (a) Geometry of cylinder example, domain dimension

Of course many different alternative coupling schemes

11.3 Particle Finite Element Method

#including kratos path

#importing Kratos main library