Forcing InsertionSortCollider execution

Asked by Jérôme Duriez

Hi,

I would like to force InsertionSortCollider to do his job on demand, and could not find how to do it. Is it possible ?

To give you some background about the issue, I'd like to introduce distant interactions at some point in a simulation, changing aabbEnlargeFactor and interactionDetectionFactor once the simulation has already started. However, I have been unsuccessful when InsertionSortCollider does not run right after the changes (and it does not always run)

The script below considers two distant spheres to illustrate the issue and the link with InsertionSortCollider executions : change O.run(10,1) to e.g. O.run(1,1) and ISC would run each timestep and I would get my distant interaction..

************************************************
 from yade import timing
O.timingEnabled=True

O.bodies.append(sphere(Vector3(0,0,0),1,fixed=True))
O.bodies.append(sphere(Vector3(0,0,3),1,fixed=True))

O.run(10,1)
print 'Number interactions = ', O.interactions.countReal()

# Attempting to introduce distant interactions
O.engines[1].boundDispatcher.functors[0].aabbEnlargeFactor = 2.0
O.engines[2].geomDispatcher.functors[0].interactionDetectionFactor = 2.0
O.engines[2].lawDispatcher.functors[0].neverErase = True

O.step()
print 'Number interactions = ', O.interactions.countReal()
# => 0 in this case, I need InsertionSortCollider to run to get my interaction

yade.timing.stats()
*******************************************************

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
Jérôme Duriez (jduriez) said :
#1

Sorry to answer myself, I just found out I could use

O.runEngine(O.engines[1])
or O.engines[1].__call__()

to solve the issue... (even though the imposed ISC execution would not appear in the Exec count stats, it seems)

Comments, if any, are still welcome

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

Hi Jérôme,
Setting verletDist=0 will make the collider run at each iteration.
Does it really do something with runEngine? I would expect the collider to just return if not a collliding situation.
Bruno

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

Thank you for the comment, but it seems it is not possible to actually update verletDist during the simulation, no ?

In the above script, adding O.engines[1].verletDist=0 before the O.step() does not lead to any new interaction. (Whereas defining O.engines[1].verletDist=0 from the start would indeed do the trick.)

As for runEngine(), I confirm adding O.runEngine(O.engines[1]) before O.step() is enough to have a new interaction after the O.step()
However, I finally faced difficulties with this runEngine method in my actual script (the not minimal one), the particles bounds being therein not updated after a runEngine()...

(In the end, my problem is still solved with another method, but everything is not 100% clear yet, as you see)

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

>it is not possible to actually update verletDist during the simulation

It is possible of course.
The main problem is that the collider is smart: if the grains do not move (as in your exemple) there is no need to detect new collisions.
Consequence: the lines after "# Attempting to introduce distant interactions" are not doing anything
You can check in the 3D view, the bounds are not modified. The new sizes would be accounted for only after the next colliding step (give a velocity to one body, bounds will change).

>As for runEngine(), I confirm adding O.runEngine(O.engines[1]) before O.step() is enough

I see. runEngine() skips the check InsertionSortCollider::isActivated(), so you get something even if it would not normally run.

In the long run, I think this question of creating distant interactions should be solved without the collider because it has different requirements compared to detecting collisions.

Bruno