PDA

View Full Version : Computational Physics - "Numerical Integration": RK4, Verlet.. "n-body problem"



abaraba
2008-Oct-18, 10:02 AM
hello everyone,


this is about an algorithm,
time stepping function aka "iterative solver" - it is the one and the same algorithm no mater if you're simulating planets, moons, galaxies.. atoms, molecules, ping-pong balls or maybe even 'strange attractors' and chaos itself..




PLEASE,
can someone confirm or prove this wrong, im happy with either - THANK YOU!



summary:
- the 1st basic problem is that Wikipedia and the rest of the internet claim that there is some ERROR in "Euler method", but there is not. the error exist only with nonuniform rate of change in acceleration - this caused practical implementation of algorithm to perform "integration" even if there was no need for it, which in turn caused further multiple mistakes and errors in implementation

- the 2nd basic problem has to do with limiting of number of steps per main loop iteration, but this is not really important for non real-time applications, tho its one of the factors in producing the error under certain situation coupled with 1st problem


BOTH of these "bugs" are present in every single software package i came across, that include all of the commercial and Open Source physics libraries - Havok, PhysX, Bullet, ODE, Ogre, Newton.. but it also seem to include scientific simulators; "Software for molecular mechanics modeling": AGM, AMBER, Ascalaph, BOSS, CHARMM, GROMACS, LAMMPS, MCCCS, MOE, MOIL, MOLDY, NAB, QMOL, RasMol, TINKER, VMD + NAMD, YASARA, Zodiac... (from Wikipedia)


and who knows where else..
i hope, for example, at NASA they actually dont have this buggy algorithm, eh?



ok, let me now copy/paste the message that i hope explains all the subjects that i would like to discuss here, and of course i can go into more details depending on what turns out to be most interesting to public here...



+++COPY/PASTE:
//=== OVERTURE =======================================

Numerical Integration: RK4, Verlet.. WIKIPEDIA is WRONG!

KEYWORDS:
Constraint Algorithm, Iterative Solver, Interpolation, Extrapolation, Verlet, Runge Kutta, Taylor, Sampling, Multistep; Monte Carlo, SHAKE, RATTLE, SETTLE algorithms


do the search and you may find that:
- Wikipedia and every other info on the Internet regarding these matters is simply FALSE in the context of computer simulation, but no one seem to listen to me and im not allowed to make changes.. as 'unverified source'

So, there you go.. all these studies, books, papers, articles.. WRONG?!

//==================================================

//--- FUGUE..

to whom it may concern...
+++ i believe i found the heart of the whole problem:


"numerical integration",
as i suggested before, is completely misplaced in its practical implementation



--- the cause ---

before applying mathematics to physics, and before implementing the solution in computer simulation application there was a failure to recognize TWO very different types of "simulation", i'll call them 'FIELD FORCES' and 'CLASSIC' simulation



A.) 'FIELD FORCES simulation', i.e. NON-UNIFORM "external" ACCELERATION
- deals with oscillations, gravity fields, planet or atom orbits..

B.) 'CLASSIC simulation', i.e CONSTANT "external" ACCELERATION
- everything that is not in the first category.. majority of simulations that deal with objects under constant gravity (constant altitude)



--- the problem ---

1.) with constant acceleration - basic kinematic equations will actually give EXACT solution, i.e. the next POSITION is exact solution as function of time, previous position and acceleration/velocity
(what was measured as error was actually "bug" in implementation)

ergo,
we do not need any APPROXIMATION... no INTERPOLATION is necessary with constant acceleration - we do not need any fancy mathematics, we already have EXACT solution, and so addition of any other computation will only hinder precision and speed


2.) ..plus, if you have this popular implementation that uses MAX steps, as everyone does, then i hope everyone can see now where all the problems came from



--- the solution ---

huh.. this thing surely turned much deeper than i expected, and im still tumbling down the rabbit hole.. but i know this - there are many problems here and solutions that i already proposed do work.. tho, the general and complete solution has to do with defining the problems of the "FIELD FORCE simulation" and basically just define stuff more clearly - which is what im trying to do, and i would appreciate some help







--- the general and complete solution ---

"FIELD FORCE simulation" - NON-UNIFORM ACCELERATION
- so you doing simulation of planetary or maybe atomic orbits..


then, i think its important to realize this sort of simulation is to CLASSIC simulation what ray tracing is to vector graphics


basically, all of the objects are under COLLISION all the time, they all interacting with each and every other object 'ALL the time', in NON-UNIFORM acceleration topology


now we have two problems:

1.) physics libraries and all the spatial partitioning and speed-ups are of no use, the whole "constant collision" is a huge performance problem in its own and solution is to buy faster computer or build cluster of CPUs


2.) the solution to "constant collision" algorithm has actually to do with "n-body problem", "Kepler problem", maybe even "Coulomb's law" and stuff like that - basically, a problem is to find a position as function of time when given initial positions, masses and velocities


one of the ways to go about it is by ITERATIONS, i.e every time step we calculate new AVERAGE ACCELERATION, then calculate velocities and positions as usual




and so,
we finally arrive to the point where "numerical interpolation" makes sense - its nothing else but one of the ways too approximate that *AVERAGE ACCELERATION*, thats the whole point - to compensate for the rate of change in acceleration and try to estimate it given the elapsed time period (time step)


obviously, with enough small time step and maybe some "simple average" the error caused by this would probably be minimal compared to other numerical instabilities already present in computer hardware... and so, even in this case RK4, Verlet.. might be less than desirable solution


*ONLY* "EXTERNAL" NON-UNIFORM ACCELERATION "needs" some sort of APPROXIMATION, there is no need to interpolate position or velocity



of course,
exact solution is much better than some approximation... (to be concluded)



am i right or wrong?

//------------------------------------------------------------
+++END COPY/PASTE





thank you all

cjameshuff
2008-Oct-18, 03:15 PM
summary:
- the 1st basic problem is that Wikipedia and the rest of the internet claim that there is some ERROR in "Euler method", but there is not. the error exist only with nonuniform rate of change in acceleration - this caused practical implementation of algorithm to perform "integration" even if there was no need for it, which in turn caused further multiple mistakes and errors in implementation

You contradict yourself. Yes, there is an error in the result of Euler integration when acceleration is not uniform...so the various sources out there are correct.



- the 2nd basic problem has to do with limiting of number of steps per main loop iteration, but this is not really important for non real-time applications, tho its one of the factors in producing the error under certain situation coupled with 1st problem

I'm not sure what you refer to here. However, computer arithmetic is done to finite precision, and it is not very useful to continue reducing step size when the limiting factor is the numeric precision.



BOTH of these "bugs" are present in every single software package i came across, that include all of the commercial and Open Source physics libraries - Havok, PhysX, Bullet, ODE, Ogre, Newton.. but it also seem to include scientific simulators; "Software for molecular mechanics modeling": AGM, AMBER, Ascalaph, BOSS, CHARMM, GROMACS, LAMMPS, MCCCS, MOE, MOIL, MOLDY, NAB, QMOL, RasMol, TINKER, VMD + NAMD, YASARA, Zodiac... (from Wikipedia)

and who knows where else..
i hope, for example, at NASA they actually dont have this buggy algorithm, eh?

Carefully and precisely describe exactly what you think the "bugs" are.



A.) 'FIELD FORCES simulation', i.e. NON-UNIFORM "external" ACCELERATION
- deals with oscillations, gravity fields, planet or atom orbits..

B.) 'CLASSIC simulation', i.e CONSTANT "external" ACCELERATION
- everything that is not in the first category.. majority of simulations that deal with objects under constant gravity (constant altitude)

The usual division is between numeric simulations and analytical ones. Many of what you call "field forces simulations" can be done analytically.



1.) with constant acceleration - basic kinematic equations will actually give EXACT solution, i.e. the next POSITION is exact solution as function of time, previous position and acceleration/velocity
(what was measured as error was actually "bug" in implementation)

ergo,
we do not need any APPROXIMATION... no INTERPOLATION is necessary with constant acceleration - we do not need any fancy mathematics, we already have EXACT solution, and so addition of any other computation will only hinder precision and speed

This does not follow. If acceleration is constant, d = v*t + 0.5*a*t^2 is indeed ideal, giving exact results to the precision of the arithmetic...but acceleration is usually not constant, or even varying in a way conducive to analytical solution.



then, i think its important to realize this sort of simulation is to CLASSIC simulation what ray tracing is to vector graphics

I think you mean scanline rendering. And a better analogy would be a raster image to a vector image.



1.) physics libraries and all the spatial partitioning and speed-ups are of no use, the whole "constant collision" is a huge performance problem in its own and solution is to buy faster computer or build cluster of CPUs

This is not true. At a distance, the effects of the individual objects in a small volume of space are often insignificant, and so they can be grouped together and treated as a single object as far as interactions with distant objects are concerned. The maximum error produced by this simplification can be quantified. It is a valuable technique for handling complex systems without requiring excessive amounts of processing power.



*ONLY* "EXTERNAL" NON-UNIFORM ACCELERATION "needs" some sort of APPROXIMATION, there is no need to interpolate position or velocity

Pretty much. What's your point? Analytical solutions are almost always preferred over numeric ones, when they are possible. There are a few cases where exact analytical solutions are just too unwieldy for practical use, or the precision isn't worth the trouble of working the equations out, but as a general rule, they are preferred. Those physics packages will generally not do analytical solutions, the assumption is that if you need to use one, you are doing something that is complex enough to need numeric solving. If "d = v*t + 0.5*a*t^2" is sufficient for your calculations, why would you be using a complicated physics library?

So...what exactly is the problem you see? Or the question you have?

abaraba
2008-Oct-18, 05:48 PM
cjameshuff,


are you proving me wrong?
..or just saying "stuff" with no reason, purpose or meaning?


if you go on pretending that you know - you will never learn




>>"You contradict yourself."
>>"...so the various sources out there are correct."

- no, i do not, but you do..
please make yourself familiar with "various sources"





>>"I'm not sure what you refer to here."

- of course you're not,
and yet you find appropriate to be giving advice?





>>"Carefully and precisely describe exactly what you think the "bugs" are."


- i do not think, assume or guess - i KNOW


the 2nd bug is mostly related to real-time simulation, it has to do with smooth animation and FPS, but since i had the most terrible time trying to inform public of this, i think that i should keep this "bug-fix" for myself ..you dont even know that you have bugs, so its all the same to you





>>"The usual division is between numeric simulations and analytical ones. Many of what you call "field forces simulations" can be done analytically."


- you should be asking questions and not pretending to be giving advice, its silly





>>"This does not follow. If acceleration is constant, d = v*t + 0.5*a*t^2 is indeed ideal, giving exact results to the precision of the arithmetic...but acceleration is usually not constant, or even varying in a way conducive to analytical solution."


- of course it follows,
thats why i first made that classification and so i was clearly talking about:
>"1.) with constant acceleration - ...with constant acceleration"


so it is you who does not follow,

you say:
>>"but acceleration is usually not constant" - even if my first three words clearly stated what case im talking about, then i repeated it once more, just in case, but that wasn't enough apparently - whats your problem?





>>"I think you mean scanline rendering. And a better analogy would be a raster image to a vector image."


- stop insulting yourself,
you clearly know nothing about any of these then





>>"This is not true. At a distance, the effects of the individual objects.."

- you can simulate your objects as you like,
i said i was describing GENERAL solution, which also means unoptimized, or yet in other words, it also means 'as precise as possible'

..you can optimize as you like, but dont complain and go write studies about some "phantom errors", mysterious "energy leaks" and other "phenomenon" ..its just bugs

good luck!




>>"Pretty much. What's your point?"

- my points is that everyone has wrong implementation, that Wikipedia and the rest of the internet have wrong explanations which most likely was actual cause that everyone have same wrong implementation


to understand that you need to be looking at source code of all these software packages and libraries i mentioned or whichever software you're using, then you might see bugs im talking about ..and then you might search internet and you will find out where the bugs came from




>>"So...what exactly is the problem you see? Or the question you have? "

- are you blind?
--------------------------------------------------------------------------
PLEASE,
can someone confirm or prove this wrong, im happy with either - THANK YOU!
--------------------------------------------------------------------------


..for that you need to use ARGUMENTS and you need to know what are you talking about



actually when i look at it now,
when you're not plain wrong or confused, you mostly DO agree with me.. thanks

cjameshuff
2008-Oct-18, 10:18 PM
If this is the tone you've been using elsewhere, it's no wonder people don't pay any attention to you.


are you proving me wrong?

You haven't really given enough of an argument to prove wrong. There were some factual errors, I covered most of those in my previous post.



>>"I'm not sure what you refer to here."

- of course you're not,
and yet you find appropriate to be giving advice?

I don't know what you think is a problem, because you haven't stated it clearly. I do appear to be equipped to give you advice. Have you ever even taken a numeric analysis class? Or written an orbit simulator?



>>"Carefully and precisely describe exactly what you think the "bugs" are."


- i do not think, assume or guess - i KNOW


the 2nd bug is mostly related to real-time simulation, it has to do with smooth animation and FPS, but since i had the most terrible time trying to inform public of this, i think that i should keep this "bug-fix" for myself ..you dont even know that you have bugs, so its all the same to you

This is not a careful and precise description of what you think the problem is. Have you considered that if you want people to be informed about it...you might have to give them some information?



>>"The usual division is between numeric simulations and analytical ones. Many of what you call "field forces simulations" can be done analytically."

- you should be asking questions and not pretending to be giving advice, its silly

I did ask a question. And here's another: can you point out anything wrong with what I just said?



- of course it follows,
thats why i first made that classification and so i was clearly talking about:
>"1.) with constant acceleration - ...with constant acceleration"


so it is you who does not follow,

you say:
>>"but acceleration is usually not constant" - even if my first three words clearly stated what case im talking about, then i repeated it once more, just in case, but that wasn't enough apparently - whats your problem?

Okay...so you're talking about problems involving constant acceleration. Why claim a problem with orbit simulations, then? Why talk about numeric integration packages, when you're talking about something with a closed form analytical solution?



>>"I think you mean scanline rendering. And a better analogy would be a raster image to a vector image."

- stop insulting yourself,
you clearly know nothing about any of these then

I've written raytracers, scanline renderers, and programs using raster and vector graphics. I've contributed a fair amount of code to the POV-Ray raytracer.
Raytracing is to vector images as apples are to oranges. One's a way of representing 2D images with polygons and curves, the other is a way of generating a 2D image of a 3D scene by performing intersection tests on rays going into the scene. Scanline rendering instead projects polygons onto a 2D plane, and raster images represent an image with an array of pixels.



>>"This is not true. At a distance, the effects of the individual objects.."

- you can simulate your objects as you like,
i said i was describing GENERAL solution, which also means unoptimized, or yet in other words, it also means 'as precise as possible'

Then why'd you bring it up?



>>"Pretty much. What's your point?"

- my points is that everyone has wrong implementation, that Wikipedia and the rest of the internet have wrong explanations which most likely was actual cause that everyone have same wrong implementation

In what way is it wrong?



>>"So...what exactly is the problem you see? Or the question you have? "

- are you blind?

That would have made it rather difficult to test the renderers and simulations I've written...
Above, you got rather upset about me "giving advice" rather than asking questions. In case you didn't recognize it, that was a question. Please answer it.



..for that you need to use ARGUMENTS and you need to know what are you talking about

If you want people to pay attention to what you're saying, you might try that yourself...



actually when i look at it now,
when you're not plain wrong or confused, you mostly DO agree with me.. thanks

I'm certainly confused, your rant has not exactly been the most coherent of arguments. As for the other...where am I wrong?

Tinaa
2008-Oct-18, 10:50 PM
abaraba take time to read http://www.bautforum.com/about-baut/32864-rules-posting-board.html

Pay especial attention to 2. Civility and Decorum

Politeness is the top rule here. Of course, we expect to have spirited debates! That’s fine, as long as the people involved extend one another basic respect. Disagreements are inevitable, but even in those situations you must still be nice.

Attack the ideas, not the person(s) presenting them. If you've got concerns with what someone is saying, feel free dismantle their arguments, but do not resort to ad hominem or personal attacks. Be mindful and respectful of others' feelings. If you feel that someone has crossed the line and insulted you, please contact one of the moderators, preferably via the reporting mechanism described here, or by PM or email. Don't write scathing posts in the forum to try and humiliate people publicly.

If these guidelines are not followed, the administrators/moderators will take swift and appropriate action, so please behave accordingly.

abaraba
2008-Oct-19, 12:52 AM
cjameshuff,

- please copy/paste your time stepping function so i can show you on concrete and practical example..

would that be enough of a proof?






//--------------------------------------------------------

Tinaa,


>>"Politeness is the top rule here. Of course, we expect to have spirited debates!"

- why do yo saying this to me?

is it not obvious that it was 'cjameshuff' who was pointless, trying to put me down with no reason and with no arguments, skewing my sentences and lecturing about stuff he clearly showed he has no knowledge of



>>"Attack the ideas, not the person(s) presenting them."

- clearly it was me who was attacked here first, with no reason and NO ARGUMENTS, i simply do not back down and no one will **** over me, i hope that is clear



>>"If these guidelines are not followed, the administrators/moderators will take swift and appropriate action, so please behave accordingly. "


- i fixed many problems that concern almost everyone... there is no reason, what so ever, for anyone to try and put me down


i dont need silly lectures and i can do whatever i please.. you, on the other hand, have these choices:

- you can say "thank you"
- you can ask anything
- you can agree
- you can disagree and we can discuss it until one is proven wrong

but what ever you say, you MUST QUOTE what are you referring to and use ARGUMENTS to support your opinion, NOT GUESSES, NOT ASSUMPTIONS, so we can make it clear for everyone and continue the discussion, everything else is rude, unclear or unnecessary




//----------------------------------------------------------
-"All truth goes through three stages.
First it is ridiculed;
then it is violently opposed;
finally it is accepted as self-evident." (Schopenhauer)

ToSeek
2008-Oct-19, 02:05 AM
i dont need silly lectures and i can do whatever i please.. you, on the other hand, have these choices:

- you can say "thank you"
- you can ask anything
- you can agree
- you can disagree and we can discuss it until one is proven wrong



There is one other possibility here that you need to take into consideration: we can suspend or terminate your posting privileges here. And this is exactly what's going to happen unless you start treating the rules and other members of this forum with respect and consideration.

I see nothing objectionable in cjameshuff's posts so far and a great deal objectionable in yours. People are trying to help you out and understand what you're talking about here - you should take that into account rather than treating any criticism as hostility.

ToSeek
BAUT Forum Moderator

mugaliens
2008-Oct-19, 09:31 AM
...but what ever you say, you MUST QUOTE what are you referring to and use ARGUMENTS to support your opinion, NOT GUESSES, NOT ASSUMPTIONS, so we can make it clear for everyone and continue the discussion, everything else is rude, unclear or unnecessary.

Have you considered pursuing your explorations via a graduate level course in philosophy, where such mandatory rules apply?

Here on these message forums, collectively known as Bad Astronomy/Universe Today, we take more of an eclectic approach, and quite often, guesses, assumptions, and other "soft" approaches (some might call them "touchy-feely") are better suited for the many and varied individuals who call this online community "home."

You rules sound reasonable, however, for such a discussion as you propose. Have you considered starting your own message forum website, wherein you would be free to impose your own rules as you see fit?

I do not say this in jest, but as a mod and admin on other boards, a few of which I've started from scratch. Sometimes, which certain approaches are not feasible on one board, it's time to start another, with a different set of rules under which they would be feasible.

On the other hand, you can accomplish much the same here by simply choosing to adhere to those rules yourself while mentioning that you're doing, without requiring that others do so. Then, you're free to respond to whatever portion of anyone's comment you wish, and if you find someone's response not to your liking, you're also free to simply ignore it.

I hope you find this bit of constructive commentary useful.

Good luck!

abaraba
2008-Oct-19, 01:42 PM
i apologize to everyone..

i suppose its all matter of opinion, i thought this concerns everyone

Computer Simulation,
used in Chemistry, Biology, Medicine.. to develop new drugs, to study diseases, in genetic engineering.. its used to help us predict earthquake, tsunamis and other natural disasters.. in industry to build automobiles and planes.. its used to help us understand the world around us and model interactions of atomic and subatomic particles.. its even used in development and testing of nuclear weapons.. to model planets, stars, galaxies, used by NASA for planning trajectories, orbits, exit and entry points ...it used everywhere


i thought it was important enough, so i felt responsibility to share this with the rest of the world.. in return, i got only stones in my face and fingers in my eyes ..interesting

Veeger
2008-Oct-19, 02:10 PM
This particular discussion is very interesting to me, but it definitely got off on the wrong foot, and I think mainly because of the opening post. Perhaps because of the posting style, or whatever, I found it difficult to ascertain what your point was, abaraba. For example, you stated 1) there was no inherent error in the Euler method for uniform acceleration 2) there is no need to limit step size on non realtime computations; 3) both of these bugs are present on all software packages.

(If I incorrectly summarized your premises, forgive me)

What bugs?

I think cjameshuff was right on track when he stated that (more or less - I'm paraphrasing) that the biggest limitation of digital computation models is the round-off error inherent in the computation system. After many interations, the error accumulates and soon the error exceeds the threshold of what is acceptable.

I presently have several implementations of integrators (in source code format) and have been looking into them more deeply and while each approach seems to be according to the whim and skill of the programmer, at the end of the day, if the simulation yields acceptable results then it works. (disclaimer - I am not a mathematician, but I have written a few programs in my day :) ).

cjameshuff
2008-Oct-19, 09:01 PM
What bugs?

I'm still wondering that myself. It'd be nice if he answered some of the questions and gave us some idea what he was talking about, rather than howling about unjust persecution in response to every reply...



I think cjameshuff was right on track when he stated that (more or less - I'm paraphrasing) that the biggest limitation of digital computation models is the round-off error inherent in the computation system. After many interations, the error accumulates and soon the error exceeds the threshold of what is acceptable.

To be more precise, I was pointing out that for a given solver, problem, and numeric precision, there is a point where reducing the size of the time-steps can not improve results because the numeric precision of the computations becomes the limiting factor. One of his "bugs" is apparently a practice of limiting the number of steps you can specify...I've not come across such a limit myself, and would assume that NASA, etc. are doing the analysis to determine what step size meets their requirements.

The other "bug", as near as I can tell, is that numeric solvers will solve problems numerically even if it is possible to do them analytically. I would put forth that if you don't want a numeric solution, you shouldn't use a numeric solver. In molecular dynamics, orbital trajectories, etc, you generally don't have any other options, though.

abaraba : I have written simulations using RK4, velocity Verlet, and Beeman's method, and a few variations of Euler's method. However, none of them are really conducive to discussion of the algorithms involved...too much unrelated code intertwined. There are many minimal examples of these algorithms out there...why not pick one, and demonstrate the "bugs" and your fix?

frankuitaalst
2008-Oct-19, 09:28 PM
In the case of integration of the n-body gravitational problem there also exists code which uses algorithms based on Taylor-series . This approach is quite different of the methods used by Euler , Leap Frog , RK4...
The only limitation in this approach seems to be the numerical limitation
The method works quite well , fast and accurate , especially for low numbers of bodies .
This method approaches the analytical solution of the n-body problem , as a Taylor series does .

Veeger
2008-Oct-19, 10:08 PM
What initially struck my interest as a programmer, was the fact I was looking at Aldo Vitagliano's early implementation of a Stormer 8th order integration yesterday and then boom, this thread appears. I have never successfully written a program which uses first order forward Euler that remains stable. Perhaps the algorithm is flawed, perhaps the initial conditions, I don't know, but I have just started exploring this interesting topic. I, for one, am ready to learn something.

abaraba
2008-Oct-19, 11:47 PM
everyone,

feel free to copy/paste your algorithms, your time stepping functions..

i'll show all the problems and then fix them on concrete and practical examples, then you can report your findings and compare with previous results, you also might compare the speed of algorithms, not only precision/correctness


..hope that should be convincing enough

Van Rijn
2008-Oct-19, 11:54 PM
everyone,

feel free to copy/paste your algorithms, your time stepping functions..

i'll show all the problems and then fix them on concrete and practical examples, then you can report your findings and compare with previous results, you also might compare the speed of algorithms, not only precision/correctness


..hope that should be convincing enough

Why don't you show us an example you think is relevant (but not your own code, not something you came up with yourself) and show us the problems you think you've found in it?

Veeger
2008-Oct-20, 12:57 AM
Just to see where this leads, the snippet of code below was from one my first attempts at testing the feasibility of a simple algorithm. The code is written in VB6 which I usually use for prototyping before converting to C/C++.

I am posting the parts which calculate accelerations and which would normally integrate them. The loops shown below are intended to be inside an outer loop which is basically the step loop.




For i = 0 To nObjects - 1
pi(0) = Obj(i).px ' position of the i'th body
pi(1) = Obj(i).py
pi(2) = Obj(i).pz
tax = 0 ' start with no accelerations
tay = 0
taz = 0
For j = 0 To nObjects - 1
DoEvents ' yield to other processes while looping
' i cannot equal j
If i <> j Then
pj(0) = Obj(j).px ' position of the j'th body
pj(1) = Obj(j).py
pj(2) = Obj(j).pz
' Find the acceleration caused by
' the gravity of j on i
dx = pj(0) - pi(0) ' derive a vector from j to i
dy = pj(1) - pi(1)
dz = pj(2) - pi(2)
dist = Sqr(dx * dx + dy * dy + dz * dz)
tax = tax + tstep * (G * Obj(j).m / (dist ^ 3)) * dx
tay = tay + tstep * (G * Obj(j).m / (dist ^ 3)) * dy
taz = taz + tstep * (G * Obj(j).m / (dist ^ 3)) * dz

End If
Next


Obj(i).ax = Obj(i).ax + tax ' accumulate the accelerations
Obj(i).ay = Obj(i).ay + tay
Obj(i).az = Obj(i).az + taz

Obj(i).px = Obj(i).px + Obj(i).ax ' update the object positions
Obj(i).py = Obj(i).py + Obj(i).ay
Obj(i).pz = Obj(i).pz + Obj(i).az
Next


When putting in the masses, starting positions, and accelerations of the Mercury through Neptune and the earth's moon, this code worked and produced decent orbits. The earth orbit, however, soon decayed, and the moon broke free into a solar orbit; obviously flawed. I tried several variants of this code but none allowed me to use a time slice of any value other than one.

cjameshuff
2008-Oct-20, 01:08 AM
In the case of integration of the n-body gravitational problem there also exists code which uses algorithms based on Taylor-series . This approach is quite different of the methods used by Euler , Leap Frog , RK4...
The only limitation in this approach seems to be the numerical limitation
The method works quite well , fast and accurate , especially for low numbers of bodies .
This method approaches the analytical solution of the n-body problem , as a Taylor series does .

Even Euler's method is closely related to Taylor series. For example:

vnew = vold + a*t

That's your simple, first-order Euler's method, and also the first two terms of a Taylor series. It'll give exact results, aside from roundoff error, as long as a is constant. If it is not constant, the error is bounded by the third term of the Taylor series, a'*t^2/2. The position computation is in this situation, and using Euler's method with the initial or final velocity will give very poor results, but if you instead average the velocities at the beginning and end of the step:


pnew = pold + (vold + vnew)/2*t
= pold + (vold + vold + a*t)/2*t
= pold + vold*t + a*t^2/2

Which should look familiar...both as the exact solution for motion under constant acceleration, and as the first three terms of a Taylor series. This can be applied further if more derivatives are available, but that can become rather unwieldy. If you infer such derivatives from past accelerations, velocities, or positions, you end up with something that can be shown to be analogous to one of the higher order methods. To my knowledge, *all* such techniques can be analyzed in terms of Taylor series (after all, they are all solving the same problem), and some of them, like Runge-Kutta, are easily extensible to higher orders...RK4 is simply the 4th order version.

abaraba
2008-Oct-20, 03:07 AM
hey cjameshuff, thank you!

you actually did it,
you confirmed the basic premise from which most of the problems spawned

let me take back everything i said ..can i do that?

thanks again..

i'll soon post some practical examples of source code i have here

but let me tell you there are TWO main bugs and there are about 4-5 other "bugs" or common mistakes that go closely related to this - so, although very simple in nature, this may appear complicated just because it interconnects somewhat unrelated stuff...

[edit]
ok, so the code below is ACTUAL code from Open Source Bullet physics library... as much as i know so far, i can tell you the similar/same implementation exist in Intel Havok, NVIDIA PhysX, ODE, Newton...

i've also seen it in molecular dynamics software that is used by universities and large scientific institutions
actually, as far as i know - EVERYONE has some similar implementation that has 1, 2, 3.. or more of these bugs

in this particular case i will concentrate on 2nd bug - "MAX SUBSTEPS BUG"

this is original:


//-----------------------------------------------------------------------
int btDiscreteDynamicsWorld::stepSimulation( btScalar timeStep,int maxSubSteps, btScalar fixedTimeStep)
{
startProfiling(timeStep);

BT_PROFILE("stepSimulation");

int numSimulationSubSteps = 0;

if (maxSubSteps)
{
//fixed timestep with interpolation
m_localTime += timeStep;
if (m_localTime >= fixedTimeStep)
{
numSimulationSubSteps = int( m_localTime / fixedTimeStep);
m_localTime -= numSimulationSubSteps * fixedTimeStep;
}
} else
{
//variable timestep
fixedTimeStep = timeStep;
m_localTime = timeStep;
if (btFuzzyZero(timeStep))
{
numSimulationSubSteps = 0;
maxSubSteps = 0;
} else
{
numSimulationSubSteps = 1;
maxSubSteps = 1;
}
}

//process some debugging flags
if (getDebugDrawer())
{
gDisableDeactivation = (getDebugDrawer()->getDebugMode() & btIDebugDraw::DBG_NoDeactivation) != 0;
}
if (numSimulationSubSteps)
{

saveKinematicState(fixedTimeStep);

applyGravity();

//clamp the number of substeps, to prevent simulation grinding spiralling down to a halt
int clampedSimulationSteps = (numSimulationSubSteps > maxSubSteps)? maxSubSteps : numSimulationSubSteps;

for (int i=0;i<clampedSimulationSteps;i++)
{
internalSingleStepSimulation(fixedTimeStep);
synchronizeMotionStates();
}

}

synchronizeMotionStates();

clearForces();

#ifndef BT_NO_PROFILE
CProfileManager::Increment_Frame_Counter();
#endif //BT_NO_PROFILE

return numSimulationSubSteps;
}
//-----------------------------------------------------------------------



this completely replaces that thing from above, and fixes 1st & 2nd bug (in most cases):



//-----------------------------------------------------------------------
int btDiscreteDynamicsWorld::stepSimulation(
btScalar timeStep,int maxSubSteps, btScalar fixedTimeStep)
{
m_localTime+= (timeStep < fixedTimeStep*2)? timeStep : fixedTimeStep*2;
saveKinematicState(fixedTimeStep); applyGravity(); maxSubSteps= 0;
while( m_localTime >= fixedTimeStep )
{
internalSingleStepSimulation(fixedTimeStep);
m_localTime-= fixedTimeStep; maxSubSteps++;
}
synchronizeMotionStates(); clearForces();
return maxSubSteps;
}
//-----------------------------------------------------------------------


this is actual, practical example implementation and you can try it in a matter of minutes: http://www.bulletphysics.com/Bullet/phpBB3/


+++symbolic explanation:

--- PROBLEM, "NUMERICAL INTEGRATION" ---




//-------------------------- *** ORIGINAL algo - capping the NUMBER
cnt= 0;
time= 10;

maxSteps= 5;

while(time > 0 && cnt < maxSteps)
{
step(); cnt++;
time--;
}
//--------------------------
Iterations, cnt= 5
"Time left", time= 5 <<<--- TIME REMAINDER


combination of bug1 & bug2 (integration + maxSubSteps)
"integration" wrongly trying to deal with this reminder of time caused by MAX sybSteps- in all of the implementations of this algorithm i've seen.. all physics libraries, ALL ..and some molecular dynamics software.. SAME!

this mostly has to do with smooth animation and FPS under loaded CPU with real-time applications, but if implemented in scientific software, scientist could, in effect, observe some "energy drift" not knowing there was a bug inside the software

this bug would heavily depend on the definition of "MAX ITERATIONS", "MAX NUM of SUBSTEPS" or similarly named variable and the size of time-step (fixed time-step, deltaTime)

pzkpfw
2008-Oct-20, 05:31 AM
Could you edit your posts using
...code... tags to make them readable?

For one thing, it stops HTML-style space compression, so you can use indenting.

frankuitaalst
2008-Oct-20, 05:06 PM
[QUOTE=cjameshuff;1346589]Even Euler's method is closely related to Taylor series. For example:

vnew = vold + a*t

That's your simple, first-order Euler's method, and also the first two terms of a Taylor series. It'll give exact results, aside from roundoff error, as long as a is constant. If it is not constant, the error is bounded by the third term of the Taylor series, a'*t^2/2. The position computation is in this situation, and using Euler's method with the initial or final velocity will give very poor results, but if you instead average the velocities at the beginning and end of the step:


pnew = pold + (vold + vnew)/2*t
= pold + (vold + vold + a*t)/2*t
= pold + vold*t + a*t^2/2

QUOTE]
Yes indeed you're right . This is some kind of Taylor expansion .
But the method a referred to writes down the velocities and positions of each body as a time power series up to ...fi. power 22 .
So ri(t) is represented by ri1+ri1*t+ri2*t^2.....rin*t^n
( same for the velocities ) .
Together with the accelerations formulas one obtains a set of algebraic equations which can be solved for ri0, ri1....rin .

The great advantage of this approach is that the motion can be described as a function of time and can be interpolated , and ...the desired accurancy per timestep can be given .
Accurancies of fi. 10m or even less can be obtained over an interval of time of 120 hours ( which is in this case the timestep) .

If interested I can provide some references about this method .
The method , described by Parker et al . is used fi. by Carles Simo

abaraba
2008-Oct-20, 08:32 PM
let me argue these two:

"NUMERICAL INTEGRATION": Interpolation, Extrapolation, Verlet, Runge Kutta, Taylor, Modified Euler...


A.) "NUMERICAL INTEGRATION" is completely misplaced in its practical implementation, time stepping algorithm

B.) "NUMERICAL INTEGRATION" is completely NOT NECESSARY in this algorithm, and as such, it is actually a cause of inaccuracy and slowdown



"Euler method" is all you need.. but maybe i can argue 3rd point as well

C.) Not even "Euler method" is required, all you need is basic kinematic equations and you solve the problem in easy three steps like you did in high school:


STEP 1: calculate INSTANTANEOUS acceleration (this is the ONLY topic for discussion, i think)


then calculate position at the end of the step as usual...

STEP 2: v=a*dt
STEP 3: s=v*dt

--->REPEAT


i dont see why would that be called "Euler method" and why would there be any kind of "numerical integration"

sure, since it is iterative loop it is some sort of "integration" in its nature, but calling it fancy names while it is a matter of simple kinematic equations is misleading, yes?



//--------------------------------
...and once we agree,
we have a chance of making a really nice, general and universal algorithm... having in mind that in case where acceleration was uniform during the time-step the INSTANTANEOUS acceleration is nothing more but simple AVERAGE

so, the REAL QUESTION is - what is the "AVERAGE" of INVERSE SQUARE change of rate in acceleration (jolt, surge)



--- THE TRICK ---
because you not quite sure what is the acceleration at the end of the step - you are not quite sure about the "average" ..and even worse you are not quite sure even about acceleration at the begging of the time-step, since you calculated it with this same uncertainty the last time as well

..kind of like Schrödinger's cat and thing about determining the position of an electron in atom orbit, you can not know velocity, mass and position in the same time.. interestingly, in analogy we could achieve COMPLETE SPATIAL ACCURACY, by giving up the certainty of TIME, but sure without knowing "what time it is" during the simulation, we cant quite iterate to the next step and we would not know what time it is "around" other objects ..ah damn quantum mechanics!

all i wanted is to make the bloody Moon spin around the Earth ..sheesh! can human not do anything on this planet without bumping into some PARADOX?!




let me repeat this now,
- this is COMPLETE and EXACT solution with constant gravity (constant altitude), simply because we KNOW the exact acceleration at ANY time and so we can calculate that average acceleration easy: (a1+a2)/2



so again,
the REAL QUESTION.. The Ultimate Question of Life, Universe and Everything:

*** what is the "AVERAGE" of INVERSE SQUARE change of rate in acceleration (jolt, surge) ? ***


42?


answer that question,
and, in return, i'll simulate 'LIFE' inside the computer.. virus or bacteria perhaps, on atomic or molecular level


how does that sound?

cjameshuff
2008-Oct-20, 09:58 PM
A.) "NUMERICAL INTEGRATION" is completely misplaced in its practical implementation, time stepping algorithm

B.) "NUMERICAL INTEGRATION" is completely NOT NECESSARY in this algorithm, and as such, it is actually a cause of inaccuracy and slowdown

The time stepping process, accumulating a quantity over time, is numerical integration.



"Euler method" is all you need.. but maybe i can argue 3rd point as well

Due to the error involved when the function being integrated is not constant...no, it isn't. About the only thing it's useful for is a teaching tool, and rough approximations where processing power and code size are very limited.



i dont see why would that be called "Euler method" and why would there be any kind of "numerical integration"

It's called the "Euler method" because Leonhard Euler developed much of the math related to it. It's a method for performing numerical integration.



sure, since it is iterative loop it is some sort of "integration" in its nature, but calling it fancy names while it is a matter of simple kinematic equations is misleading, yes?

No. It is integration. That's not a technicality, or an obscure and trivial analogy...it's what it fundamentally is. Where do you think those kinematic equations came from?



so, the REAL QUESTION is what is the "AVERAGE" of SQUARE INVERSE change of rate in acceleration (jolt, surge)

That depends on your trajectory through the field. It's more than tricky...it requires numerical algorithms to compute for arbitrary numbers of objects.

Also, there are often other effects...Lorentz forces that depend on velocity, drag which depends on both velocity and the surrounding medium (in the case of planets, on winds and density profiles), photon and solar wind pressure which depend on solar weather, variations of planets from perfect spheres, the measured performance of rocket engines...



*** what is the "AVERAGE" of SQUARE INVERSE change of rate in acceleration (jolt, surge) ***

Use a numerical approximation to compute it. It's generally not (a1 + a2)/2, because acceleration is usually not changing at a constant rate.

abaraba
2008-Oct-20, 10:45 PM
i dont understand what is the point of your message


- you do not prove wrong any of my statements

- you do basically agree with all i said

- you just rearranged the words and made fancy labels


[edit:]
>"sure, since it is iterative loop it is some sort of "integration" in its nature, but calling it fancy names while it is a matter of simple kinematic equations is misleading, yes?"

your answer to this question is therefore - YES
(but are you doing it on purpose to confuse everyone or you just confused yourself..)




please, have in mind that i can actually CONFIRM in PRACTICE that im telling the truth, its very pointless to argue about some empty meanings

i expect now some of moderators will give you a lecture.. >>"Politeness is the top rule here."

i think if you plan on blindly attacking me, you should consider that you failed to provide your algorithm... anyway, why so angry?

abaraba
2008-Oct-21, 12:34 AM
ooops sorry,
i have to address this, since its very, very.. terribly, awfully wrong.. wrong, wrong, wrong, wrong ...FALSE!


ME:
>"Euler method" is all you need..

YOU:
>>"Due to the error involved when the function being integrated is not constant...no, it isn't."


while(TRUE != FALSE) print( " WRONG, WRONG, WRONG !!! " );

once you realize what that "function" you're talking about actually is, you will agree with me, even more


YOU:
>>"About the only thing it's useful for is a teaching tool, and rough approximations where processing power and code size are very limited."

while(TRUE != FALSE) print( " WRONG, WRONG, WRONG !!! " );


my algorithm will give EXACT and PERFECT solution with ALL,
but ONE SPECIAL CASE - when acceleration was nonuniform for the given time interval, just like division has special case - "division by zero"

BUT,
even with this special case, with nonuniform acceleration, my algorithm will be "MORE CORRECT" and FASTER than whatever algorithm you have there based on these wrong assumptions - wanna bet? give me your algorithm!


(the keyword here is actually: "constant COLLISION DETECTION" )

Veeger
2008-Oct-21, 01:29 AM
Are we talking about two-body or n-body solutions? I am not understanding how acceleration can be constant in an n-body system when the effective acceleration is the resultant of all of the other acceleration vectors also acting in the system.

abaraba
2008-Oct-21, 01:59 AM
>>"Are we talking about two-body or n-body solutions? "

- am talking about Life, Universe and Everything, so about n-body, which includes two-body


but im also talking about all other everyday simulations, all the games, soccer, billiard, ping-pong, racing, flying, falling, shooting cannon, all those simulations are under CONSTANT GRAVITY, constant altitude

so, EULER WILL DO PERFECTLY

but to answer THE QUESTION, we then talk about n-body problem, we talk about nonuniform acceleration, or more precisely we talk about INVERSE SQUARE since its the same thing with planets and atoms...


>>"I am not understanding how acceleration can be constant in an n-body system when the effective acceleration is the resultant of all of the other acceleration vectors also acting in the system."

- its not, but it is where it is, on Earth surface for example which will satisfy the most, and again Euler is COMPLETE and PERFECT solution for "everyday" simulations on Earth surface, or some other "constant" altitude - constant "external' acceleration


As for for 'n-body problem' and nonuniform acceleration - so we can simulate planets and atoms - we need to address this:


The Ultimate Question of Life, Universe and Everything:
- what is the "AVERAGE" of INVERSE SQUARE change of rate in acceleration?

answer that question,
and, in return, i'll simulate 'LIFE' inside the computer.. virus or bacteria perhaps, on atomic or molecular level



...or maybe even on planetary level.. have you considered the possibility that our galaxy might be just a molecule inside some huge interstellar virus?


but don't forget that our equations are flawed as they are,
masses are not point masses and size does matter, not really in relative way, such that atoms could easily be the size of planets, that's possible, size does not matter in that sense - but it matters as a property of "distance to mass" or some sort of "density parameter" - this actually has quite to do with practical case, because its something you can start with in order to make decision on the size of time-step (granularity) ..everything is about how to "control the error" and recognize how errors form, how they accumulate with time and how decimal precision of computer hardware plays its role in all this...

Veeger
2008-Oct-21, 02:05 AM
Sorry, I am not interested in philosophy or science fiction. I am interested in n-body simulations which is what I thought I understood from the title of the opening post.
:)

abaraba
2008-Oct-21, 02:19 AM
did i not answer your question before?



>>"Are we talking about two-body or n-body solutions? "
- ..so about n-body, which includes two-body



>>"I am interested in n-body simulations.."

- yes, this is one of the better ways to go about solving the n-body problem



>>"Sorry, I am not interested in philosophy or science fiction."

- im sorry, can't help you there,
its really unfortunate since it is all interconnected..

cjameshuff
2008-Oct-21, 02:34 AM
my algorithm will give EXACT and PERFECT solution with all but ONE SPECIAL CASE - when acceleration was nonuniform for the given time interval, just like division has special case - "division by zero"

That is not a special case, it is the general rule. Euler's method only gives exact results when the derivative is constant...that is a special case.



even with this special case, with nonuniform acceleration, my algorithm will be MORE CORRECT and FASTER than whatever algorithm you have there based on these wrong assumptions - wanna bet? give me your algorithm!

Velocity Verlet? Or Beeman's algorithm? They're simpler to implement than RK4. I'm not claiming to have any super-special secret algorithm that gives better results. I'm claiming everybody uses the more complex algorithms because they need to in order to get good results.

Have you actually tried this at all? It's extremely clear exactly why Euler's method is inaccurate. And in fact, an orbit simulation using Euler's method will very quickly diverge from anything resembling reality, even with a huge number of steps. Higher order methods can give stable results for many orbits with far larger steps. The other methods do require more processing per step, but can achieve equivalent accuracy with far fewer steps, and so are much faster overall, not to mention avoiding roundoff error.

Veeger
2008-Oct-21, 03:04 AM
but don't forget that our equations are flawed as they are,
masses are not point masses and size does matter, not really in relative way, such that atoms could easily be the size of planets, that's possible, size does not matter in that sense - but it matters as a property of "distance to mass" or some sort of "density parameter" - this actually has quite to do with practical case, because its something you can start with in order to make decision on the size of time-step (granularity) ..everything is about how to "control the error" and recognize how errors form, how they accumulate with time and how decimal precision of computer hardware plays its role in all this...

If I'm understanding you well (and I doubt I am), considering the size of object and the sum of its relative gravity as anything other than a point-source, adds a whole other layer of complexity to the equations. Even if the goal is to only consider size in computationally trying to determine and control error accumulation. Consider when two masses are very close together and their collective gravities are acting on a third mass.

abaraba
2008-Oct-21, 03:42 AM
>>"..considering the size of object and the sum of its relative gravity as anything other than a point-source, adds a whole other layer of complexity to the equations."

- yes, that is my point,
and that's how it is in nature, simple rules - complex results ..that's the beauty of it

[edit: little bit of Cyberpunk philosophy...]

its similar to fractals,
in its simplicity in rules and iterative nature, where results feed directly into next iteration to produce next results - beautiful, "harmonic" results.. planets, stars, galaxies.. they're moving.. it's animation, that's life...

-"All other things being equal, the simplest solution is the best."
(Occam's razor)




>>"Even if the goal is to only consider size in computationally trying to determine and control error accumulation."

- ok, let me try to rephrase it

* the goal is always to simulate reality as close possible, and so we must realize that our equations are APPROXIMATIONS to start with

* its important to realize that approximating average acceleration in given time step IS NOT the only error, we have decimal precision, point mass, rounding and maybe some other errors like with gravity constant and such..

* realize that by decreasing the time step,
and maybe taking some "simple harmonic average" as a guess we decrease this error, therefore we can control this error in "AVERAGE ACCELERATION", which is good



CONCLUSION:
there is a point where the size of the time step is small enough so that error in the estimation of AVERAGE ACCELERATION will be less than other errors

CONSIDER THIS - THE RESULT:
the result is some collection of coordinates after some given time interval, to be useful for humans you have to print it as numbers with *certain limited number of decimal places* OR you gonna print it as graph, as dots on a screen or paper and again, it will be in some *certain limited resolution of that screen or paper*

all im saying is:
- find out what precision are you after as a result, then accordingly asses other errors and finally decide on the size of the time step, so that the error be less than the sum of other "numerical instabilities"


there is also another way,
- to make corrections based on equivalence and preservation of energy, so that n-body system always keep SUM E(n)= SUM(n)(1/2*mv^2 )

or something like that, but i didnt have much time to think about it, so dont put me down if this "another way" doesn't hold the water, tho you sure welcome to correct me, but its really a secondary matter (FOR NOW)




>>"Consider when two masses are very close together and their collective gravities are acting on a third mass."

- yes, its all very complicated - the goal is to approximate it as best as we can, in fastest possible way


Homer (as Max Power):
- From now on, there are three ways to do things: the right way, the wrong way, and the Max Power way.

Bart:
- Isn't that just the wrong way?

Homer:
- Yeah, but faster!

abaraba
2008-Oct-21, 04:34 AM
cjameshuff ,


ok, thank you for you input we all know now your opinion and your arguments, which mostly actually agree with mine

so, nothing has changed and its time for other people to make input, if they will...




>>"Velocity Verlet? Or Beeman's algorithm? They're simpler to implement than RK4."

- simple kinematic equation is even simpler.. and more correct.. or even EXACT in most of the "everyday" simulations, which makes other methods look silly


>>"I'm claiming everybody uses the more complex algorithms because they need to in order to get good results."

- yep, i noticed it myself ...i laugh at that



>>"Have you actually tried this at all?"

- as soon as you copy/paste that algorithm of yours i can prove it ..even to you ...until then, thanks for your opinion and arguments, now lets hear what other people think

abaraba
2008-Oct-21, 05:46 AM
let me copy/paste something i found on another forum:


-"Actually, the first order Euler method works remarkably well. With a timestep as large as 16767 seconds per time step, the solar system holds together for over a million years. Probably more, as I ended the simulation at 1 million years because it took my computer a month to do. I can speed this up to 65536 if I remove moons from the solar system. Faster than that causes Mercury to deviate from its orbit.

In fact, the Euler Method is accurate enough that if I use JPL's Horizons system to accurately place the planets in their January 1, 2003 position, Mars and Earth pass each other at exactly the right time and distance as the real Mars did August 2003 when it made its closest approach in 60000 years. Running the simulation further into the future, Mars also passed Earth at the correct time and distance for its next opposition (2005? I think). But the 2007 opposition came about 2 days early or late, but at the right distance, and the 2009 or 2010 opposition was about 7 days off its predicted date, but the correct distance. I'm not sure if Runge Kutta would give better results here. I might just need a more accurate value for G or for Sun mass."


http://www.physicsforums.com/showthread.php?t=21812&page=2


>>"I might just need a more accurate value for G or for Sun mass."

- yes, it seems the error in "Euler method" is the least worry here.. to what precision are we certain in the planetary masses and gravitational constant... to what precision was it defined inside the program, how many decimal places?

..and how many iterations the program went through.. MANY! ..where did error come from? ...Euler?



i'll see if i can contact him so that he can make some further comment, it would be interesting to compare RK4 with these results he got with Euler ...and then compare it with my special algorithm


www.gravitysimulator.com

if someone knows this guy,
or similar guy that has built in all the planetary data already, please call him in, thank you




in any case,
thank you for your existence 'gravitysimulator guy', thanks Tony!

Veeger
2008-Oct-21, 10:59 AM
I believe he posts at this forum. I actually PMed him a few days before your OP, but he never answered me.

abaraba
2008-Oct-21, 11:10 AM
thanks,

i sent him an e-mail too.. he should actually know much more than myself

to be honest now,
i really have not tried any of this ..except that 2nd bug, i just "discovered" that 2nd bug with max substeps, then i noticed my algorithm works perfectly without any integration, which was the point when i "discoverd" the 1st bug with "integration" ...then, after about two months of trying to figure out how could it happen that everyone implemented this algorithm the same way, with exact same two bugs?! ..then i "discovered" the 3rd bug that has to do with simulation frequency i.e. size of timeStep - where people would do the opposite to "fix" the error, they would increase frequency and amazingly "integration" would make it look as if they were improving something... then i discovered the 4th bug.. hahaa, is this funny? so, the 4th bug was related to gravity, mass and size..

at that point i wrote a book, its written in allegory and its actually also a technical paper about this subject, its actually collection of my arguing with people on public forums.. many of these threads does not exist anymore, so this book is the only place that holds some of the information

here is the part from it:



Three bugs with one stone.. allegory continues
RealTime Allegory Novella, Technical Paper and Chronological account of an Algorithm discovery


Kapitoly:
I) Genesis, anecdote
II) Divina Commedia, abysm spirale
III) Seraphim and Nephilim, the chronicles
IV) Aspidochelone, physiologus
V) ..alegoria continua


..among other themes,
book most obviously and most practically addresses these issues:
Common bugs
in Havok, PhysX, Bullet, ODE, Ogre, Newton.. SOLVED!

Bug 1.) Few subSteps: "Moon gravity effects"
bUg 2.) A lot of subSteps: "Spiraling to death"
buG 3.) Interpolation VS. Temporal Distribution


Common mistakes
related to fixedTimeStepping - UNCOVERED
a.) Design-Time Planning and Recognition of Hardware Min. Sys. Requirements
b.) "Scaling the World" - Gravity, Mass, Size and Hidden Effects of fixedStepping
c.) Jitter, Wobbles, Choppiness and Slowdowns: Unstable Physics & Smooth Animation


Common pitfalls
for any kind of simulation, say - MOLECULAR DYNAMICS
-"Error and timing analysis
of symplectic multiple time-step integration methods for molecular dynamics"

-"In molecular dynamics simulations,
'Energy Drift' is the gradual change in the total energy of a closed system"

-"Multiple time-step integration
hampered by parametric resonance exhibits the instability phenomenon"




Stepping the simulation correctly - living la vida loca
(Intel Software Network, Havok Physics Engine Public Forum)

September 25, 2008

ahm.. there are two stories here, (@..alegoria continua)
one story is 'obvious story', its just what it is - a conversation on public forum where im trying to argue, somewhat emotionally, a validity of this bug-report and propose solution to which i would like to have some feedback on.

now,
the other story is a little sci-fi 'Cyberpunk NOVEL', kind of like the Matrix trilogy, hence the preluding quote, but this tale is all in ALLEGORY, i.e. it has symbolic or figurative meaning and its already told, its woven within this real-time dialog/monologue on public forums, its a "real-time allegory novel" if you will, i hope you will like it..

- its about "good and evil" (Intel/Havok), about the beginning of time (let there be light), creation (Designing API), it is about existence and life (ANIMATION), about humans ("Newbies"), human behavior (ALGORITHM) and "soul" (Source Code)

[MISSING-REPEAT]

both tales, tho completly unrelated, progress chronologically and coincidence in "spirit",
follow very specific and yet very different themes, but still, they both 'come up' as "true"


but hey,
dont forget.. the algorithms are still real!



..then, i discovered Wikipedia was wrong, and after carefully studying the rest of the related information.. well after all that it was kind of easy to see what was going on, but couldn't really try any of this because i was lazy to collect all the data and make simulator myself (giggles)




have you tried his little program.. its pretty interesting what he manages to do with it.. predictions and stuff.. and it looks cool, just like some fractals, those pictures there, eh?

cheers