Re: [Yade-dev] [Yade-users] Optimized contact detection available

2012-01-31 Thread Bruno Chareyre 

> 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

Re: [Yade-dev] [Yade-users] Optimized contact detection available

2012-01-31 Thread Anton Gladky 
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

2012-01-31 Thread Bruno Chareyre 
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

2012-01-30 Thread Klaus Thoeni 
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

2012-01-30 Thread Bruno Chareyre 

>> - 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

2012-01-30 Thread Bruno Chareyre 

> ===
> 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

2012-01-30 Thread Bruno Chareyre 

>>   (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

2012-01-30 Thread Bruno Chareyre 

> ===
> 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

2012-01-30 Thread Anton Gladky 
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

2012-01-30 Thread Bruno Chareyre 

>   (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

2012-01-30 Thread Bruno Chareyre 
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

2012-01-27 Thread Anton Gladky 
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

2012-01-26 Thread Anton Gladky 
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

2012-01-26 Thread Bruno Chareyre 
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

2012-01-26 Thread Bruno Chareyre 

> 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