# decreasing speed of run after some cycle

Hi everyone
I run polyhedra particles in this computer:

CPU (Cores):: xIntel(R) Xeon(TM) E5-2680 v2
20 cores 3.1 Hz
Hard disc (HDD): 150 GB ssd
Ram: 128 GB DDR 3
ubuntu : 18.04

number of bodies : 1511
size of bodies' range in x and y axises: 5cm til 1 m
z length of body is constant : 10 cm

I run it with : yade -j20 filename.py

it started with 97% of CPU and high velocity of running and continue (75 cycle in a second), after 2950000 iteration I stoped it for saving simulation until this iter and then play it but now simulating has 30% of CPU and velocity of runnig is very low (6 cycle in a second), WHY?

Thanks,
Mahdeyeh

Here is my code:

import os
import math
import pylab
import matplotlib; matplotlib.rc('axes',grid=True)
from matplotlib import pyplot
import numpy as np
from numpy import *
from yade import export as expt

RawVer=np.genfromtxt('ring.txt',names=True,dtype=None)
Ver=()
ListVer=[]
for b in RawVer:
if b[0]=='*LWPOLYLINE':
ListVer.append(Ver)
Ver=()
continue
Cordn=b[0]
Cordn=np.fromstring(Cordn, sep=',')
Cordn=tuple(Cordn.tolist())
Cordn1=Cordn+(0.1,) # add z vertex to coordinates
Cordn2=Cordn+(0.2,) # add z vertex to coordinates
if not Cordn1 in Ver:
Ver=Ver+(Cordn1,Cordn2)
ListVer.append(Ver)

RawVer1=np.genfromtxt('boundary.txt',names=True,dtype=None)
Ver1=()
ListVer1=[]
for b in RawVer1:
if b[0]=='*LWPOLYLINE':
ListVer1.append(Ver1)
Ver1=()
continue
Cordn=b[0]
Cordn=np.fromstring(Cordn, sep=',')
Cordn=tuple(Cordn.tolist())
Cordn1=Cordn+(-2,) # add z vertex to coordinates
Cordn2=Cordn+(2,) # add z vertex to coordinates
if not Cordn1 in Ver1:
Ver1=Ver1+(Cordn1,Cordn2)
ListVer1.append(Ver1)

RawVer2=np.genfromtxt('waste.txt',names=True,dtype=None)
Ver2=()
ListVer2=[]
for b in RawVer2:
if b[0]=='*LWPOLYLINE':
ListVer2.append(Ver2)
Ver2=()
continue
Cordn=b[0]
Cordn=np.fromstring(Cordn, sep=',')
Cordn=tuple(Cordn.tolist())
Cordn1=Cordn+(0.1,) # add z vertex to coordinates
Cordn2=Cordn+(0.2,) # add z vertex to coordinates
if not Cordn1 in Ver2:
Ver2=Ver2+(Cordn1,Cordn2)
ListVer2.append(Ver2)

Dolomite = PolyhedraMat()
Dolomite.density = 2870 #kg/m^3
Dolomite.young = 24.36e9 #Pa
Dolomite.poisson = 0.2

Shale = PolyhedraMat()
Shale.density = 2750 #kg/m^3
Shale.young = 6e9 #Pa
Shale.poisson = 0.23

for ii in ListVer:

for iii in ListVer1:

for iiii in ListVer2:

O.bodies.erase(340)

for b in O.bodies:
b.state.blockedDOFs='zXY'
for b in O.bodies:
b.state.blockedDOFs='zXY'

def calm():
for c in O.bodies:
c.state.vel=Vector3(0,0,0)
c.state.angVel=Vector3(0,0,0)

O.engines=[
ForceResetter(),
InsertionSortCollider([Bo1_Polyhedra_Aabb(),]),
InteractionLoop(
[Ig2_Polyhedra_Polyhedra_PolyhedraGeom(),],
[Ip2_PolyhedraMat_PolyhedraMat_PolyhedraPhys()],
[Law2_PolyhedraGeom_PolyhedraPhys_Volumetric()]
),
NewtonIntegrator(gravity=(0,-9.81,0),damping=0.2),
]

utils.calm()

O.engines=O.engines+[PyRunner(iterPeriod=20,command='calm()',label="calmRunner")]

O.dt=10e-6
O.run(50000,True)

O.run()

## Question information

Language:
English Edit question
Status:
Solved
For:
Assignee:
No assignee Edit question
Solved by:
Jan Stránský
Solved:
2020-01-16
Last query:
2020-01-16
2020-01-16
 Mahdeyeh (mahdiye.sky) said on 2019-12-24: #1

it maybe helps: always at first of run, this warning is display:

"WARN /build/yade-fDuCoe/yade-2018.02b/pkg/common/InsertionSortCollider.cpp:76 insertionSortParallel: Parallel insertion: only 16 thread(s) used. The number of bodies is probably too small for allowing more threads, or the geometry is flat. The contact detection should succeed but not all available threads are used."

After decreasing velocity, I load saved file of simulation until 2950000 and this warning is display:

 Mahdeyeh (mahdiye.sky) said on 2019-12-29: #2

Another thing: when I loaded save of 2950000 iteration and saw the image of model , I saw particles had been passed the walls, I think the error of "WARN /build/yade-fDuCoe/yade-2018.02b/pkg/dem/Polyhedra_support.cpp:370 SolveLinSys3x3: error in linear solver" is because of this, is it right? and solution of that is decreasing dt???

 Jan Stránský (honzik) said on 2020-01-06: #3

Hello,

how much interactions is at the beginning and how much at the end of your simulation?

> but now simulating has 30% of CPU

this might be because of parallelization. basically the computation is split into 20 chunks, but each might take different amount of time (especially the interactions). Already finished threads wait for the slower.

> velocity of runnig is very low

see above.
Plus there might be more interactions (including non-real interactions) than at the beginning, which makes the simulation slower just by spending more time by evaluating them.

> and solution of that is decreasing dt???

might be, you have to try

cheers
Jan

 Mahdeyeh (mahdiye.sky) said on 2020-01-09: #4

Thank you Jan

Do you have any idea for this:
> Another thing: when I loaded save of 2950000 iteration and saw the image of model , I saw particles had been passed the walls

In my model, walls are huge polyhedrons with very very little thickness (about 1 mm). why particles (other polyhedrons) passed these walls? Has this passing been effective in increasing interactions?

 Jan Stránský (honzik) said on 2020-01-09: #5

> particles had been passed the walls
> walls are huge polyhedrons with very very little thickness (about 1 mm). why particles (other polyhedrons) passed these walls?

Law2_PolyhedraGeom_PolyhedraPhys_Volumetric computes repulsive force (by default) proportional to the volume of intersection of colliding polyhedrons. If the wall has "very very little thickness", the intersection has very very little volume and the repulsive force has very very little magnitude and is not able to prevent large bodies to pass the walls.

You can use actual Wall or Facet. In that cases, the actual volume "behind" the wall or facet contributes to the force.

You can also try to artificially increase the stiffness of the thin walls, but only works to certain extent..

> Has this passing been effective in increasing interactions?

maybe yes, maybe not :-) you have to investigate yourself..

cheers
Jan

 Mahdeyeh (mahdiye.sky) said on 2020-01-15: #6

1- For all polyhedars I has used blockedDOFs in 'zXY', but while I locked particles, I saw some particles in own place rotate around Z axis and these particle have "angMom" in Z axis. why it happens?

2- To solve the above problem (question number 1), angMom and angVel all particles have set zero, but again a few particles have amount in angMom !! why??

3- Something different happens when I run this script in 2 system with similar "ubuntu : 18.04, yade 2018.02b" but different number of core"2 Cores and 16 cores":
in system with 2 cores does n`t give follow error but in system with 16 cores it shows follow error continuously:
error: "WARN /build/yade-fDuCoe/yade-2018.02b/pkg/dem/Polyhedra_support.cpp:370 SolveLinSys3x3: error in linear solver" . Why does this error occur in one system but not in the other? And What is the reason for this error?

 Jan Stránský (honzik) said on 2020-01-15: #7

1,2 - blockedDOFs lower case letters mean displacement degrees of freedom and upper case letters rotational degrees of freedom.
so "zXY" means zero z displacement and zero rotation around X and Y axes.
Rotation around Z axis is allowed.

> different number of core"2 Cores and 16 cores":

different numbers of cores leads to different results. |So in one case, the situation is such that it casues the error, while in the other situation the configuration is different.

Also consider testing a newer CGAL version [1]

cheers
Jan

 Mahdeyeh (mahdiye.sky) said on 2020-01-16: #8

Jan! you are so good , thanks a lot. You are solving my problem step by step.

Another question:

How I can solve this error:

information:

In VMware
16 cores
Ram: 32 GB
ubuntu : 18.04.3 LTS
libcgal: 4.11-2 build 1
gcc: 4:7.4.0-1 ubuntu 2.3

number of bodies : 921
size of bodies' range in X, Y axis: 15 cm til 1 m
Thickness of bodies is constant : 50 cm
The particle distribution is only along the XY axis; in other words, it is a two-dimensional model.

I run it with : yade -j16 filename.py

 Jan Stránský (honzik) said on 2020-01-16: #9

> How I can solve this error:

> Also consider testing a newer CGAL version [1]

cheers
Jan

 Mahdeyeh (mahdiye.sky) said on 2020-01-16: #10

Thanks Jan Stránský, that solved my question.

 Mahdeyeh (mahdiye.sky) said on 2020-01-16: #11

Thank you a lot Jan Stránský. you are so good.

Best regards,
Mahdeyeh