Advances in Engineering Software 32 (2001) 759767

www.elsevier.com/locate/advengsoft

Design of object oriented nite element code

B. Patzak*, Z. Bittnar
Faculty of Civil Engineering, Czech Technical University in Prague, Thakurova 7, 166 29 Prague, Czech Republic
Received 25 October 1999; accepted 22 February 2001

Abstract
In this paper, a general structure of a recently developed object oriented nite element code is presented. The main reasons which lead to
the development of the new general environment for a complex nite element computations are discussed. The principal requirements for
new FEM code are formulated. The attention in this paper is put on an overall description of the program design and, particularly, on the
description of representations of the general material modelelement frame and the analysis module. Finally, computational efciency of
developed environment is compared to existing codes. q 2001 Civil-Comp Ltd and Elsevier Science Ltd. All rights reserved.
Keywords: Object oriented programming; Finite element software

1. Introduction

goals can be summarized as follows:

The engineering community is facing growing demands

for state of the art modeling and realistic predictions in
many elds. Such demands lead to a very complex geometry
models with many degrees of freedom involved. In many
cases, the nonlinear behaviour has to be taken into account,
including complex nonlinear constitutive models and
geometrically nonlinear effects. The recent progress in
computer technology allows a practical use of advanced
and complex nite element models.
Commercial products often provide a set of userdened subroutines, which can be used to extend the
package abilities in a specic direction. However, for
example, the implementation of a principally new
constitutive model is usually extremely hard or even
impossible. On the other hand, programs distributed
with source codes (free- and share-ware codes) often
suffer from unclear data structure, bad program design,
or insufcient documentation. Extensibility is then
becoming time consuming and error prone. In addition,
as a consequence of poor modularity, the teamwork is
hardly possible.
Due to these facts, the necessity for a suitable FEM
computational environment is evident. Such computational
environment must be able to reect the continuing development in terms of its wide and unrestricted extensibility,
teamwork support, robustness, and portability. The main

The open nature of the kernel the kernel design and its
implementation must be extensible in a broad sense. This
should also be valid for a particular module design.
The program structure must comply with a modular
design. This is very important for teamwork support.
The code must be easily modiable and maintainable.
The portability over available platforms is an important
and natural requirement.
The computational performance, similar to programs
written in Fortran or C.

* Corresponding author.
E-mail address: borek.patzak@fsv.cvut.cz (B. Patzak).

A general object oriented nite element kernel has been

designed and implemented. Several specialized modules
have already been implemented on top of this general
kernel. In the following sections of this paper, the basic
principles of kernel design will be described with special
attention to the key aspects of the overall kernel design. For
the graphical representation of the design of structure of
object oriented kernel, the CoadYourdon methodology
(see Ref. [6] for details) will be used.

2. General structure
The kernel provides abstractions (representations) for all
necessary building blocks of the nite element method.
These abstractions, represented by the corresponding
general classes, usually declare the common attributes and
services. The particular service may be declared as an

0965-9978/01/$ - see front matter q 2001 Civil-Comp Ltd and Elsevier Science Ltd. All rights reserved.
PII: S 0965-997 8(01)00027-8

760

B. Patzak, Z. Bittnar / Advances in Engineering Software 32 (2001) 759767

Fig. 1. General structure of the object oriented code.

abstract one, requiring its implementation by the

specialized derived classes or, on the other hand, a
general implementation may be provided using lowlevel services implemented by the derived classes. The
derived classes are allowed to overload these general
implementations to reect the specic needs. The very
important role of the abstract classes consists in declaring the common required services (so-called abstract
services). This allows potential user to use the derived
class instances on a very abstract level, hiding the particular implementation details, by using only the general
services declared by the base classes. As a consequence,
such communication using abstract services from the
general interface, allows the programmer to be independent of a particular derived class interface. Therefore,
the use of various suitable implementations (derived
from the same base class, but representing different
implementations) is fully transparent without the necessity to change the code because all derived classes have
to implement the same general interface. However, the
design of general interfaces is one of the most crucial
parts of the overall code design. The general services
must be carefully designed to cover all needs and to reect
possible future demands.
The general structure of the kernel is shown in Fig. 1. The
kernel provides the denitions for all basic abstract classes
of nite element method. For example, abstractions for

general DOF, 1 Dof manager, 2 nite element, boundary

and initial condition, constitutive and cross section model,
analysis module, numerical method or sparse matrix are
dened. The kernel also provides a representation for solution steps, vectors, matrices, and other common parts. The
complete problem description is kept by a Domain class.
This class maintains lists of components describing the
problem under consideration Dof managers, elements,
material models, cross section models, boundary and initial
conditions, and analysis representation. If program runs in
parallel, then the Domain contains only description of a
particular partition. The class Domain provides general
services for instantiating corresponding components according to the problem description and for accessing particular
domain components.
The class DOF represents a single degree of freedom. It
maintains its physical meaning, associated equation
number, and keeps a reference to applied boundary and
initial conditions. The general services for obtaining corresponding unknowns in a given solution step are provided as
well as various services for printing and identication. The
base class Dof Manager represents an abstraction for an
entity possessing DOFs. It manages its DOF collection,
list of applied loadings and, optionally, its local coordinate
1
2

Degree of freedom.
An entity like node or element side possessing DOFs.

B. Patzak, Z. Bittnar / Advances in Engineering Software 32 (2001) 759767

system. General services include methods for gathering

localization numbers from maintained DOFs, computing
applied load vector, and computing transformation to its
local coordinate system. Derived classes typically represent
a nite element node or an element side, possessing some
DOFs.
The base abstract class Element represents a general nite
element. It declares the general, analysis independent
services. These services include methods for assembling
localization array, accessing element integration points or
nodes, and several abstract methods for set-up of integration
points, assembling element transformations or computing
characteristic components. The derived classes are assumed
to be the analysis-specic base classes, which dene the
analysis-specic part of general interface in terms of
declaring the necessary services for a particular analysis.
Generally, the services for obtaining the characteristic
components (the element contributions to governing equation) are declared. Usually, the general implementations of
these services are provided (like stiffness or mass matrix
evaluation, load vector computation) using declared abstract
services (services for evaluation of straindisplacement or
displacementinterpolation matrices), which are implemented by the terminate classes representing the particular nite
element implementations. As most of these general services
for characteristic component evaluation can be overloaded,
the efcient element specic algorithms can be implemented.
The boundary and initial condition abstractions represent
the general boundary or initial condition. The classes
derived from the base Boundary condition class may represent, for example, the loading applied to a particular component (attributes of either Dof Manager or element) or
prescribed primary unknown (attribute of DOF). The
services for evaluating the boundary condition components
at a given time are declared. The initial conditions describe
the initial state. They are usually attributes of one or more
DOFs.
In the following sections, the attention will be focused on
a more detailed description of analysis frame and material
element frame representations because of their crucial
importance in overall nite element code design.
3. Analysis frame
The analysis frame is represented by hierarchy of
abstractions representing a particular analysis (hierarchy
of classes derived from a base abstract Engng model
class) and corresponding numerical algorithms solving
the governing equations (hierarchy of classes derived
from a base abstract Numerical method class). The principal requirement of the analysis frame design is to
make the problem formulation independent of a particular numerical algorithm or even data storage. Similarly,
it is natural that numerical algorithms should be generally
formulated independent of a particular physical process

761

behind and a particular format of data storage of problem

components.
The abstractions for particular analysis types are derived
from the abstract base Engng model class. These classes
represent the underlying physical problem with its corresponding characteristic equation(s) and boundary conditions. The base class Engng model provides general
services for assembling characteristic components from
various element or Dof Manager contributions, starting
and terminating solution steps, and storing and restoring
solution state from database. The derived classes `know'
the form of governing equation(s) and the physical meaning
of the particular components. They are responsible for forming governing equation for each solution step, which may
represent the time step, load increment or load case. In order
to solve the governing equation, the particular instance of
the Engng model class should select and create a suitable
instance of the Numerical method class, map its governing
equation components to corresponding numerical method
components and request the solution from this numerical
method instance. The Numerical method class is an abstraction for numerical algorithm. Generally, the particular
instances (instances of derived classes) perform some
sequence of numerical operations on given data to obtain
the solution. The data are specied using so-called mapping.
Typically, each Engng model instance is responsible for
mapping of its governing equation components to corresponding numerical components. Such mapping allows the
numerical method implementation to be independent of a
particular physical problem by strictly dealing with numerical components, which are mapped to corresponding physical components of governing equation that are hidden to
numerical method. It should be pointed out that all numerical methods solving the same numerical problem use the
same compulsory names for the corresponding numerical
components. By using the separate mapping of each component of governing equation to compulsory numerical
method component (using compulsory names), it is possible
to use any suitable instance of the Numerical method class to
solve problem, and leave the whole engineering model code,
including mapping, unchanged because all instances of the
Numerical method class provide the common interface and
the mapping is determined using the same component
names. Similarly, a high-level numerical method instance
may use services of another low-level numerical method
instance. The Numerical method instance may also represent interface to an existing procedure written in C or
Fortran (see Fig. 2).
This concept is further enhanced by the introduction of a
base abstract Sparse matrix class, representing a matrix
stored in a sparse format, which stands for parent class for
all particular sparse matrix implementations. This class is
purely abstract; it only declares the basic, common required
services provided by all sparse matrix implementations.
Particular numerical method instances are then implemented only using the common services declared by the base

762

B. Patzak, Z. Bittnar / Advances in Engineering Software 32 (2001) 759767

Fig. 2. Engng model numerical method interface.

Sparse matrix class interface. As a consequence, the Numerical method class instances will work with any sparse matrix
class implementation, without changing any part of a particular numerical method code, because all classes derived
from Sparse matrix base class have to implement the same
interface.
To summarize, the natural independence of problem
formulation, numerical solution, and data storage format
has been obtained, which leads to the modular and the
extensible structure of the engineering modelnumerical
method frame.
3.1. Program and data ow
The program ow in the engineering modelnumerical
method frame is explained in Fig. 3, showing the example of
a nonlinear static problem analysis. After Domain reads the
input le with the problem description, it starts computation
by invoking SolveYourself service of Engng model class.
The corresponding Engng model class (here represented
by instance of NLStatic class) solves the whole problem
as a series of load increments. Therefore, for each step of
computation, a SolveYourselfAt service is invoked. For the
rst step, the reference load vector is formed from element
and nodal contributions, so these components are accessed
from corresponding domain using its services. Then, for

each solution step, the stiffness matrix is formed and particular components of the governing equation are mapped to
the numerical method components. Here, CALM instance of
Numerical Method class is being used. For the solution of a
linearized problem, the CALM uses another instance of
Numerical method class here named Linear solver.
After components are mapped and the solution is obtained,
the CALM checks convergence. It asks Engng model to
compute (update) the vector of real nodal forces according
to the solution reached, and checks convergence. If convergence criterion is reached, the program control returns to
Engng model and the solution step is then terminated (stress
updates and necessary printing) and the solution continues
with next step. If prescribed accuracy is not reached, the
stiffness matrix can be updated by suitable Engng model
service and iteration continues.
4. Materialelement frame
The materialelement frame represents denition and
description of mutual element, cross section, and constitutive model interfaces. The overall design of this frame has
been motivated by the following requests:
general, easily extensible modular design,

B. Patzak, Z. Bittnar / Advances in Engineering Software 32 (2001) 759767

763

Fig. 3. Engng model numerical method frame.

independent description and implementation of cross

section and constitutive model,
general and efcient storage scheme for constitutive
model history variables.
The following base class and objects have been introduced in the framework of this frame to meet the aforementioned requirements:
Integration point class and object is an abstraction for the
integration point of a nite element. It keeps its coordinates
and associated integration weight. Any integration point can
generally contain any number of other integration points
so-called slaves. Slaves are, for example, introduced by a
layered cross section model, where they represent integration points for each layer. They can be also introduced at a
material model level, where they may represent, for example, microplanes. The integration point has to store its
associate internal variables and, if material nonlinearity is
taken into account, the history variables related to that
integration point. Such variables, the nature of which
depends on employed constitutive model, are stored in an
associated Material status class instance.
Cross section class is an abstraction for the cross section
description. Its main role is to hide from an element all
details concerning cross section description and implementation. Particular objects representing nite elements do not
communicate directly with constitutive model, instead they
always use Cross section class interface, which performs all

necessary integration over its volume and invokes necessary

material model services. The Cross section interface,
dened in terms of general functions, allows the use of
any cross section model, without modication of any
code, because all cross section models share the same interface, which hides the implementation details of particular
model.
Material represents a base abstract class for all constitutive models. Derived classes are the base analysis-specic
classes, which declare analysis-specic part of abstract
services (as real-stress or stiffness matrix computation for
structural analysis). Again, the abstract material model
interface, dened in terms of general services, allows the
transparent use of any material model, even that added in the
future, without modifying any code, because all material
models implement the same interface.
One of the most important goals which have been formulated is the extensibility. In the case of extension of the
material library, the analyst is facing a key problem.
Every material model must store its unique history parameters for every related integration point. The amount,
type, and meaning of these history variables vary from
one material model to another. Therefore, it is not possible
to efciently match all needs and reect them in the integration point data structure. The suggested remedy uses the
associated Material status class, related to Material model
class, to store necessary history variables. Unique copy of
material model status is created and associated to every

764

B. Patzak, Z. Bittnar / Advances in Engineering Software 32 (2001) 759767

Fig. 4. Materialelement frame.

integration point by the particular constitutive model. As

integration point is the compulsory parameter of all
messages sent to the material model, that material model
can in turn access its related material status from the given
integration point, and therefore can access its history
variables.
To summarize, the described program structure supports
extension towards any material model with arbitrary history
variables, and towards any cross section model, without
modication of any part of the code.
4.1. Program and data ow and example
In Fig. 4, the materialelement frame is depicted in more
detail, although it is still simplied. The program ow,
showing an element computing its real nodal forces, is
indicated here. There is simple cross section model class
hierarchy with two derived classes from the parent Cross
section class: Simple cross section class representing an
integral cross section model and Layered cross section

model class, representing a layered cross section model

implementation. At the bottom, the hierarchies of material
model and associated material status representations are
indicated. Real nodal force computation on element level
is generally done by integrating real stresses at its integration points. For each Integration point, element asks cross
section model to compute real stresses at that integration
point. In this example, layered cross section implementation
(represented by LayeredCS class) uses the masterslave
integration point principle. Each element integration point,
here called master, contains its slaves, each representing one
layer. These slave integration points are introduced by the
cross section model, and are hidden to the element. For a
given master integration point, the cross section model
performs integration over cross section volume using slaves.
Therefore, for each slave integration point, which is
requested from the master, material model class services
are used to compute real stresses in the corresponding
layer, passing the slave integration point as a parameter.
Then for each slave, the material model asks the given

B. Patzak, Z. Bittnar / Advances in Engineering Software 32 (2001) 759767

765

Fig. 5. Example Microplane model implementation.

integration point for its associated status. Having obtained

reference to it, the material model can access all its history
variables through status services, and compute results.
As an example, Fig. 5 shows specic details concerning
implementation of a microplane model. A material interface
similar to the previous one can be seen. Again, there are
classes representing element, material, and integration
point. The general Microplane material class, which is
derived from Material model class, is the base class for all
microplane models. It denes services required by all
microplane models and implements general common
services (for example, stress homogenization). Other material model dependent services are left to be implemented by
derived classes (for example, service for computing real
microplane stresses). For convenience, a Microplane class
has been added. This class is an abstraction for microplane.
Since microplane can be generally considered as an integration point, it was natural to derive this class from the Integration point class. A few services have been added, like
returning microplane normal or its projection tensors.
Further, the implementation of the microplane model
MicroplaneModel1, which implements services declared
by the base Microplane Model class, is introduced. Together
with this class, the related MicroplaneModel1 status is
dened to store all necessary history variables. Integration
point on the macrolevel is represented by the Integration

point class. Microlevel is represented by Microplane

objects, introduced by microplane model for each master
integration point. Since Microplane is derived from the
Integration point class, it inherits its capability to contain
reference to related material status.
The sketched program ow describes the situation when
real stresses are requested from the material model. The corresponding service of general Microplane model class for stress
homogenization is invoked, again with master integration
point as a parameter (remember, integration point is a
compulsory parameter of all material model services).
Homogenization results in integration over all microplanes,
and therefore, the corresponding microplane is extracted
from the master integration point, and GiveRealMicroplaneStress service is invoked, with the corresponding
Microplane instance as a parameter. MicroplaneModel1
Table 1
Linux computational performance on 3D specimen, compared to specialized plain C source in-house code (jk3d). User times are in seconds and are
shown for code with no optimization
Mesh

nnodes/nelems

ndofs

jk3d

oofem

Ratio (jk3d/oofem)

1
2
3

3219/15849
6770/34642
12871/67277

9645
20298
38601

91
709
2141

116.55
847.85
2690

0.78
0.83
0.80

B. Patzak, Z. Bittnar / Advances in Engineering Software 32 (2001) 759767

766

Table 2
Win NT computational performance on 2D plane stress specimen,
compared to specialized plain C in-house code (jk2d). User times are in
seconds and are shown for optimized code (optimization performed by the
compiler itself)
Mesh

nnodes/nelems

ndofs

jk2d

oofem

Ratio
(jk2d/oofem)

1
2
3
4

5030/9664
10022/19476
19997/39181
40006/78855

10057
20041
39991
80009

3
12
54
210

4
15
64
241

0.75
0.80
0.84
0.87

then extracts its associated status from microplane and

computes results using its history variables from current
microplane.
5. Implementation
At the very beginning, this environment has been
designed as a tool for a new development and testing.
Nevertheless, this tool is now being intensively used as a
powerful computational tool. The C11 programming
language has been chosen due to its implementation efciency, portability, and widespread availability [21]. The
proposed general kernel structure has been successfully
implemented [17,18]. A large module for the structural
analysis has also been implemented. This module covers
usual linear and nonlinear static and dynamic problems.
Large element and material libraries are provided with
this module as well as interface to a general 3D mesh
generator. Currently, the parallelization of both explicit
and implicit parts of this module is in progress as well as
the development of a new module for coupled heat and mass
transfer analysis.
6. Computational performance
In order to compare the implementation efciency,
several linear structural analyses have been performed on
3D (see Table 1) and 2D specimens, including plane stress
(see Tables 24) and plate bending problems (see Tables 5
and 6). The results have been compared with those obtained
Table 3
Linux computational performance on 2D plane stress specimen,
compared to specialized plain C in-house code (jk2d). User times are in
seconds and are shown for optimized code (optimization performed by the
compiler itself)
Mesh

nnodes/nelems

ndofs

jk2d

oofem

Ratio
(jk2d/oofem)

1
2
3
4

5030/9664
10022/19476
19997/39181
40006/78855

10057
20041
39991
80009

2.02
6.85
37.84
141.60

3
8.17
30.74
102.20

0.67
0.83
1.23
1.38

Table 4
Linux computational performance on 2D plane stress specimen,
compared to specialized plain C in-house code (jk2d). User times are in
seconds for nonoptimized codes
Mesh

nnodes/nelems

ndofs

jk2d

oofem

Ratio
(jk2d/oofem)

1
2
3
4

5030/9664
10022/19476
19997/39181
40006/78855

10057
20041
39991
80009

3.36
12.38
56.27
240.

6.05
19.63
78.00
293.54

0.55
0.63
0.72
0.82

by available existing codes to demonstrate the overhead

associated with object oriented nature of the code. In
order to make results comparable, the use of the same
element type, sparse matrix storage scheme (skyline), and
solution algorithm (direct elimination) has been explicitly
enforced. All comparisons have been performed on DELL
PC workstation (model 610), with processor clock at
450 MHz and 512 MB memory installed, running under
Linux and Microsoft Windows NT 4.0 operating systems.
The compilers used were gcc version egcs-2.91.66
19990314 (egcs-1.1.2 release) and g77 (GNU Fortran
0.5.24-19981002) under Linux OS and Microsoft Visual
C11 6.0 under Win NT. For each package, the total user
time is reported as well as the ratio between reference code
and described code (marked as oofem). Each problem has
been analyzed several times using different meshes to show
efciency for different problem sizes. The performance loss,
compared to traditional codes in Fortran or C, is generally
caused by overhead connected with object oriented design
and implementation, and by generality of the code
compared to specialized codes. The overhead of object
oriented implementation is mainly caused by the use of
abstract classes, relying on virtual methods. The use of
virtual methods necessary leads to dynamic resolution in run
time, which is relatively time consuming compared to static
resolution done by compiler. Some overhead is also connected
with dynamic memory allocation and deallocation.
The comparisons demonstrate a comparable computational performance. Generally, computational performance
of object oriented code is lower for small problems.
However, for moderate and larger problems, performance
is increasing and approaches the performance of existing
traditional codes. This is due to efcient implementation
Table 5
Linux computational performance on 2D plate bending specimen,
compared to specialized Fortran in-house code (pl2). User times are in
seconds, shown for nonoptimized codes
Mesh

nnodes/nelems

ndofs

pl2

oofem

Ratio
(pl2/oofem)

1
2
3

5030/9664
10022/19476
19997/39181

15087
30063
59988

19.58
75.36
302.89

17.82
63.96
260.84

1.10
1.17
1.16

B. Patzak, Z. Bittnar / Advances in Engineering Software 32 (2001) 759767

767

Table 6
Linux computational performance on 2D plate bending specimen, compared to specialized Fortran in-house code (pl2). User times are in seconds, shown for
optimized codes
Mesh

nnodes/nelems

ndofs

pl2-opt

oofem-opt

Ratio
(pl2-opt/oofem-opt)

1
2
3

5030/9664
10022/19476
19997/39181

15087
30063
59988

6.86
26.83
126.22

8.22
25.35
100.2

0.83
1.06
1.26

of numerical algorithms, which is similar to the implementation in compared codes. The performance loss arises
mainly in those parts of the code that perform problem
set-up, assembly and termination of the problem, which
are necessary due to generality of the code. But the examples demonstrate that these losses are becoming less important for larger problems.
7. Conclusions
To summarize, the general object oriented environment
for nite element computations has been developed. The
described structure leads to modular and extensible code
design. Special attention has been focused on the important
aspects of materialelement and analysis frame design.
Successful implementation using C11 language veries
the designed program structure and provides a robust
computational tool for nite element modeling.
Note added in proof
In the past several years, a number of articles on applying
an object-oriented approach to nite-element analysis have
been published. In 1990 Fenves [10] described the advantages of an object-oriented approach for engineering-software development. Forde et al. [12] presented one of the
rst applications of OOP to nite elements. Many authors
presented the complete architectures of OO nite element
codes, notably, a coordinate-free approach by Miller [16], a
non-anticipation principle by Zimmermann et al. [22] and
DuboisPelerin et al. [79]. Recent contributions include
the work of Mackie [14], Archer et al. [2,3], Menetrey et al.
[15], and Yu et al. [5]
Acknowledgements
This work was supported by the Grant Agency of the
Czech Republic, Project no.: 103/97/P106. Thanks are due

to Jaroslav Kruis and Daniel Rypl from Czech Technical

University in Prague for providing their codes for performance testing.

References
[2] Archer GC. Object-oriented nite element analysis. PhD Thesis.
University of California, Berkeley, April 1996.
[3] Archer GC, Fenves G, Thewalt C. A new object-oriented nite
element analysis program architecture. Comput Struct 1999;70:63
75.
[5] Yu L, Kumar AV. An object-oriented modular framework for implementing the nite element method, Computers and Structures
2001;79:91928.
[6] Coad P, Yourdon E. Object-oriented analysis. Englewood Cliffs, NJ:
Prentice-Hall, 1991.
[7] Dubois-Pelerin Y, Zimmermann T, Bomme P. Object-oriented nite
element programming. Part II. A prototype program in Smalltalk.
Comput Meth Appl Mech Engng 1992;98(3):261397.
[8] Dubois-Pelerin Y, Zimmermann T. Object-oriented nite element
programming. Part III. An efcient implementation in C11. Comput
Meth Appl Mech Engng 1993;108:16583.
[9] Dubois-Pelerin Y, Pegon P. Object-oriented programming in
nonlinear nite element analysis. Comput Struct 1998;67:22541.
[10] Fenves GL. Object-oriented programming for engineering software
development. Engng Comput 1990;6:115.
[12] Forde BWR, Foschi RO, Stiemer SF. Object-oriented nite element
analysis. Comput Struct 1990;6:115.
[14] Mackie RI. Object-oriented programming of the nite element
method. Int J Numer Meth Engng 1992;35:42536.
[15] Menetrey P, Zimmermann T. Object-oriented non-linear nite
element analysis application to J2 plasticity. Comput Struct
1993;49:76777.
[16] Miller GR. An object-oriented approach to structural analysis and
design. Comput Struct 1991;40:7582.
[17] Patzak B. Numerical modeling of concrete structures. PhD Thesis. (in
Czech) FSv CVUT, 1996.
[18] Patzak B. OOFEM home page, http://ksm.fsv.cvut.cz/oofem/
oofem.html, 2000.
[21] Stroustrup B. The C11 programming language. 3rd ed. Reading,
MA: Addison-Wesley, 1997.
[22] Zimmermann T, Dubois-Pelerin Y, Bomme P. Object-oriented nite
element programming. Part I. Governing principles. Comput Meth
Appl Mech Engng 1992;98(3):291303.