No interactions after erasing body

OK, I've just discovered that when I create a new particle (using O.bodies.append) *after* having erased a previous particle, the bound seems to be uninitialised, which I guess explains why no collisions are detected...

Can anyone tell me why this is the case, and how I should get around it? All other bodies correctly have Aabb instances, but the particle created after I first erase one has uninitialised (other properties look OK, though)...

It would be good to see a simple test-script, which demonstrates the problem.

Anton

Sure, good idea :) This modified version of the bouncing ball script
shows either my problem, or what stupid mistake I'm making ;-) I am
running yade-daily on ubuntu from the PPA (version 2+3128+30~precise1,
from 2012-05-16) and the script below shows the dynamic particle
bouncing in the first case, and penetrating in the second, and that the
bound of the re-created body is not initialised.

Regards, Mark

-----

ids = O.bodies.append([
    utils.sphere(center=(0,0,0),radius=.5,fixed=True),
    utils.sphere((0,0,2),.5)
])

O.engines=[
    ForceResetter(),
    InsertionSortCollider([Bo1_Sphere_Aabb()]),
    InteractionLoop(
       [Ig2_Sphere_Sphere_L3Geom()],
       [Ip2_FrictMat_FrictMat_FrictPhys()],
       [Law2_L3Geom_FrictPhys_ElPerfPl()]
    ),
    GravityEngine(gravity=(0,0,-9.81)),
    NewtonIntegrator(damping=0.1),

VTKRecorder(fileName='vtk/test-',recorders=['spheres','id','velocity'],iterPeriod=1000)
]

O.dt=.5e-4*utils.PWaveTimeStep()

O.run(2100000, True)

print 'Particle IDs and boundings: ' + str(ids)
print str([pcle.bound for pcle in O.bodies])

O.bodies.erase(ids[1])

# Run a few timesteps to ensure interactions are cleared/updated etc.
O.run(10, True)

#Create new body
new_id = O.bodies.append([utils.sphere((0,0,2),.5)])

O.run(2100000, True)

print 'Particle IDs and boundings: ' + str(ids)
print str([pcle.bound for pcle in O.bodies])

On 16/05/12 16:15, Anton Gladky wrote:
> Question #197438 on Yade changed:
> https://answers.launchpad.net/yade/+question/197438
>
> Status: Open => Answered
>
> Anton Gladky proposed the following answer:
> It would be good to see a simple test-script, which demonstrates the
> problem.
>
> Anton
>

It is a bug I think. Thanks for pinpointing the bound problem and providing a script. It should not be too difficult to fix.
I wonder why Anton, who heavily delete/create bodies is not affected...

This is the new record for fixing a bug. ;)

Hi,
It is not very clear to me how this was fixed. Could you please say something more about it, Anton (or Bruno)?
Thank you very much,
Chiara

On 18 May 2012, at 14:25, Chareyre wrote:

> Question #197438 on Yade changed:
> https://answers.launchpad.net/yade/+question/197438
>
> Chareyre proposed the following answer:
> This is the new record for fixing a bug. ;)
>
> --
> You received this question notification because you are a member of
> yade-users, which is an answer contact for Yade.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-users
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~yade-users
> More help : https://help.launchpad.net/ListHelp

If interactions->dirty, then the collider runs at next iteration (including bounds dispatching).
Then the new bound will be defined immediatly (I guess it was defined only after N iterations before the fix).
Do you confirm Anton?

2012/5/18 Chareyre <email address hidden>:
> Question #197438 on Yade changed:
> https://answers.launchpad.net/yade/+question/197438
>
> Chareyre posted a new comment:
> If interactions->dirty, then the collider runs at next iteration (including bounds dispatching).
> Then the new bound will be defined immediatly (I guess it was defined only after N iterations before the fix).
> Do you confirm Anton?

Yes. There are several conditions. when the collider should be rerun [1].
With this commit I force rerunning the function, if even the number of
bodies will not
change (for example, when the body was previously deleted and newly created).

https://github.com/yade/trunk/blob/master/pkg/common/InsertionSortCollider.cpp#L83

Anton

I think, that this bug should not affect many users.

But I will backport the fix to 0.80 branch as well,

Anton

Sounds good. Thanks!

On 18 May 2012, at 18:15, Chareyre <email address hidden> wrote:

> Question #197438 on Yade changed:
> https://answers.launchpad.net/yade/+question/197438
>
> Chareyre posted a new comment:
> If interactions->dirty, then the collider runs at next iteration (including bounds dispatching).
> Then the new bound will be defined immediatly (I guess it was defined only after N iterations before the fix).
> Do you confirm Anton?
>
> --
> You received this question notification because you are a member of
> yade-users, which is an answer contact for Yade.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-users
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~yade-users
> More help : https://help.launchpad.net/ListHelp

Thanks for the fix and explanations! I'm not set up to build yade at the
moment, and the daily build for precise failed last night, but I'll give
it a try next time the build succeeds!

Thanks,

Mark

On 18/05/12 23:30, Chiara Modenese wrote:
> Question #197438 on Yade changed:
> https://answers.launchpad.net/yade/+question/197438
>
> Chiara Modenese proposed the following answer:
> Sounds good. Thanks!
>
>
> On 18 May 2012, at 18:15, Chareyre<email address hidden> wrote:
>
>> Question #197438 on Yade changed:
>> https://answers.launchpad.net/yade/+question/197438
>>
>> Chareyre posted a new comment:
>> If interactions->dirty, then the collider runs at next iteration (including bounds dispatching).
>> Then the new bound will be defined immediatly (I guess it was defined only after N iterations before the fix).
>> Do you confirm Anton?
>>
>> --
>> You received this question notification because you are a member of
>> yade-users, which is an answer contact for Yade.
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~yade-users
>> Post to : <email address hidden>
>> Unsubscribe : https://launchpad.net/~yade-users
>> More help : https://help.launchpad.net/ListHelp

Tested and confirmed solved on lucid x64 - thanks! The build failed again for precise x64 on launchpad, but I guess that's a separate issue! Regards, Mark

Thanks Anton Gladky, that solved my question.

Hi Mark,

I have just committed a better fix for this bug (rev 1e50860). I would
recommend you to update, because the previous hurts performance.

> The build failed again for precise x64 on launchpad, but I guess that's a separate issue!

There are not enough RAM again on build-servers.

Anton

> I have just committed a better fix for this bug (rev 1e50860). I would
> recommend you to update, because the previous hurts performance.

Ah... I guess the problem is ISCOllider.cpp:162

        if(scene->interactions->dirty){
            doInitSort=true;
            scene->interactions->dirty=false;
        }

We don't need the doInitSort in this case, we just need to update the
sort like in a ordinary colliding (not initialize it, as for iteration 1).
One way to trigger a standard colliding is to set
Collider::fastestBodyMaxDist>1, as if one body moved too much (which is
in fact the case of that body that disappeared then popped up in a
different place...).

Bruno

Or maybe cleaner: add a flag "doSort" somewhere (Scene or Collider?) and turn it on when inserting bodies.

2012/5/21 Chareyre <email address hidden>:
>
> Chareyre posted a new comment:
> Or maybe cleaner: add a flag "doSort" somewhere (Scene or Collider?) and
> turn it on when inserting bodies.

Maybe you are right, but I am not sure, whether this action will
create "bounds" for newly created bodies.

Anton.