Predicting Next Recalculation

  1. Alkatran

    Alkatran 944
    Science Advisor
    Homework Helper

    I've recently been working on optimizing a solar-system simulator I wrote a year ago to allow me to add more moons. The issue I have (not surprisingly) is the orbit of moon's require a much lower time step to calculate.

    Trying to avoid this, I've change the simulation to no longer used a fixed time step. Instead of (wait x seconds, recalculating all positions, repeat) it now has a priority queue containing all pairs of planet and it recalculates each pair at different rates (the next calculation time is specified during the recalculation of position).

    I've managed to get it working, and it does work well. Moons mostly get more attention than the planets, and far off things like Pluto get almost no attention at all. However, I want to optimize the prediction of the next calculation time (some bodies are still getting the wrong amount of attention, mercury gets more than earth's moon for example).

    The current formula is simply the inverse of acceleration for the smaller planet, meaning planets being accelerated are more likely to be recalculated:
    nextTime += Math.min(b1.mass, b2.mass)/force; //(all units in SI)

    So I guess it all comes down to: what's a good function for predicting how often the forces need to be recalculated? (Currently assuming constant force between calculations and doing a simple x + vt + at^2/2)
  2. jcsd
  3. jim mcnamara

    jim mcnamara 1,563
    Science Advisor
    Gold Member

    Would it be worth considering the inverse of instantaneous angular acceleration as an optimization approach? It's a lot like your model but it is sensitive to changes in r over time. Yours doesn't appear to be....

    [tex]\alpha = lim_{\Delta t\rightarrow 0} \frac{\Delta\omega}{\Delta t}[/tex]

    Dynamcially repopulate your priority queue with those values for each object.
  4. Alkatran

    Alkatran 944
    Science Advisor
    Homework Helper

    I modified the priority to include absolute relative velocity (based on the simple idea that "hmmm, the units don't match"). The distribution is MUCH nicer now.
Know someone interested in this topic? Share this thead via email, Google+, Twitter, or Facebook

Have something to add?