New container causes different results between r2091 and r2092

[Anton Gladky]

As discussed http://<email address hidden>/msg03202.html
r2091 and r2092 gives different results.

Attached script shows that.

r2091 output:
17716
17716
17716

r2092 output:
18519
18519
18539

This is the number of cohesive contacts inside the specimen.

Thank you

[Bruno Chareyre (bruno-chareyre)]

I confirmed this bug with FrictPhys contacts. Scene generated with TT
preprocessor : different runs give different numbers of iterations.
In addition : different numbers in load/saved scenes, as in
https://bugs.launchpad.net/yade/+bug/569169.

[Václav Šmilauer (eudoxos)]

Anton, I am not able to reproduce the bug with your script. I have 17716 with both r2091 and r2092, and 19872 with current (which is due to regularHexa changes).

Bruno, can you be more precise? Different number of iterations could be fine (finite precision, periodic engines bound to computation time which is not constant) etc, Anton's script was supposedly giving different number of interactions (contacts). I need a script that I can run.

Bug #569169 is a separate issue.

[Anton Gladky (gladky-anton)]

Hi, Vaclav,

please, try to make a clean r2092 install and you should get the difference.
For one time I also got r2092 normal results, but after clean install I have
got again the problem.

Thank you
______________________________

Anton Gladkyy

2010/4/25 Václav Šmilauer <email address hidden>

> Anton, I am not able to reproduce the bug with your script. I have 17716
> with both r2091 and r2092, and 19872 with current (which is due to
> regularHexa changes).
>
> Bruno, can you be more precise? Different number of iterations could be
> fine (finite precision, periodic engines bound to computation time which
> is not constant) etc, Anton's script was supposedly giving different
> number of interactions (contacts). I need a script that I can run.
>
> Bug #569169 is a separate issue.
>
> --
> New container causes different results between r2091 and r2092
> https://bugs.launchpad.net/bugs/563894
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Yet Another Dynamic Engine: New
>
> Bug description:
> As discussed
> http://<email address hidden>/msg03202.html
> r2091 and r2092 gives different results.
>
> Attached script shows that.
>
> r2091 output:
> 17716
> 17716
> 17716
>
> r2092 output:
> 18519
> 18519
> 18539
>
> This is the number of cohesive contacts inside the specimen.
>
> Thank you
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/yade/+bug/563894/+subscribe
>

[Václav Šmilauer (eudoxos)]

It was a clean instal what I did...

[Václav Šmilauer (eudoxos)]

OK, it seems it was due of bug #569169 after all. Please check by redefining

 def cohesiveContacts():
 coh=[(i.id1,i.id2) for i in O.interactions if i.phys.isCohesive]
 print len(coh),len(set(coh))

in your script (set automatically merges multiple occurences of the same (i.id1,i.id2) tuple. If you get 2 different numbers, it is a bug. I do get difference for r2092 and after.

It is correct (both number the same) for r2080 and later, and also for r2091. Absolute values are different between the version due to regularHexa changes.

Please set to Fix Commited if it works for you now.

[Bruno Chareyre (bruno-chareyre)]

I wrote "iterations"? Sorry, I meant "interactions".

Unfortunately, the other fix in container doesn't seem to solve this problem (it was not a duplicated bug).

In r2181, generate a TriaxialTest.xml and run this (with always the same xml ofc) :

O.load("TriaxialTest.xml")
O.run(2000)
O.interactions.countReal()
1116
....
1130
...
1120

[Václav Šmilauer (eudoxos)]

OK, open a new bugreport then. Anton's case is fixed.

BTW the fact that multi-threaded simulations are not deterministic has been discussed here multiple times. That is not a bug.

[Bruno Chareyre (bruno-chareyre)]

You are right, the difference comes only when j=2 apparently (I didn't
notice it was the default!).
I reviewed the discussion about this : I'm still surprised roudings can
make such significant difference in only 1000 iterations.
But ok : no new bug. Thanks.

[Václav Šmilauer (eudoxos)]

I think if you ran without damping, the difference wouldn't be as noticeable.

Cundall's damping is not Lorentz-like function that amplifies small causes into big effect. It is function that is _discontinuous_, i.e. depending on value of the least significant bit, if around zero, that force's component is multiplied (damping=.2) by .8 or 1.2 -- that is propagation by easily 10 orders of magnitude in just one step!

[Anton Gladky (gladky-anton)]

Thank you very much Vaclav! It works now as should work.

[Anton Gladky (gladky-anton)]

I cannot change the status of this big. The button does not work for me.

[Václav Šmilauer (eudoxos)]

Oh, if it is duplicate, it takes status from the master bug. OK then.