yade-dev team mailing list archive
-
yade-dev team
-
Mailing list archive
-
Message #01053
PersistentSAPCollider leaks??
-
To:
Yade Development Group <yade-dev@xxxxxxxxxxxxxxxxxxx>
-
From:
Václav Šmilauer <eudoxos@xxxxxxxx>
-
Date:
Fri, 27 Feb 2009 14:16:17 +0100
-
User-agent:
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.19) Gecko/20090105 Lightning/0.8 Thunderbird/2.0.0.19 Mnenhy/0.7.6.666
Hi,
I was sort-of profiling PersistentSAPCollider, which is notorious for
taking forever during the first iteration. The reason is in the function
updateIds, which calls findOverlappingBB for x,y,z, which makes up over
90% of the lag at the start.
I wanted to measure exactly how much time is used for how many elements.
The largest set I dared (the complexity is something like O(n^2), since
findOverlappingBB has two nested while loops over bodies) was 64k
spheres, running just the very first iteration with only the collider as
engine.
After about 7 minutes of running, the process starts taking more and
more memory (now it has 15GB) and doesn't seem to stop. You can try
yourself with the script below.
Vaclav.
---
# generate random packing, save it to file
nSpheres=64000
p=Preprocessor('TriaxialTest',{'numberOfGrains':nSpheres,'radiusMean':1e-3,'lowerCorner':[0,0,0],'upperCorner':[1,1,1]})
p.load()
import os
tmp='/tmp/spheres%d'%(os.getpid())
utils.spheresToFile(tmp)
# load the packing into clean simulation again
O.reset()
utils.spheresFromFile(tmp)
from yade import timing
O.timingEnabled=True
print "Spheres loaded"
O.engines=[StandAloneEngine('PersistentSAPCollider'),]
O.step()
timing.stats()
quit()
Follow ups