[ODE] Possible solution to unstable rotating bodies problem

Gary R. Van Sickle g.r.vansickle at worldnet.att.net
Thu Apr 7 05:19:33 MST 2005

Again I don't want to get into a huge thing over this considering there's no
code for there to be a thing over, but FWIW:

> > Seriously, these sort of arguments really have no truck 
> with me (i.e. 
> > "It would make things correct in the sense of the program not 
> > crashing, but you'd need an extra bit and an if-then-else for every 
> > object which would slow things down by 0.0001%, so let's 
> just ignore it.").
> There are tons of simulations that don't explode.

True.  And there are tons of applications I use every day which are
defective in some way, yet I either luck out and the defects don't manifest
themselves for whatever reason, or I consciously work around the defects.
In neither instance are the defects solved.

> With 
> sufficient damping, any simulation can be made to not 
> explode.

Well, fine, but that's like Homer Simpson's classic line, (paraphrasing):
"Pffht, Marge, everything seems bad if you remember it!"  The problem isn't
that the free body doesn't have sufficient damping applied to it; the
problem is that the free body gains momentum when it shouldn't.

> Tyler reports that extreme amounts of damping still 
> didn't work for him -- I would attribute that to a bug, 

As I suppose would I, I hadn't seen that statement.

> rather than to damping not being enough to work around the 
> numerical problems inherent in this kind of simulation.

I have multiple issues with that statement:

- Maybe damping is enough to work around this problem.  I strongly prefer
solutions to workarounds though, as I believe most people do.
- I do not belive that there are "numerical problems inherent in this kind
of simulation".  In fact the "isolated rigid body spinning in space" problem
has a simple closed form solution.  I believe other special cases do as well
(I'm thinking "spinning top" in particular here).

> Thus, 
> you're trading a solution that costs cycles and memory, 
> against a solution that is currently implemented and uses 
> much less cycles and memory.

What's the solution for a guy who wants, say, his space station to slowly
spin forever?  Damping can't solve it; what would be the damping factor to
exactly balance the probably-uncharacterizable momentum growth?  Explicitly
enforcing conservation of momentum/energy would solve it (and who knows what
else), because it would attack the root problem.  The question that we
should be asking here is, "how can we enforce conservation of
momentum/energy?", with sub-questions like, "how do we do it with minimum or
even positve impact on runtime and/or memory?", "If it does have any
penalties, is it worth #ifdef-ing?", "should we seek a general solution, or
break out special cases and treat them differently?", etc.

Your "much less cycles and memory" statement is actually wrong.  Still with
the spinning satellite, what if Tyler's "isolated rigid body" solution is
sharp enough to detect such situations (i.e. the body has a stable spin
about an axis), and switch over to the closed-form solution instead of the
numerical integration one?  That's way *less* cycles, and one *bit* more
memory (i.e. a flag to say "do the closed-form rigid body spin calculations
on this one").

> The only reason to choose the 
> new option

Again, there is no new option.  Only a lot of talk, mostly from yours truly
;-).  And my talk can be summed up rather sussinctly: "Solve problems if you
can, bandage if you must."

> over the old would be that you don't like the 
> characteristics of a sufficiently dampened simulation,

I don't like exploding universes, correct.  I also don't like twiddly bits
that, if not set right, result in the universe exploding.  And I like those
twiddly bits even less if there is no possible way to know what they should
be set to, nor to guarantee that you've set them right.

> and 
> what I'm saying is that I'm not sure whether your preference, 
> or the needs of people who use ODE in memory- and 
> cycle-constrained environments, is the bigger need.

And I don't see these as being in any way mutually exclusive, because I
simply don't subscribe to the notion that "doing things the correct way"
always and forevermore means "doing things the slow, big, and bloated way."
Again, *worst possible case*, there is *always* #ifdef to fall back on!

Gary R. Van Sickle

More information about the ODE mailing list