> 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