yade-dev team mailing list archive

[Václav Šmilauer <eu@xxxxxxxx>]

> Hello Vaclav (Hi yade-devs),
> I was wondering one thing when I checked again the periodic sorting.
> I realized that there was a possibility for all bounds to have a
> drift toward larger and larger positive values (not sure how it is in
> Woo, I'm speaking of your implementation in yade).
> This is is because everything is relative to the "loIdx" bound [1].
> Obviously loIdx tends to jump to bounds of smaller coordinates, then
> intuitively I was expecting that it would continuously stay close to
> zero+ position. This is (was - see below) not necessarily the case,
> since the changes of loIdx occur only after inversions.
> So, if you simply impose a collective motion in the x+ direction,
> leading to no inversion, all bounds coordinates are translated
> uniformly across many periods.
> And I found at that when random motion is combined with overall
> motion in the x+ direction (typically periodic flow down infinite
> slope), the same effect happens.
Hi Bruno,
sorry for a rater delayed reply. Thank you for detailed checks of the
code.
I am looking at loIdx now and it should not be a problem. What it does
is that VecBounds::vec behaves as circular buffer (periodic, in our
words) so it does not matter where you start. loIdx marks the index
where the period division is, so that when all particles move
uniformly, loIdx will be moving but bounds will be the same. Whenever
loIdx is re-assigned, the value is re-normalized so that it is between
0 and number of bounds all the time.
> I'm absolutely not sure that it can be a problem, hence this
>     message, out of curiosity. Did you anticipate that (if you
>     remember...)?What is a real problem is that if you drift by 1e5 cells, computation's
precision will suffer everywhere, not just in the collider. That was
something I had in mind but never thought it would happen in practice,
and never measured how much drift was necessary for this to become
apparent. The real solution would be to have a function which would
move particles back to the canonical cell, adjusting cellDist and all
other things, and call it every 1e5 steps or so depending on your
problem. I've never met it myself, as usually periodic simulations were
not so long (lack of patience ;) ) and would also typically be quasi-
static, without drifting.
> 
>     In doubt, I inserted a (cheap) additional loop to clamp the bounds
>     [2]. With this loop all bounds are in [0,size] after the sort. Not
>     sure it is needed though.This is unrelated to loIdx. Speaking of https://github.com/yade/trunk/c
ommit/9ea3fa9aa63070a3af1dad067204f6eba0b0990a I am just looking at
that and do not understand much. v[i].coord is assigned in https://gith
ub.com/yade/trunk/blob/master/pkg/common/InsertionSortCollider.cpp#L296
 , the coordinate pre-processed by cellWrap, so it will be always
within 0..cellSize as far as I see - for the collider. The real
coordinate dependso n the particle's coordinate, which might drift and
cause trouble, see above.
> For the record, I'm pasting below a script exhibiting the bugs I've
>     been trying to solve recently. Unfortunately, this script cannot
>     reproduce the bug deterministically across different computers, as
>     it seems. Even with the same version of yadedaily. For me, a missed
>     interaction was found after 3.4e6 iterations.
I am not able to test this one, sorry :)
Thanks for keeping me updated.
Best, Vaclav