Drawing a trajectory with multiple gravitational soures.

[Nagransham]

Hi there guys.

As the title implies I'm trying to draw a trajectory on the screen (yes, this is indeed about programing :P) involving multiple sources of gravity.

Here is my dilemma: Since I'm working with an update loop there would be no problem to just simulate an object and having it leave a trail. However it would have to travel the whole relevant distance in order to show the complete trajectory. This is problematic because the trajectory depents on input, so it has to be able to change instantly (as in a few ms / a single update) and needs to be drawn completely, instantly.

I found some formulas that looked promising, which seem to be able to do a lot of stuff with very little information and calculation, however I'm pretty sure i didn't find anything involving multiple sources of gravity. And frankly I'm not sure if there even is such a thing.

Luckily the only thing i need to make this work is the ability to find out where an object will be after a given time. And this, at least to me, sounds like it's far easier to do. Because then i can just play connect the dots and I'm ready to go.

Unfortunately I'm not really sure how to do this :/



So... i guess my question is this:

How could i figure out where a given object (providing it's starting position, velocity and direction) is after a given time, while beeing affected by multiple sources of gravity ?



Also: it's a little hard to figure out where to post this since it's math and also physics... so... if I'm totally off here, feel free to tell me.

I hope i was able to get my question across, since I'm terrible at talking about things i don't fully understand in the first place ;) Also english is not my native language, so show mercy :)

 

[dauto]

You need to find the trajectory step by step. There is no way around that for a general configuration with multiple sources. If the sources are fixed than I think a modern computer ought to be able to do it in a fraction of a second to a reasonable precision.

 

[Nagransham]

Yea i figured as much. Now, the whole "connect the dots" thing is step by step :P

The problem is that it has to run on a phone and calculating and drawing all the steps every single update could become too much rather fast. I'm really worried about slower speeds, for example orbiting a planet far out. Because then, in order to show the whole path, i'd have to calculating insane amounts of steps. Of course for this particular scenario there are other solutions, but as soon as it stop beeing an orbit things get ugly.

I just hoped to find a way to skip a few steps withing each update without losing precision. Well i guess i could test it and see how much i can drop but I'm pretty sure it'll get out of hand rather quickly :/

Even expensive calculations can be worth it if i just have to do a few of them, so any non-ideal solution that might give this whole thing an edge can help.

 

[dauto]

Use an adaptive time step. Short time steps when needed, long ones whenever possible. I'll try to dig out the formula used to determine the ideal time step. It's been a while since a last saw an algorithm that required an adaptive time step.

 

[jtbell]

One popular algorithm that uses an adaptive stepsize is Runge-Kutta-Fehlberg. Google for it. I used it several years ago to calculate gravitational trajectories in a Fortran program.

This is a general algorithm for solving differential equations numerically. To use it, you'll have to (a) set up a system of differential equations that basically says F = ma in vector form for the object that you want to "move," and (b) convert the resulting second-order differential equations into an equivalent set of first-order differential equations that you can encode into the RKF algorithm. I suspect there are some web sites out there with the details for exactly this problem.

 

[D H]

Runge Kutta Fehlberg is notoriously lousy for orbital mechanics. It oftentimes goes bonkers and yields ridiculously bad results.

A nice package that uses adaptive integration techniques (multiple such techniques; the integrator decides which is best) is the Livermore Solver for Ordinary Differential Equations, LSODE and its variants. You can get it from SourceForge (http://lh3lh3.users.sourceforge.net/solveode.shtml) or directly from Lawrence Livermore (http://computation.llnl.gov/casc/software.php ).

Another good integrator is Gauss-Jackson. This is a fixed step size integrator, but it is very good at orbital mechanics when the restrictions of a fixed step size are valid. Here's a simple MATLAB implementation: http://www.mathworks.com/matlabcent...ckson-eighth-order-ode-solver-fixed-step-size.

 

[Nagransham]

I'm impressed. Not only does one actually get an answer here (this goes out to pretty much every other physics forums i ever visited) but you guys are fast too.

Not only that but now you show knowledge in programing too. Cool.

Anyway, i'll need some time to dig through that. Thanks for the keywords and links guys, that's probably the best solution there is, at least i can't imagine it getting better.

Now, i'll look into all of that and if i mess up i'll be back :P

 

[jtbell]

I agree with D F that if you're looking for precision, RKF isn't the way you want to go, except maybe as a first version that you can easily upgrade to a better algorithm if you set up the interface properly between the differential-equation-solver and the rest of your program.

As I recall, in my old program I could watch planetary orbits slowly spiral inwards towards the sun, because the errors in the RKF algorithm tended to decrease the overall energy of the system. (Or maybe the error was in the other direction, and the orbits spiraled outwards? It was a long time ago.)

 

[Nagransham]

Well it's just for drawing a trajectory, the actual objects will be simulated. So if the error margin is small enough it won't matter all that much. But then again, slow passages might become a problem since you'd need a rather small time step and hence many calculations and that could then add up to visible errors in the trajectory.

That said, i didn't have time to look into either of the suggested things, so feel free to ignore my blabbering :)

 

[Nagransham]

Well... i took some time and looked into the links and infos you guys provided and I'm not really sure on how helpful those are. Mostly because I'm not understanding any of it :|

I looked into that mathlab implementation you linked me and I'm afraid it'll take me a week to even understand what the code does...

Looks like i really have to refresh my math, huh ?