[ODE] ODE spatial inconsistency
pilat at cpsc.ucalgary.ca
Thu Jun 21 10:22:53 MST 2007
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.
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.
> / h+
More information about the ODE