DEM Application
WARNING: This page is still under construction.
The DEM Kratos Team
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
Forward Euler 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 model A described in the following article: C.M. Wensrich, A. Katterfeld. Rolling friction as a technique for modelling particle shape in DEM. Powder Technology 217 (2012) 409–417.
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
D-DEMPack
D-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 for fast learning on how to use the GUI.
C-DEMPack
Continuum / Cohesive
F-DEMPack
Fluid coupling
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: maceli@cimne.upc.edu
-Guillermo Casas: gcasas@cimne.upc.edu
-Salva Latorre: latorre@cimne.upc.edu
-Miquel Santasusana: msantasusana@cimne.upc.edu
-Ferran Arrufat: farrufat@cimne.upc.edu
