erase particles(segmentation fault)

Asked by azim

Dear all,
I am building a simple model. I tried to delete some particles in a way suggested in [1]:

[1] https://answers.launchpad.net/yade/+question/211937

particles are deleted without any problem. but after running even 1 iteration,O.run(1,1), yade shows this:
Segmentation fault (core dumped)
my script is as below:

 # -*- coding: utf-8 -*-
from yade import pack, plot
young=1e8
compFricDegree = 5
finalFricDegree = 35
mn,mx=Vector3(0,0,0),Vector3(.005,.005,.005)

O.materials.append(FrictMat(young=young,poisson=0.5,frictionAngle=radians(compFricDegree),density=2600,label='spheres'))
O.materials.append(FrictMat(young=young,poisson=0.5,frictionAngle=0,density=0,label='walls'))
walls=aabbWalls([mn,mx],thickness=0,material='walls')
wallIds=O.bodies.append(walls)
psdSizes=[.00001,.00006,.00008,.0002,.0004,.0005,.0008,.001]
psdCumm=[0,.0175,.025,.4,.5,.7,.85,1]
sp=pack.SpherePack()
sp.makeCloud(mn,mx,psdSizes=psdSizes,psdCumm=psdCumm,distributeMass=True,num=500)
sp.toSimulation(material='spheres')
triax=TriaxialStressController(
 maxMultiplier=1.001,
 finalMaxMultiplier=1.00001,
 thickness = 0,
 stressMask = 7,
 internalCompaction=True,
)

newton=NewtonIntegrator(damping=0.2)
O.engines=[
 ForceResetter(),
 InsertionSortCollider([Bo1_Sphere_Aabb(),Bo1_Box_Aabb()]),
 InteractionLoop(
  [Ig2_Sphere_Sphere_ScGeom(),Ig2_Box_Sphere_ScGeom()],
  [Ip2_FrictMat_FrictMat_FrictPhys()],
  [Law2_ScGeom_FrictPhys_CundallStrack()],label="iloop"
 ),
 triax,
 newton,
]
O.dt=PWaveTimeStep()
triax.goal1=triax.goal2=triax.goal3=-10000

while 1:
  O.run(1000,True)
  unb=unbalancedForce()
  print 'porosity', triax.porosity
  if unb<0.01 and abs(-10000-triax.meanStress)/10000<.01:
    break

bodiesToBeDeleted=[]
for b in O.bodies:
 if b.id in range(6):
  continue
 else:
  if b.state.pos[0]<.0023:
   bodiesToBeDeleted.append(b)

for b in bodiesToBeDeleted:
 O.bodies.erase(b.id)

can any one tell me about what is happening??
any help is appreciated id advance
i am using ubuntu 14.04 and yade version is: 2018.02b-85-f861843~trusty

Question information

Language:
English Edit question
Status:
Solved
For:
Yade Edit question
Assignee:
No assignee Edit question
Solved by:
Jérôme Duriez
Solved:
Last query:
Last reply:
Revision history for this message
Jan Stránský (honzik) said :
#1

Hello,
I **guess** TriaxialStressController [1] does not like deleted bodies.. There are a few places where the existance of the body is not tested and could segfault..
What is the output of
catchsegv yade yourScript.py
?
cheers
Jan

[1] https://github.com/yade/trunk/blob/master/pkg/dem/TriaxialStressController.cpp

Revision history for this message
azim (mirzavand) said :
#2

Hi Jan,
thanks for your reply.
>>catchsegv yade yourScript.py

the result is so weired. It consists of a lot of obscure lines. a little part of the results are here[1]
 My script is as mentioned above,please run the script and watch the results of: catchsegv yade yourScript.py.

[1]7f342a07b000-7f342a081000 r--s 00000000 08:08 1705938 /var/cache/fontconfig/2cd17615ca594fa2959ae173292e504c-le64.cache-4
7f342a081000-7f342a088000 r--s 00000000 08:08 1705784 /var/cache/fontconfig/a755afe4a08bf5b97852ceb7400b47bc-le64.cache-4
7f342a088000-7f342a09c000 r--s 00000000 08:08 1705781 /var/cache/fontconfig/04aabc0a78ac019cf9454389977116d2-le64.cache-4
7f342a09c000-7f342a0a0000 r--s 00000000 08:08 1705775 /var/cache/fontconfig/385c0604a188198f04d133e54aba7fe7-le64.cache-4
7f342a0a0000-7f342a0a5000 r--s 00000000 08:08 1705595 /var/cache/fontconfig/8801497958630a81b71ace7c5f9b32a8-le64.cache-4
7f342a0a5000-7f342a165000 rw-p 00000000 00:00 0
7f342a165000-7f342a166000 r--s 00000000 08:08 1705937 /var/cache/fontconfig/e7071f4a29fa870f4323321c154eba04-le64.cache-4
7f342a166000-7f342a167000 r--s 00000000 08:08 1705932 /var/cache/fontconfig/0d8c3b2ac0904cb8a57a757ad11a4a08-le64.cache-4
7f342a167000-7f342a168000 r--s 00000000 08:08 1705776 /var/cache/fontconfig/1ac9eb803944fde146138c791f5cc56a-le64.cache-4
7f342a168000-7f342a169000 r--s 00000000 08:08 1705770 /var/cache/fontconfig/dc05db6664285cc2f12bf69c139ae4c3-le64.cache-4
7f342a169000-7f342a16d000 r--s 00000000 08:08 1713837 /var/cache/fontconfig/c57959a16110560c8d0fcea73374aeeb-le64.cache-4
7f342a16d000-7f342a174000 r--s 00000000 08:08 1705554 /var/cache/fontconfig/3047814df9a2f067bd2d96a2b9c36e5a-le64.cache-4
7f342a174000-7f342a17a000 r--s 00000000 08:08 1705519 /var/cache/fontconfig/b47c4e1ecd0709278f4910c18777a504-le64.cache-4
7f342a17a000-7f342a18d000 r--s 00000000 08:08 1705444 /var/cache/fontconfig/d52a8644073d54c13679302ca1180695-le64.cache-4
7f342a18d000-7f342a196000 r--s 00000000 08:08 1705274 /var/cache/fontconfig/3f7329c5293ffd510edef78f73874cfd-le64.cache-4
7f342a196000-7f342a25b000 rw-p 00000000 00:00 0
7f342a25b000-7f342a25d000 r--s 00000000 08:08 1705217 /var/cache/fontconfig/767a8244fc0220cfb567a839d0392e0b-le64.cache-4
7f342a25d000-7f342a25e000 r--s 00000000 08:08 1721233 /var/cache/fontconfig/4794a0821666d79190d59a36cb4f44b5-le64.cache-4
7f342a25e000-7f342a262000 r--s 00000000 08:08 1705239 /var/cache/fontconfig/d589a48862398ed80a3d6066f4f56f4c-le64.cache-4
7f342a262000-7f342a265000 r--s 00000000 08:08 1704032 /var/cache/fontconfig/e13b20fdb08344e0e664864cc2ede53d-le64.cache-4
7f342a265000-7f342a269000 r--s 00000000 08:08 1713858 /var/cache/fontconfig/7ef2298fde41cc6eeb7af42e48b7d293-le64.cache-4
7f342a269000-7f342a270000 r--s 00000000 08:08 4466981 /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache
7f342a270000-7f342a271000 rw-p 00000000 00:00 0
7f342a271000-7f342a272000 r--s 00000000 08:08 1705525 /var/cache/fontconfig/56cf4f4769d0f4abc89a4895d7bd3ae1-le64.cache-4
7f342a272000-7f342a273000 r--s 00000000 08:08 1705520 /var/cache/fontconfig/b9d506c9ac06c20b433354fa67a72993-le64.cache-4
7f342a273000-7f342a274000 rwxp 00000000 00:00 0
7f342a274000-7f342a275000 r--s 00000000 08:08 1705225 /var/cache/fontconfig/0c9eb80ebd1c36541ebe2852d3bb0c49-le64.cache-4
7f342a275000-7f342a277000 rw-p 00000000 00:00 0
7f342a277000-7f342a278000 r--p 00022000 08:08 5374864 /lib/x86_64-linux-gnu/ld-2.19.so
7f342a278000-7f342a279000 rw-p 00023000 08:08 5374864 /lib/x86_64-linux-gnu/ld-2.19.so
7f342a279000-7f342a27a000 rw-p 00000000 00:00 0
7ffde9d01000-7ffde9d22000 rw-p 00000000 00:00 0 [stack]
7ffde9d97000-7ffde9d9a000 r--p 00000000 00:00 0 [vvar]
7ffde9d9a000-7ffde9d9c000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]

thanks Jan

Azim

Revision history for this message
Jan Stránský (honzik) said :
#3

Hi Azim,

the important part of the output is:

Backtrace:
/home/honzik/lib/x86_64-linux-gnu/yade-2017.01a/libyade.so(_ZN4Shop13growParticlesEdbb+0x188)[0x7ff0c3fb7368]
/home/honzik/lib/x86_64-linux-gnu/yade-2017.01a/libyade.so(_ZN24TriaxialStressController6actionEv+0x60e)[0x7ff0c41626be]

meaning that the problem is really TriaxialStressController, calling growParticles [1] where the existence of Body is not tested in the for loops. Please report a bug if you want to have it corrected.

cheers
Jan

[1] https://github.com/yade/trunk/blob/master/pkg/dem/Shop_02.cpp#L819

Revision history for this message
azim (mirzavand) said :
#4

Hi Jan,
I will do as you said.
thanks
Azim

Revision history for this message
azim (mirzavand) said :
#5

Hi jan,
I reported a bug as you suggested.
I have no idea about what may happen to a bug report or the hierarchy for fixing it.
So:
is there any stable version that can install and complete my simulation without this error?
or I do have to wait!!!?
thanks
azim

Revision history for this message
Jan Stránský (honzik) said :
#6

No version (stable or unstable) can do it, sorry.. I do not have time to do it myself, you can try to urge in the bug thread or try to implement it yourself..
cheers
Jan

Revision history for this message
Jan Stránský (honzik) said :
#7

Sorry, I just read the bug afterwards, according to Jerome, it seems that with newer versions it is ok.. I have only "old" yade versions installed..
Jan

Revision history for this message
azim (mirzavand) said :
#8

Hi jan,
>>.......try to implement it yourself..
where is the starting point, if I want to do it myself??
thanks

Revision history for this message
Jérôme Duriez (jduriez) said :
#9

Should be fixed now, see the bug report.

Thanks for reporting,

Jerome

Revision history for this message
azim (mirzavand) said :
#10

Hi Jerome and Jan
thank you both dears.
I appreciate your help.

Revision history for this message
Bruno Chareyre (bruno-chareyre) said :
#11

Hi Azim,
A bug report is to document and keep record of a problem. It favors efficient development but it is not a solution in itself and it does not mean someone will urgently try and fix it.
Bruno

Revision history for this message
azim (mirzavand) said :
#12

Hi Bruno
Thanks for the point.

Revision history for this message
azim (mirzavand) said :
#13

Hi
thanks to Jérôme the problem of erasing particles is solved.
now:
 1) why len(O.bodies) is the same as before?
I don't want Yade to reproduce erased particles(I think I should set triax.internalCompaction=False), and beside I want only one of walls to participate in compaction and others remain on their positions.
2) how can I apply wall positions mentioned above?
thanks
Azim

Revision history for this message
Best Jérôme Duriez (jduriez) said :
#14

Hi Azim,

As usual, please open new Launchpad questions for new questions.

As you said, the segmentation fault issue with erased particles is solved, hence please keep this "erase particles(segmentation fault)" Launchpad question as solved.

PS: your last question 1) has already been discussed in https://answers.launchpad.net/yade/+question/660861
PPS: https://yade-dem.org/wiki/Howtoask ;-)

Revision history for this message
azim (mirzavand) said :
#15

Hi Jerome
I will follow as you recommend.
thanks.
Azim

Revision history for this message
azim (mirzavand) said :
#16

Thanks Jérôme Duriez, that solved my question.