Re: [Yade-dev] [Yade-users] Optimized contact detection available
> the bottleneck is SpheresFactory which is working with new version > incorrectly and > cannot find places for new bodies. I think I see the problem. Since you are using bounding boxes for finding places, you have problems with the default Verlet distance (0.7 * mean_radius). Your algorithm is searching place for bodies larger than what they actually are. Setting a small verlet distance should fix the problem, but then you will get less speedup from the new algorithm. This is actually a problem on the sphere factory side. Using the collider for placement is not very consistent because the role of the collider is to tell what is "in the neighborhood of", not "what body is overlapping with" (it was the same in the previous logic, but since verletDist was smaller, the difference was less sensible). Checking real overlaps between bodies is the role of Ig2 functors. It is maybe possible to give a modified version of the "probe" function that would account for the verletDist, let me think. Bruno ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] [Yade-users] Optimized contact detection available
On 26/01/12 10:49, Bruno Chareyre wrote:
>> the bottleneck is SpheresFactory which is working with new version
>> incorrectly and
>> cannot find places for new bodies.
> I think I see the problem. Since you are using bounding boxes for
> finding places, you have problems with the default Verlet distance (0.7
> * mean_radius).
> Your algorithm is searching place for bodies larger than what they
> actually are. Setting a small verlet distance should fix the problem,
> but then you will get less speedup from the new algorithm.
> This is actually a problem on the sphere factory side. Using the
> collider for placement is not very consistent because the role of the
> collider is to tell what is "in the neighborhood of", not "what body is
> overlapping with" (it was the same in the previous logic, but since
> verletDist was smaller, the difference was less sensible). Checking real
> overlaps between bodies is the role of Ig2 functors.
> It is maybe possible to give a modified version of the "probe" function
> that would account for the verletDist, let me think.
>
>
Here is a correct way to fix the problem on sphere factory's side, using
Ig2 functor to check overlaps (found in ResetRandomPosition.cpp:101
from Sergei):
// Test overlap with other bodies
vector probedBodies=bI->probeBoundingVolume(bv);
FOREACH(Body::id_t id, probedBodies){
if
(iGME->explicitAction(b,Body::byId(id),/*force*/false)->geom){
is_overlap=true;
break;
}
}
if (is_overlap) continue; // new attempt
break;
It seems to me it can also be partly fixed in the probe function, by
substracting sweepLength in the bounds comparison. I can try that if I
have an example script. But still, it will fail to place spheres when
corners of the bounding boxes are overlapping, even if the sphere are
not actually overlapping.
B
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] [Yade-users] Optimized contact detection available
Ok, I have got a "segmentation fault". Will try to prepare a simple test-script. Anton On Thu, Jan 26, 2012 at 12:22 PM, Bruno Chareyre wrote: > Could you please try bzr3006? > > B >>> I have tried one of my working scripts and the results are not good. >>> The new version is dramatically slower. Not sure what is the reason, >>> but it seems >>> the bottleneck is SpheresFactory which is working with new version >>> incorrectly and >>> cannot find places for new bodies. >>> >>> Bruno, is there an opportunity to use both algorithms: old and new one? >>> >> It is very difficult to keep both logics Anton, it would combine >> disadvantages from each side. I should understand what the problem is in >> SpheresFactory and fix it. Since I didn't touch this code, I'm really >> curious about the problem. Are you doing operations in SpheresFactory at >> runtime? >> Could you send an example script? >> >> Bruno >> >> >> >> ___ >> Mailing list: https://launchpad.net/~yade-users >> Post to : yade-us...@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~yade-users >> More help : https://help.launchpad.net/ListHelp >> > > > -- > ___ > Bruno Chareyre > Associate Professor > ENSE³ - Grenoble INP > 11, rue des Mathématiques > BP 46 > 38402 St Martin d'Hères, France > Tél : +33 4 56 52 86 21 > Fax : +33 4 76 82 70 43 > > > > ___ > Mailing list: https://launchpad.net/~yade-users > Post to : yade-us...@lists.launchpad.net > Unsubscribe : https://launchpad.net/~yade-users > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] [Yade-users] Optimized contact detection available
Hi, Bruno,
I have prepared a small test-script from "examples/packs.py". It is
similar to one, which is crashes in my case,I could not "catch" a
crash with this test-script, but it seems, BoxFactory creates new
spheres not in the right places:some of particles are "jumping", it
can be caused by the initial overlapping.
Anton
On Fri, Jan 27, 2012 at 7:43 AM, Anton Gladky wrote:
> Ok, I have got a "segmentation fault".
>
> Will try to prepare a simple test-script.
>
> Anton
>
>
>
> On Thu, Jan 26, 2012 at 12:22 PM, Bruno Chareyre
> wrote:
>> Could you please try bzr3006?
>>
>> B
I have tried one of my working scripts and the results are not good.
The new version is dramatically slower. Not sure what is the reason,
but it seems
the bottleneck is SpheresFactory which is working with new version
incorrectly and
cannot find places for new bodies.
Bruno, is there an opportunity to use both algorithms: old and new one?
>>> It is very difficult to keep both logics Anton, it would combine
>>> disadvantages from each side. I should understand what the problem is in
>>> SpheresFactory and fix it. Since I didn't touch this code, I'm really
>>> curious about the problem. Are you doing operations in SpheresFactory at
>>> runtime?
>>> Could you send an example script?
>>>
>>> Bruno
>>>
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~yade-users
>>> Post to : yade-us...@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~yade-users
>>> More help : https://help.launchpad.net/ListHelp
>>>
>>
>>
>> --
>> ___
>> Bruno Chareyre
>> Associate Professor
>> ENSE³ - Grenoble INP
>> 11, rue des Mathématiques
>> BP 46
>> 38402 St Martin d'Hères, France
>> Tél : +33 4 56 52 86 21
>> Fax : +33 4 76 82 70 43
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~yade-users
>> Post to : yade-us...@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~yade-users
>> More help : https://help.launchpad.net/ListHelp
#!/usr/bin/python
# -*- coding: utf-8 -*-
from yade import pack,ymport,export,log,geom,bodiesHandling
import math
""" This script demonstrates how to use 2 components of creating packings:
1. packing generators pack.regularHexa, pack.regularOrtho etc. generate vertices and filter them
using predicates. (Note that this will be enhanced to irregular packings in the future)
2. predicates are functors returning True/False for points that are given by the packing generator.
Their names are mostly self-explanatory, see their docstrings for meaning of their arguments.
Predicates can be combined using set arithmetics to get their Intersection (p1 & p2), union (p1 | p2),
difference (p1 - p2) and symmetric difference (XOR, p1 ^ p2). This is demontrated on the head (which
has sphere taken off at the back and also a notch) and the body (with cylidrical hole inside).
"""
rad,gap=.15,.02
#Add material
O.materials.append(FrictMat(young=10e9,poisson=.25,frictionAngle=0.5,density=1e3))
#Parameters, which will be passed into spheres and facets creators
kw={'material':0}
kwBoxes={'color':[1,0,0],'wire':False,'dynamic':False,'material':0}
kwMeshes={'color':[1,1,0],'wire':True,'dynamic':False,'material':0}
#Demonstration of HarmonicRotationEngine
#O.bodies.append(pack.regularHexa(pack.inSphere((-15,5,-5),1.5),radius=rad*2.0,gap=rad/3.0,color=(0.5,0.5,0.1),material=0))
oriBody = Quaternion(Vector3(0,0,1),(math.pi/4))
#O.bodies.append(geom.facetBox((0,0,0),(0.5,0.5,1.0),wallMask=15,**kwMeshes))
O.bodies.append(geom.facetBunker((0,0,-1.2),dBunker=1.5,dOutput=0.6,hBunker=1.2,hOutput=0.5,hPipe=0.1,orientation=oriBody,segmentsNumber=4,**kwMeshes))
try:
from yade import qt
qt.Controller()
qt.View()
except ImportError: pass
#log.setLevel('SubdomainBalancer',log.TRACE)
O.engines=[
#SubdomainBalancer(colorize=True,initRun=True,iterPeriod=100),
ForceResetter(),
InsertionSortCollider([Bo1_Sphere_Aabb(),Bo1_Facet_Aabb(),Bo1_Wall_Aabb()],label='collider'),
InteractionLoop(
[Ig2_Sphere_Sphere_ScGeom(),Ig2_Facet_Sphere_ScGeom(),Ig2_Wall_Sphere_ScGeom()],
[Ip2_FrictMat_FrictMat_FrictPhys()],
[Law2_ScGeom_FrictPhys_CundallStrack()],
),
GravityEngine(gravity=(0,0,-100)),
NewtonIntegrator(damping=.3),
BoxFactory(maxParticles=-1, extents=(0.5,0.5,1.0),center=(0.0,0.0,0.0),vMin=1.0,vMax=1.5,
rMin=0.025, rMax=0.030,
vAngle=math.pi/3.0,massFlowRate=150.0,normal=(0.0,0.0,-1.0),label='factory',stopIfFailed=False),
DomainLimiter(lo=[-0.6,-0.6,-1.2], hi=[0.6,0.6,1.2], iterPeriod=1)
]
O.dt=1e-5
O.saveTmp()
O.timingEnabled=True
___
Mailing list: https://launchpad.net/~yade-dev
Post to : yade-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-dev
More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] [Yade-users] Optimized contact detection available
Hi, Thanks for the script Anton. This is what I found: - A crash sometimes (not very often) occurs in GLrender(), it is apparently due to deleted body. i could reproduce it before and after bzr3001. I never crashed without opening the GL view. - There was a typo in the modified probe(), it is fixed. There was also the problem of comparing the ref. positions of aabb instead of current position of body, it is fixed too. - One problem in your script it there are no spheres at startup, hence the collider can't determine a verletDist and then it runs at each iteration, which take a lot of time. I got a significant speedup by setting verletDist explicitely to something positive (e.g. 0.002). I added a message warning the user at runtime when the collider fails finding a valid verletDist. - I saved a bit more cpu by removing gravityEngine and using Newton::gravity instead. I'm sending the fixed script. Please let me know how bzr3007 works in your true working scripts. Klaus, I found that clumps were still using an old function from Newton. As a consequence, striding was broken and the collider was acting at each iteration. I get speedup on your script with bzr3007, give it a try. (Don't use Newton::gravity though, it breaks something in your script and I'm still investigating). Bruno On 27/01/12 21:03, Anton Gladky wrote: > Hi, Bruno, > I have prepared a small test-script from "examples/packs.py". It is > similar to one, which is crashes in my case,I could not "catch" a > crash with this test-script, but it seems, BoxFactory creates new > spheres not in the right places:some of particles are "jumping", it > can be caused by the initial overlapping. > Anton > > > > On Fri, Jan 27, 2012 at 7:43 AM, Anton Gladky wrote: >> Ok, I have got a "segmentation fault". >> >> Will try to prepare a simple test-script. >> >> Anton >> >> >> >> On Thu, Jan 26, 2012 at 12:22 PM, Bruno Chareyre >> wrote: >>> Could you please try bzr3006? >>> >>> B > I have tried one of my working scripts and the results are not good. > The new version is dramatically slower. Not sure what is the reason, > but it seems > the bottleneck is SpheresFactory which is working with new version > incorrectly and > cannot find places for new bodies. > > Bruno, is there an opportunity to use both algorithms: old and new one? > It is very difficult to keep both logics Anton, it would combine disadvantages from each side. I should understand what the problem is in SpheresFactory and fix it. Since I didn't touch this code, I'm really curious about the problem. Are you doing operations in SpheresFactory at runtime? Could you send an example script? Bruno ___ Mailing list: https://launchpad.net/~yade-users Post to : yade-us...@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-users More help : https://help.launchpad.net/ListHelp >>> >>> -- >>> ___ >>> Bruno Chareyre >>> Associate Professor >>> ENSE³ - Grenoble INP >>> 11, rue des Mathématiques >>> BP 46 >>> 38402 St Martin d'Hères, France >>> Tél : +33 4 56 52 86 21 >>> Fax : +33 4 76 82 70 43 >>> >>> >>> >>> ___ >>> Mailing list: https://launchpad.net/~yade-users >>> Post to : yade-us...@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~yade-users >>> More help : https://help.launchpad.net/ListHelp >>> >>> >>> ___ >>> Mailing list: https://launchpad.net/~yade-dev >>> Post to : yade-dev@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~yade-dev >>> More help : https://help.launchpad.net/ListHelp -- ___ Bruno Chareyre Associate Professor ENSE³ - Grenoble INP 11, rue des Mathématiques BP 46 38402 St Martin d'Hères, France Tél : +33 4 56 52 86 21 Fax : +33 4 76 82 70 43 #!/usr/bin/python # -*- coding: utf-8 -*- from yade import pack,ymport,export,log,geom,bodiesHandling import math """ This script demonstrates how to use 2 components of creating packings: 1. packing generators pack.regularHexa, pack.regularOrtho etc. generate vertices and filter them using predicates. (Note that this will be enhanced to irregular packings in the future) 2. predicates are functors returning True/False for points that are given by the packing generator. Their names are mostly self-explanatory, see their docstrings for meaning of their arguments. Predicates can be combined using set arithmetics to get their Intersection (p1 & p2), union (p1 | p2), difference (p1 - p2) and symmetric difference (XOR, p1 ^ p2). This is demontrated on the head (which has sphere taken off at the back and also a notch) and the body (with cylidrical hole inside). """ rad,gap=.15,.02 #Add material O.materials.append(FrictMat(young=10e9,poisson=.25,frictionAngle=0.5,density=1e3)) #Para
Re: [Yade-dev] [Yade-users] Optimized contact detection available
> (Don't use Newton::gravity though, it breaks something in your > script and I'm still investigating). > It is not related to the new Newton::gravity, it only revealed another bug in eigen's quaternions. In your script, Klaus, the clump sometimes disappear, did you notice? It is because the axisAngle conversion of clump members orientation is nan from time to time (especially just after impact, when the roation of the clump is very small). For some reasons, this feature breaks the time integration when the gravity engine is removed and replaced by Newton.gravity=-9.81. Adding a GravityEngine in the loop with gravity=(0,0,0) fixes the problem, although it doesn't touch orientation at all... I'm really scared of eigen's quaternions. It's not the first time they give weird behavior. The conclusion is: if you have problems with clumps rotations, add a null gravity engine in your simulation... :( Bruno ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] [Yade-users] Optimized contact detection available
Hi Bruno, > - A crash sometimes (not very often) occurs in GLrender(), it is apparently> > due to deleted body. i could reproduce it before and after bzr3001. I never> > crashed without opening the GL view. I know about the problem with OpenGL-crashes. But for working simulations I do not use graphic at all. Anyway I have catched the backtrace from the crash (rev. 3007): === python: /usr/include/boost/smart_ptr/shared_ptr.hpp:418: T* boost::shared_ptr< >::operator->() const [with T = Bound]: Assertion `px != 0' failed. === Please, have a look. > - One problem in your script it there are no spheres at startup, hence the > collider can't determine a verletDist and then it runs at each iteration, > which take a lot of time. I got a significant speedup by setting verletDist > explicitely to something positive (e.g. 0.002). I added a message warning > the user at runtime when the collider fails finding a valid verletDist. Ok > - I saved a bit more cpu by removing gravityEngine and using Newton::gravity > instead. Thanks for the tip. Will try on my working scripts. Anton On Mon, Jan 30, 2012 at 1:41 PM, Bruno Chareyre wrote: > Hi, > > Thanks for the script Anton. This is what I found: > - A crash sometimes (not very often) occurs in GLrender(), it is apparently > due to deleted body. i could reproduce it before and after bzr3001. I never > crashed without opening the GL view. > - There was a typo in the modified probe(), it is fixed. There was also the > problem of comparing the ref. positions of aabb instead of current position > of body, it is fixed too. > - One problem in your script it there are no spheres at startup, hence the > collider can't determine a verletDist and then it runs at each iteration, > which take a lot of time. I got a significant speedup by setting verletDist > explicitely to something positive (e.g. 0.002). I added a message warning > the user at runtime when the collider fails finding a valid verletDist. > - I saved a bit more cpu by removing gravityEngine and using Newton::gravity > instead. > > I'm sending the fixed script. > Please let me know how bzr3007 works in your true working scripts. > > Klaus, > I found that clumps were still using an old function from Newton. As a > consequence, striding was broken and the collider was acting at each > iteration. I get speedup on your script with bzr3007, give it a try. (Don't > use Newton::gravity though, it breaks something in your script and I'm still > investigating). > > Bruno > > > > > On 27/01/12 21:03, Anton Gladky wrote: > > Hi, Bruno, > I have prepared a small test-script from "examples/packs.py". It is > similar to one, which is crashes in my case,I could not "catch" a > crash with this test-script, but it seems, BoxFactory creates new > spheres not in the right places:some of particles are "jumping", it > can be caused by the initial overlapping. > Anton > > > > On Fri, Jan 27, 2012 at 7:43 AM, Anton Gladky > wrote: > > Ok, I have got a "segmentation fault". > > Will try to prepare a simple test-script. > > Anton > > > > On Thu, Jan 26, 2012 at 12:22 PM, Bruno Chareyre > wrote: > > Could you please try bzr3006? > > B > > I have tried one of my working scripts and the results are not good. > The new version is dramatically slower. Not sure what is the reason, > but it seems > the bottleneck is SpheresFactory which is working with new version > incorrectly and > cannot find places for new bodies. > > Bruno, is there an opportunity to use both algorithms: old and new one? > > It is very difficult to keep both logics Anton, it would combine > disadvantages from each side. I should understand what the problem is in > SpheresFactory and fix it. Since I didn't touch this code, I'm really > curious about the problem. Are you doing operations in SpheresFactory at > runtime? > Could you send an example script? > > Bruno > > > > ___ > Mailing list: https://launchpad.net/~yade-users > Post to : yade-us...@lists.launchpad.net > Unsubscribe : https://launchpad.net/~yade-users > More help : https://help.launchpad.net/ListHelp > > > -- > ___ > Bruno Chareyre > Associate Professor > ENSE³ - Grenoble INP > 11, rue des Mathématiques > BP 46 > 38402 St Martin d'Hères, France > Tél : +33 4 56 52 86 21 > Fax : +33 4 76 82 70 43 > > > > ___ > Mailing list: https://launchpad.net/~yade-users > Post to : yade-us...@lists.launchpad.net > Unsubscribe : https://launchpad.net/~yade-users > More help : https://help.launchpad.net/ListHelp > > ___ > Mailing list: https://launchpad.net/~yade-dev > Post to : yade-dev@lists.launchpad.net > Unsubscribe : https://launchpad.net/~yade-dev > More help : https://help.launchpad.net/ListHelp > > > > -- > ___ > Bruno Chareyre > Associate Professor > ENSE³ - Grenoble INP > 11, rue des Mathématique
Re: [Yade-dev] [Yade-users] Optimized contact detection available
> === > python: /usr/include/boost/smart_ptr/shared_ptr.hpp:418: T* > boost::shared_ptr< >::operator->() const > [with T = Bound]: Assertion `px != 0' failed. > === > > Please, have a look. > Ok, I was suspecting that to. I don't know why it happens precisely but it must come from probe() when stride is used (since the collider was acting at each iteration, it did not appear before). I'll add the check. Could you confirm that the crash is in probeBoundingVolume from full backtrace? Bruno ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] [Yade-users] Optimized contact detection available
>> (Don't use Newton::gravity though, it breaks something in your >> script and I'm still investigating). > It is not related to the new Newton::gravity, it only revealed another > bug in eigen's quaternions. > In your script, Klaus, the clump sometimes disappear, did you notice? It > is because the axisAngle conversion of clump members orientation is nan > from time to time Actually, no... The nan quaternions break the display but they seem to be harmless. The problem was https://bugs.launchpad.net/yade/+bug/923929 It is fixed in bzr3009. Below is what I get with your 02_net-wall_par.py script Klaus (-j2, default collider setting, for 3009 this is without gravity engine). The speedup is only 25%. As said before, it can't be much better since the collider takes only 14% of total time initially. Still, all engines are a bit faster. :) Bruno bzr2999 Name Count TimeRel. time --- ForceResetter 20050 7068191us3.38% InsertionSortCollider 1855 29429129us 14.06% InteractionLoop 20050 92135400us 44.03% "gravity" 20050 23556447us 11.26% "newton" 20050 57063846us 27.27% TOTAL 209253016us 100.00% bzr3009 Name Count TimeRel. time --- ForceResetter 20050 7087997us4.68% InsertionSortCollider 634 11046290us7.29% InteractionLoop 20050 80287582us 52.98% "newton" 20050 53130390us 35.06% TOTAL 151552261us 100.00% ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] [Yade-users] Optimized contact detection available
> === > python: /usr/include/boost/smart_ptr/shared_ptr.hpp:418: T* > boost::shared_ptr< >::operator->() const > [with T = Bound]: Assertion `px != 0' failed. > === > > Please, have a look. Try 3009 please. B ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] [Yade-users] Optimized contact detection available
>> - One problem in your script it there are no spheres at startup, hence the >> collider can't determine a verletDist and then it runs at each iteration, >> which take a lot of time. I got a significant speedup by setting verletDist >> explicitely to something positive (e.g. 0.002). I added a message warning >> the user at runtime when the collider fails finding a valid verletDist. > Ok > Actually, there may be no other option for you than using verlet=0 currently if you are creating spheres very intensively. If, let's say, you create one sphere at each iteration and the collider runs each 10 iterations, then the spheres created between each colliding will not "see" each other, hence the "jumping sphere" problem (probably also the !bound problem comes from this). A smart solution would be to delay spheres creation so that they are created all at once each 10 iterations, or to remember which ones were created to avoid creating another one at the same place. If the collider takes more than 50% of cpu time in your simulation it is worth a try (usually the case when N>20k), else you could continue using verlet=0. It would be usefull maybe to make sure that the collider is triggered each time a body is added, since it is not the case apparently. I wonder if your script are working with version0. Did you try that before? Bruno ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] [Yade-users] Optimized contact detection available
Hi Bruno, thanks for having a look at my scripts! I know that the clump is disappearing sometimes on the display but the simulation itself seems to be ok so I never had a closer look at it. But it was good you did ;-) I just had a look at rev 3010 and now I got some speed up too which is great. I will get rid of the GravityEngine and just use NewtonIntegrator::gravity. Thanks again, Klaus On Tue, 31 Jan 2012 08:02:30 AM Bruno Chareyre wrote: > >> (Don't use Newton::gravity though, it breaks something in your > >> > >> script and I'm still investigating). > > > > It is not related to the new Newton::gravity, it only revealed another > > bug in eigen's quaternions. > > In your script, Klaus, the clump sometimes disappear, did you notice? It > > is because the axisAngle conversion of clump members orientation is nan > > from time to time > > Actually, no... The nan quaternions break the display but they seem to > be harmless. The problem was https://bugs.launchpad.net/yade/+bug/923929 > It is fixed in bzr3009. Below is what I get with your 02_net-wall_par.py > script Klaus (-j2, default collider setting, for 3009 this is without > gravity engine). > The speedup is only 25%. As said before, it can't be much better since > the collider takes only 14% of total time initially. > Still, all engines are a bit faster. :) > > Bruno > > > bzr2999 > Name > Count TimeRel. time > --- > ForceResetter >20050 > 7068191us3.38% > InsertionSortCollider 1855 > 29429129us 14.06% > InteractionLoop 20050 > 92135400us 44.03% > "gravity" 20050 > 23556447us 11.26% > "newton" 20050 > 57063846us 27.27% > TOTAL > 209253016us 100.00% > > bzr3009 > Name > Count TimeRel. time > --- > ForceResetter >20050 > 7087997us4.68% > InsertionSortCollider 634 > 11046290us7.29% > InteractionLoop 20050 > 80287582us 52.98% > "newton" 20050 > 53130390us 35.06% > TOTAL > 151552261us 100.00% ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] [Yade-users] Optimized contact detection available
Good to hear! Thank you for reporting, it made me spot the problem with clump. Bruno On 31/01/12 00:59, Klaus Thoeni wrote: > Hi Bruno, > > thanks for having a look at my scripts! > > I know that the clump is disappearing sometimes on the display but the > simulation itself seems to be ok so I never had a closer look at it. But it > was good you did ;-) > > I just had a look at rev 3010 and now I got some speed up too which is great. > I will get rid of the GravityEngine and just use NewtonIntegrator::gravity. > > Thanks again, > > Klaus > > > On Tue, 31 Jan 2012 08:02:30 AM Bruno Chareyre wrote: (Don't use Newton::gravity though, it breaks something in your script and I'm still investigating). >>> It is not related to the new Newton::gravity, it only revealed another >>> bug in eigen's quaternions. >>> In your script, Klaus, the clump sometimes disappear, did you notice? It >>> is because the axisAngle conversion of clump members orientation is nan >>> from time to time >> Actually, no... The nan quaternions break the display but they seem to >> be harmless. The problem was https://bugs.launchpad.net/yade/+bug/923929 >> It is fixed in bzr3009. Below is what I get with your 02_net-wall_par.py >> script Klaus (-j2, default collider setting, for 3009 this is without >> gravity engine). >> The speedup is only 25%. As said before, it can't be much better since >> the collider takes only 14% of total time initially. >> Still, all engines are a bit faster. :) >> >> Bruno >> >> >> bzr2999 >> Name >> Count TimeRel. time >> --- >> ForceResetter >>20050 >> 7068191us3.38% >> InsertionSortCollider 1855 >> 29429129us 14.06% >> InteractionLoop 20050 >> 92135400us 44.03% >> "gravity" 20050 >> 23556447us 11.26% >> "newton" 20050 >> 57063846us 27.27% >> TOTAL >> 209253016us 100.00% >> >> bzr3009 >> Name >> Count TimeRel. time >> --- >> ForceResetter >>20050 >> 7087997us4.68% >> InsertionSortCollider 634 >> 11046290us7.29% >> InteractionLoop 20050 >> 80287582us 52.98% >> "newton" 20050 >> 53130390us 35.06% >> TOTAL >> 151552261us 100.00% > ___ > Mailing list: https://launchpad.net/~yade-dev > Post to : yade-dev@lists.launchpad.net > Unsubscribe : https://launchpad.net/~yade-dev > More help : https://help.launchpad.net/ListHelp > -- ___ Bruno Chareyre Associate Professor ENSE³ - Grenoble INP 11, rue des Mathématiques BP 46 38402 St Martin d'Hères, France Tél : +33 4 56 52 86 21 Fax : +33 4 76 82 70 43 ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] [Yade-users] Optimized contact detection available
I have got also a good speedup! Just need to test it a little more, compare results etc. Also we need to think about "jumping spheres" problem. For example, we could create one more container in the scene, for example, where will be pointers on "just created" spheres... Anyway, I need to have a better look into the new collider-code to understand, how it actually works. Thanks! Anton ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
Re: [Yade-dev] [Yade-users] Optimized contact detection available
> I have got also a good speedup! > Very good. :) I was not sure it would improve in such "granular flow" case (my mind was more on quasi-static situations when working on that). > Just need to test it a little more, compare results etc. > Remember there is a wiki page to report results. I'm stilll not sure how to define the default parameters. > Also we need to think about "jumping spheres" problem. For example, we > could create one more container in the scene, for example, where will > be pointers on "just created" spheres... It should not be difficult to set dirty=true (or something like that) each time a body is added to scene. It would trigger the collider automatically, and it would work always. How to input spheres the optimal way is a different question, and I must confess I didn't expect people would delete/create bodies at such rates as in your script (interesting script btw). I think optimality of such feature should be handled in sphere factory (and the additional container could be there to), it is not really the collider's business to find free slots for new spheres. > Anyway, I need to have a > better look into the new collider-code to understand, how it actually > works. And I need to document it too... I didn't want to spend time for documentation before positive feedback on the functionality. It is not really different as before in fact. The main difference is that striding is based on exact displacements instead of velocity-based estimates, but it does not explain everything. A good part of the speedup is also in also due to little changes here and there, removing useless operations in the bottlenecks (special thanks to valgrind/callgrind/kcachegrind). Bruno ___ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp
