DEM Application

WARNING: This page is still under construction.

The DEM Kratos Team

Contents
[hide]

 1 Theory

o 1.1 Integration Schemes

o 1.2 Contact Laws

 1.2.1 Normal Force Laws

 1.2.1.1 Linear Repulsive Force

 1.2.1.2 Hertzian Repulsive Force

 1.2.1.3 JKR Cohesive Force

 1.2.2 Tangential Force Laws

 1.2.3 Damping Force Laws

 2 Numerical approach

o 2.1 DEM elements

 2.1.1 Spheric Particle

 2.1.2 Spheric Continuum Particle

 2.1.3 Spheric Swimming Particle

o 2.2 DEM walls (Kratos Conditions)

o 2.3 DEM Inlets

o 2.4 DEM strategies

 2.4.1 Non-cohesive materials Strategy

 2.4.1.1 Evaluation of Forces

 2.4.1.2 Rolling Friction

 2.4.2 Continuum Strategy

o 2.5 DEM schemes

 2.5.1 Integration of Motion

o 2.6 Search Strategies

 2.6.1 Global Search

 2.6.2 Local Search

 3 Programming Implementation

o 3.1 Main components of the code

  3.1.1 Elements

 3.1.2 Conditions

 3.1.3 Constitutive Laws

 3.1.4 Python elements

 3.1.5 Strategies

 3.1.6 Schemes

 3.1.7 Utilities

 3.1.8 Python scripts

 3.1.9 Test examples

 3.1.10 DEM_application

o 3.2 Main elements in the global python script

 4 Benchmarks

o 4.1 Test1: Elastic normal impact of two identical spheres

o 4.2 Test2: Elastic normal impact of a sphere against a rigid plane

o 4.3 Test3: Impact of a sphere against a rigid plane with different coefficients of restitution

o 4.4 Test4: Oblique impact of a sphere with a rigid plane with constant velocity module and variable
incident angles

o 4.5 Test5: Oblique impact of a sphere with a rigid plane with constant normal velocity and different angular
velocities

o 4.6 Test6: Impact of a sphere with a rigid plane with a constant normal velocity and variable angular
velocities

o 4.7 Test7: Impact of two identical spheres with a constant normal velocity and different angular velocities

o 4.8 Test8: Impact of two differently sized spheres with a constant normal velocity and variable angular
velocities

o 4.9 Test9: Impact of two identical spheres with a constant normal velocity and different coefficients of
restitution

 5 How to analyse using the current application

o 5.1 Pre-Process

 5.1.1 G-DEMPack

 5.1.2 C-DEMPack

 5.1.3 F-DEMPack

o 5.2 Post-Process

 6 Application Dependencies

o 6.1 Other Kratos Applications used in current Application

 7 Problems!

o 7.1 What to do if the Discrete Elements behave strangely

 8 Contact

Theory

The fundamental theoretical background corresponding to the discontinuous (granular matter) part of
the code can be found Casas et al. (2015). The following sections are destined to contain this
information though are curently still under construction.

Nothing numerical

Integration Schemes

 Symplectic Euler Scheme

 Forward Euler Scheme

 Taylor scheme

 Verlet Velocity Scheme

 Newmark Beta Method Scheme

Contact Laws
Concept of indentation HMD, LSD
Normal Force Laws
Linear Repulsive Force

The most simple representation of a repulsive contact force between a sphere and a wall is given by
a linear law, where the force acting on the sphere when contacting a plane is a linear function of the
indentation, which in turn would bring a quadratic dependence with the contact radius. The next
figure shows this simple law:
Hertzian Repulsive Force

On the other hand, Hertz solved in 1882 the non-cohesive normal contact between a sphere and a
plane. In 1971 Johnson, Kendall and Roberts presented the solution (JKR-Theory) for the same
problem in this case adding cohesive behaviour. Not much later, Derjaguin, Müller and Toporov
published similar results (DMT-Theory).

Both theories are very close and correct, the main difference being that the JKR theory is oriented to
the study of flexible, large spheres, while the DMT theory is specially suited to represent the
behaviour of rigid, small ones.

The previous figure shows the standard representation of a Linear or Hertzian contact between a
sphere and a wall. The distribution of contact pressures between both bodies follow a parabolic law.
JKR Cohesive Force
The preceding capture shows the a representation of a JKR contact between a sphere and a wall. In
this case, the distribution of pressures between both bodies is more complex due to the formation of
a neck at the boundaries of the contact. A later figure shows a detailed view of the pressures
involved.

In the previous graphic, it is very interesting to note the existence of two singular values of contact
radius: one for which the total forces acting on the contacting sphere is zero, and another for which
the maximum value of adhesion is achieved.
In the previous figure, the blue area represents the distribution of pressures acting on the sphere
when contacting a wall if a Hertzian Law is followed. On the other hand, the sum of both green and
blue areas represents the JKR distribution. Note the larger values and the existence of adhesive
behaviour at both sides of the pressures distribution.

An example of granular simulation without cohesive forces:

The same simulation as before, this time with cohesive forces in both sphere-sphere and sphere-
plane contacts.
References:

V. L. Popov. "Contact Mechanics and Friction" (2010).

G. Casas et al. "A modular, partitioned, discrete element framework for industrial grain distribution
systems with rotating machinery." Computational Particle Mechanics (2015): 1-18.
Tangential Force Laws
Damping Force Laws

(restit. coef)

Numerical approach

This section is dedicated to describe the numerical methods used to solve.

DEM elements
Spheric Particle
Spheric Continuum Particle
Spheric Swimming Particle
DEM walls (Kratos Conditions)
DEM Inlets
A DEM Inlet is a source of new DEM Elements. It is a cloud of Nodes, where each Node is the center
of a Generator Sphere. In a random order, the Nodes are chosen to create a new DEM Element
(both spherical elements or clusters) whose center coincides with the Node and the whole element is
fully included in the Generator Sphere. The newly generated DEM Element has a non-zero imposed
velocity which eventually makes the DEM Element get outside the Generator Sphere. Until this
moment, the Generator Sphere is not allowed to generate another DEM-Element. From this moment
on, the newly created DEM Element no longer has the velocity imposed, it moves freely and cannot
penetrate its Generator Sphere or any other. Actually, the Generator Sphere is seen as any other
Sphere of the domain by the DEM Element, and the contact between them is calculated as usual. In
other words, the Generator Spheres reserve the necessary space to create a new DEM
Element.

DEM strategies
Non-cohesive materials Strategy
Evaluation of Forces

Once contact between two spheres has been detected (see next figure), the forces occurring at the
contact point are computed. The interaction between the two contacting spheres can be represented
by forces Fij and Fji, which have the same module but opposite directions.

At the same time, this force Fij can be decomposed into its normal and shear components Fijn and
Fijs, respectively. The next figure shows a detailed view of this decomposition.

Fij = Fijn + Fijs = Fnnij + Fijs

The nij vector represents the unitary normal with respect to the surfaces of both particles at the
contact point. This vector lies along the line connecting the centers of the two particles and is
directed outwards from particle i.
The contact forces Fn, Fs1 and Fs2 are obtained using a constitutive model formulated for the
contact between two rigid spheres (or discs in 2D). The contact interface for the simplest formulation
is characterized by the normal and tangential stiffness Kn and Ks, respectively, a frictional device
obeying the Couloumb law with a frictional coefficient mu, and a dashpot defined by the contact
damping coefficient cn as shown in the next figure.

Rolling Friction

In order to represent irregular particles with spheres, a numerical correction is used. This correction
is the rolling friction which is about imposing a virtual moment opposite to particle rotation and
dependent on its size.

Fn represents the normal force, Ft the tangential force, ω the angular velocity, r is the radius and η
the rolling friction coefficient.

In our approach there are two importatn conditions that have to be fulfilled:

1. The moment due to rolling friction can not change the direction of the particle spin.
2. If the contact occurs between two spheres the rolling friction is calculated with the radius of the
smallest spheres.

The model used is described in the following article: J. Irazábal, F. Salazar, E. Oñate. Numerical
modelling of granular materials with spherical discrete particles and the bounded rolling friction
model. Application to railway ballast. Computers and Geotechnics 85 (2017) 220–229.
Continuum Strategy
DEM schemes
Integration of Motion

The standard translational and rotational equations for the motion of rigid bodies are used to
compute the dynamics of the spheres. For the i-th particle we have:

miui = Fi Ii i = Ti

where u represents the element centroid displacement in a xed (inertial) coordinate frame X, ! the
angular velocity, m the element mass, I the moment of inertia, Fi the resultant force, and Ti the total
moment arount the central axes.

Vectors Fi and Ti are the sum of all forces and moments applied to the i-th particle due to external
loads, Fexti and Texti , respectively, the contact interactions with neighbour spheres Fc i, j = 1;; nc,
where nci is the total number of elements in contact with the i-th discrete element, and the forces and
moments resulting from external damping, Fdampi and Tdampi , respectively, which can be written
as:

Fi = Fexti +nciXj=1Fci + Fdampi

Ti = Texti +nciXj=1(rci Fci + qci ) + Tdampi

where rci is the vector connecting the centre of mass of the i th particle with the contact point c (see
next figure) and qci are the torques due to rolling and/or torsion (not related to the tangential forces).
The next figure shows the motion of a rigid particle. Note that the form of the rotational equation is
only valid for spheres and cylinders (in 2D). It is simplified with respect to a general form for an
arbitrary rigid body with the rotational inertial properties represented by a second order tensor. In the
general case it is more convenient to describe the rotational motion with respect to a co-rotational
frame x which is embedded at each element since in this frame the tensor of inertia is constant.

The previous set of equations are integrated in time using a simple central difference scheme. The
time integration operator for the translational motion at the n-th time step is as follows:

The first two steps in the integration scheme for the rotational motion are identical to those given by
the previous equations:

On the other hand, the vector of incremental rotation is computed as

Knowledge of the incremental rotation is enough to update the tangential contact forces. It is also
possible to track the rotational position of particles when necessary. If that is the case, the rotation
matrices between the moving frames embedded in the particles and the fixed global frame must be
updated incrementally by using an adequate multiplicative scheme. Explicit integration in time yields
high computational efficiency and it enables the solution of large models. The main disadvantage of
this explicit integration scheme is its conditional numerical stability which imposes a limitation on the
time step delta_t.

Search Strategies
The contact search is a very important part of the method in terms of computational cost (range 60%-
90% of simulation time in simulations with large number of particles) and it is possibly the most
difficult part to treat when dealing with particles that have no spherical/circular shape.

The contact detection basically consists in determining, for every target object, what other objects are
in contact with, and then, judge for the correspondent interaction. It is usually not needed to perform
a search every time step, which is generally limited for the stability of the explicit integration of the
equations of motion. Due to the fact that the search is an expensive step a lower search frequency
can be selected without much loss of accuracy.

The most naïve method of search that can be set is the brute search; for every element, the method
does a loop for any other element checking for the contact. The order of the number of operations
needed is quadratic: n2. Normally, the strategy to avoid such an expensive scheme is to divide the
contact search in two basic stages, a global search and a subsequent local resolution of the contact;
in this case the computation time of the contact search is proportional to n log n. In the
DEMApplication a Grid/Cell based algorithm is used in this purpose.
Global Search

In a generic way, there are two types of elements: searcher elements (particles or finite elements)
and target elements (particles or finite elements). Hereafter searcher elements will be called S.E. and
target elements T.E.

The steps needed to perform contact search are:

a) Build bounding box of S.E. (Figure 2(a)).

b) Build bins cells based on size and position of S.E. (Figure 2(b)).

c) Collocate S.E. in bins and construct hash table with relates coordinates with cells which point to
the contacting S.E. (Figure 2(c)).

d) Build bounding box of T.E. (Figure 2(d)).

e) Loop over T.E., detect the intersecting cells to each T.E., check the intersection with the possible
found cells and add the entire S.E. contained in the cells intersected by each T.E. (Figure 2(e)).

f) Solve the contact with local resolution (Figure 2(f)).

Note: In the case of FE and DE the FE are selected as the S.E. to construct the Bins and the
Spheres are T.E. to be found in that bins.

Local Search

Once the possible neighbours are detected, the local resolution check takes place. For the case of
two spherical particles, the check is easy; only the sum of the radius has to be compared against the
distance between centres. Other geometries may demand a much complicated check. The followed
strategy is to mesh all the geometries with a discretization of triangles. In 3D, surface meshes are
used for contact detection. Now, the contact detection should be performed between particles and
triangles; if no contact is found, particle contact against lines is searched for; and if contact is still not
found, contact against points is performed. Figure 3 shows how the local search is performed.
Particle i searches contact against element j, then against lines k, l and m and finally against points
n, o and p.

This is known as a hierarchical algorithm. For further explanation please refer to the paper: "3D
contact algorithms for particle DEM with rigid and deformable solids" - M.Santasusana, J.Irazábal,
E.Oñate, J.M.Carbonell. Where the advantges and the drawback of this method and other proposed
algorithms are detailed and analysed in complicated situations like multicontact.
Fig. 3 Particle-Face contact detection.

Programming Implementation

Structure of the code (Strategy, Scheme, Element, Node, Utilities, functions frequently used like
FastGet,...)

The source code is accessible through this site.

A main Python script is used to trigger the calculation of a problem. It communicates with the C++
code. The main advantage of using a compiled language like python for the main script is that it
allows to make quick adjustments or modifications to the main strategy without having to recompile
the whole code avery time. It also allows for very fast testing.

Main components of the code

Elements

Discontinuum, continuum, cohesive, swimming, cluster of spheres.

Conditions

Main the FEM elements: lines and triangles.

Constitutive Laws

Different interactions laws: linear, Hertzian and continuum behaviour.

Python elements

These files translate the strategies and the utilities defined in C++ language to be able to call them
from python scripts.
Strategies

The main script that calls the necessary schemes and the functions on the elements during the
global loop.
Schemes

Explicit integration schemes available

Utilities

Here geometric functions are defined, the neighbours search function, configuration of the particle,
amongst others.
Python scripts

It contains, amongst other things, the python interface where the main function of the strategy such
as Initialize or Solve are called. Other operations are done like adding the necessary nodal variables.
Test examples

They contain the Benchmarks

DEM_application

It contains all the variables that will be used so they are created and registered in python and C++.

Main elements in the global python script

The first step consist of importing all libraries and files necessary for the application. It is followed by
the creation of the necessary input files of the problem at hand to be processed by the code. The
solver strategy is also chosen, and some important operations are done, as for example the addition
of the necessary variables to the solver.
At this step the buffer size value is also set: this number determines the historical database size of
the problem. The values for the different options and variables that Kratos will use in the computation
are also imported here, like the integration scheme, the type of solution, damping specifications, time
step, output time step of results, et cetera.

After the definition of the previous settings, several initializing functions are called which are
responsible of initializing, among other objects, the mesh, the inlet of particles or the solver. Also
some operations related to parallel computing are done.

Afterwards the time step is determined and the main computing loop is entered. At each time step
Solve function is executed. Finally, at user-defined time steps the results are exported to GiD so they
become ready for visualization and postprocessing.

In fact, this main python file imports another script written in the same language,
the sphere_strategy.py. This file is very important because it contains the core structure that the
program will follow when computing. On the other hand, it is the last door to the kernel of the
program, which is written in C++. Some of the most important functions and classes in this file are
the following:

AddVariables: This function sets which variables will be stored in the nodes at each time step and
also the value of those variables as a function of time also depending on the buffer size previously
selected. See the next figure for details.

AddDofs: The desired degrees of freedom are set here, as can be seen in the design of the function
in the figure that follows.

The global structure of the explicit strategy the code uses is shown in the next figure. It consists of
three main parts: a constructor of the class of the solver, which creates some default variables for the
class, an initializer, which defines the values of several standard parameters, and finally,
the Solve() function which takes command of almost the entire computing process. The next figure
shows and schematic view of this structure.

When using the Initialize() function to set the original values of a group of variables, they
automatically become accessible in the different C++ files of the application by means of the
ProcessInfo container (see more at ). This function also calls the Initialize function in the solver.

C++ Solve() function scheme:

DEM CONTINUUM

Initialize() function scheme:

Solve() function scheme:
Search() function scheme:

Benchmarks

The DEM Benchmarks consist of a set of 9 simple tests which are run every night and whose object
is to make sure both that the application performs correctly and that the code did not break after the
daily changes. They are the following:

Test1: Elastic normal impact of two identical spheres

Check the evolution of the elastic normal contact force between two spheres with time.
If the coefficient of restitution is 1, the module of the initial and final velocities should be the same.
Also, by symmetry, velocities should be equal for both spheres.

Test2: Elastic normal impact of a sphere against a rigid plane

Check the evolution of the elastic normal contact force between a sphere and a plane.
If the coefficient of restitution is equal to 1, the module of the initial and final velocity should remain
unchanged.

Test3: Impact of a sphere against a rigid plane with different

coefficients of restitution
Check the effect of different restitution coefficients on the damping ratio.
If total energy is conserved, the restitution coefficient and the damping ratio values should be
identical.

Test4: Oblique impact of a sphere with a rigid plane with constant

velocity module and variable incident angles
Check the tangential restitution coefficient, final angular velocity and rebound angle of the sphere.
_
Test5: Oblique impact of a sphere with a rigid plane with constant
normal velocity and different angular velocities
Check the final linear and angular velocities of the sphere.

Test6: Impact of a sphere with a rigid plane with a constant normal

velocity and variable angular velocities
Check the final linear and angular velocities of the sphere.
_

Test7: Impact of two identical spheres with a constant normal velocity

and different angular velocities
Check the final linear and angular velocities of both spheres.
By symmetry, the tangential final velocity of both spheres should be zero. Additionally, for a
coefficient of restitution of 1, there should be no changes in the modules of both linear and angular
velocities and their values should conserve symmetry.

Test8: Impact of two differently sized spheres with a constant normal

velocity and variable angular velocities
Check the final linear and angular velocities of both spheres.
In this case, it is interesting to note that, the bigger and/or denser sphere 2 is, the more this test
resembles the sphere versus plane simulation.

Test9: Impact of two identical spheres with a constant normal velocity

and different coefficients of restitution
Check the effect of different restitution coefficients on the damping ratio.
If total energy is conserved, the restitution coefficient and the damping ratio values should be
identical.

References:

Y.C.Chung, J.Y.Ooi. Benchmark tests for verifying discrete element modelling codes at particle
impact level (2011).

How to analyse using the current application

Pre-Process
GUI's & GiD
G-DEMPack

G-DEMPack is the package that allows a user to create, run and analyze results of a DEM simulation
for discontinuum / granular / little-cohesive materials. It is written for GiD. So in order to use this
package, you should install GiD first.

You can read the D-DEMPack manual or follow the D-DEMPack Tutorials included in DEMPack
Tutorials for fast learning on how to use the GUI.
C-DEMPack
C-DEMPack combines the features of D-DEMPack with the simulation of continuum/cohesive
materials. Refer to the C-DEMPack2 manual or follow the C-DEMPack Tutorials included
in DEMPack Tutorialsfor more information.
F-DEMPack

F-DEMPack allows you to simulate a wide spectrum of problems involving the interaction of
discontinuum DEM and fluid. It also needs GiD to work. The user is advised to take a look at F-
DEMPack2 manualand follow the C-DEMPack Tutorials included in DEMPack Tutorials in order to
get a quick idea of how this program works.

Post-Process
Application Dependencies

The Swimming DEM Application depends on the DEM application

Other Kratos Applications used in current Application

FEM-DEM

Problems!
What to do if the Discrete Elements behave strangely

In the case you notice that some discrete elements cross walls, penetrate in them or simply fly away
of the domain at high velocity, check the following points:

In the case of excessive penetration:

 Check that the Young Modulus is big enough. A small Young Modulus makes the Elements
and the walls behave in a very smooth way. Sometimes they are so soft that total penetration
and trespass is possible.

 Check the Density of the material. An excessive density means a big weight and inertia that
cannot be stopped by the walls.

 Check the Time Step. If the time step is too big, the Elements can go from one side of the wall
to the other with no appearence of a reaction.

 Check the frequency of neighbour search. If the search is not done frequently enough, the
new contacts with the walls may not be detected soon enough.

In the case of excessive bounce:

 Check that the Young Modulus is not extremely big. An exaggerated Young Modulus yields
extremely large reactions that can make the Elements bounce too fast in just one time step. Also
 take into account that the stability of explicit methods depends on the Young Modulus (the higher
the modulus, the closer to instability).

 Check the Density of the material. A very low density means a very small weight and inertia,
so any force exerted by other elements or the walls can induce big accelerations on the element.

 Check the Time Step. If the time step is too big, the method gains more energy, and gets closer
to instability.

 Check the restitution coefficient of the material. Explicit integration schemes gain energy
noticeably, unless you use a really small time step. In case the time step is chosen to be big (but
still stable), use the restitution coefficient to compensate the gain of energy and get more
realistic results.
Contact

Contact us for any question regarding this application:

-Miguel Angel Celigueta: [email protected]

-Guillermo Casas: [email protected]

-Salva Latorre: [email protected]

-Ferran Arrufat: [email protected]