[ODE] ODE spatial inconsistency

[Marcin Pilat]

Thanks Jon,

I guess I failed to state that in my mails - I am running the  
deterministic version of ODE (using dWorldStep) and when I run the  
sample at the same x,y position, the result is identical every run.   
However, the problem arises when I vary that x,y position.

Somebody just pointed out in an email that physics engines such as  
ODE have accuracy that varies with position.  That would explain the  
results I am getting with the sample (the graphs, etc).  Can any of  
you explain why that is the case though and/or provide some  
literature on the topic?

Another sample result I've noticed that seems to validate this  
observation:  2 blocks, side by side, no joint, one 0.01 step through  
dWorldStep, 2 experiments: one starting at 0.01, another at 0.02 in x  
direction.  Result is 0.00777778 in x (for 0.01) and 0.0177778 in x  
(for 0.02).  As you can see that we have lost one decimal place of  
accuracy just between those two. Between 0.0 and 0.1 there are 2  
decimal places lost.

I realize that rounding is a bad idea in the long run that only masks  
problems - but I'm looking for any ideas that will enable me to use  
ODE for further experiments even if it has such problems.

Thanks,

Marcin


On 21-Jun-07, at 12:29 AM, Jon Watte (ODE) wrote:

> ODE has been made fully deterministic in the past. I suggest you  
> search the mailing list archives for what you need to do.
> In brief:
> 1. There is a random number generator for permuting the matrix in  
> the fast solver that needs to be consistently seeded.
> 2. The rounding mode of the CPU needs to be consistent (this is the  
> x87 control word)
> 3. The register size mode of the CPU needs to be consistent (this  
> is also in the x87 control word)
> 4. All objects, geoms, and queries need to be introduced into the  
> system in a consistent ordering.
> Note that certain libraries and signal handlers will change those  
> modes on you, so your best bet is to test and reset if necessary  
> before you start your collision/step, each time.
>
> Btw: rounding does not "fix" divergence errors, it just masks them.  
> Once in a while, that last bit will go the other way, and suddely  
> you've introduced an even bigger error by doing the rounding.
>
> Cheers,
>
>             / h+
>
>