Challenge Europa Challenge

boogabooga

Bug Crusher
Joined
Apr 16, 2011
Messages
2,999
Reaction score
1
Points
0
What do you mean 'refresh rate'?

My impression is that this isn't "real time" in the Orbiter sense. You put in your initial conditions and the gravity sources, and your program calculates your trajectory (position as a function of time) for some finite amount of time in the future. Correct?

The calculation takes on the order of 10 seconds on a personal computer then, correct?

You are not, for example, running 2 week simulations on a distributed-node research cluster, are you?

The 5-10 second thing hardly seems like a deal-breaker.
 

Keithth G

New member
Joined
Nov 20, 2014
Messages
272
Reaction score
0
Points
0
If you look at IMFD's Map program output, the display changes in a near continuous manner. To do this, the trajectory needs to be re-calculated around 20 times a second - or better. So, in this instance, the refresh rate would be > 20/s. For my Mathematica used integrator, the refresh rate is around 0.1/s - i.e., at least 200 times slower than IMFD.

No, I am not doing this calculations on a supercomputer cluster. A humble MacBook Pro suffices.

No, the 5-10 seconds isn't a deal breaker. But around 1 second or less would be better.
 
Last edited:

boogabooga

Bug Crusher
Joined
Apr 16, 2011
Messages
2,999
Reaction score
1
Points
0
If you look at IMFD's Map program output, the display changes in a near continuous manner. To do this, the trajectory needs to be re-calculated around 20 times a second - or better.

Yes, but does it need to?

You have established the accuracy of Orbiter's integration scheme in that you can get a predictable, repeatable trajectory with a duration of several weeks to months. So why refresh the map so often?

Perhaps there would be a niche for generating a very high quality trajectory prediction with a very low refresh rate.
 

Keithth G

New member
Joined
Nov 20, 2014
Messages
272
Reaction score
0
Points
0
You have established the accuracy of Orbiter's integration scheme in that you can get a predictable, repeatable trajectory with a duration of several weeks to months. So why refresh the map so often?

Perhaps there would be a niche for generating a very high quality trajectory prediction with a very low refresh rate.

I agree.
 
Last edited:

Keithth G

New member
Joined
Nov 20, 2014
Messages
272
Reaction score
0
Points
0
What advice would you give to someone who would develop a new online n-body integrator MFD for use in Orbiter?

Advice for someone wanting to develop a new online n-body integrator? Here are some comments - assuming that the primary design ethos is high accuracy.

1. The specific 'kind' of integrator - whether a symplectic integrator or Runge Kutta - isn't hugely important so long as a suitable time-step size is chosen and one uses 'explicit' integrators. Generally, I use an explicit symplectic fourth-order integrator - see http://www.orbiter-forum.com/showthread.php?t=35489

2. When far away from a gravitating body, it is sufficient to use a time-step of around 1 hour. If close to a gravitating body, then trajectories are much more highly curved, and a much small time-step is needed. Generally, I use a time step of 30 seconds close to a gravitating body.

3. The core of the n-body integrator is the force calculations. The force calculations need to use accurate positions of the planets and moons. If working in the Jupiter system, for example, an accurate model of the positions of Jupiter and the four Galilean moon (Callisto, Ganymede, Europa and Io) is necessary. One also needs to know the position of the Sun with high precision. With less precision, the position of other Solar System bodies - e.g., Saturn, Uranus and Neptune and so on - is also needed because, believe it or not, these bodies provide significance perturbations.

4. There are two basic ways of getting accurate planet/moon positions. The easiest - and fastest - way of doing this is to take a snap-shot of the state-vectors of these bodies from Orbiter at the start of the integration period. Then, co-integrate the position/velocities of these bodies - along with those of the spacecraft. Over time, around 30 days or so, the co-integration model's estimate of planet/moon positions begins to slip a little - perhaps by a few hundred km from Orbiter's ephemeris projections. But, generally speaking, it is good enough for integration periods of around 30 days or less. It becomes very accurate for integrations just a few days ahead.

5. The second way of calculating positions is even more accurate, but very slow in comparison with the co-integration technique: one uses the same ephemerides for planet/moon positions as used in Orbiter. To do this one can leverage the same planet moon dlls that Orbiter uses. Or one can write bespoke routines that employ the same ephemerides that Orbiter uses (e.g., for the Jovian system, VSOP87 and Galsat). For the Jupiter system, a set of bespoke routines 'C' can be found here: http://www.orbiter-forum.com/showthread.php?t=36189. These routines produce the same planet/moon positions as Orbiter to with 20 metres or so, In effect, there is no error here, and then the only source of error is very slight variations in the numerical integration for the position of the spacecraft. And with a suitably small step-size, those errors cam almost entirely be eliminated.

6. High accuracy integrators of this kind are most useful for performing manoeuvres with systems such as the Jovian and Saturnian systems. Here, gravitation perturbations can be complex. TransX's two-body calculations are not very accurate because of various 3-body effects; and IMFDs performance in these domains seems less than stellar.
 
Last edited:

boogabooga

Bug Crusher
Joined
Apr 16, 2011
Messages
2,999
Reaction score
1
Points
0
I've tried GMAT.
It's interesting, but you need access to Matlab in order to use the optimization.
 

Keithth G

New member
Joined
Nov 20, 2014
Messages
272
Reaction score
0
Points
0
I think 'boogabooga' is the resident GMAT expert here. And I have no direct experience of GMAT other than two failed attempts to install it on my Mac. But I have long thought that a trajectory designed within GMAT will work very well when executed within a system based on GMAT's underlying planetary ephemerides, but something will be lost in translating from a GMAT environment to an Orbiter environment. Not only do the coordinate systems of the two modelling environments differ slightly (and I've never full tracked down how to translate between the two), but notwithstanding that, the positions of planets and moons differ by circa 20 - 50 km. Orbiter's ephemerides are based on VSOP87 which, as the name suggests is based on an old (JPL) ephemeris dated to around the mid-1980s. GMAT, on the other hand, uses a much more recent JPL ephemeris which is based on much more recent data. (Not that the older VSOP87 theory is at all bad or unrealistic - its just that it isn't quite as good as the new JPL ephemerides.) For very accurate work - i.e., sub < 10 km targeting - using a GMAT ephemeris system is never going to work well within Orbiter. But if one doesn't require that sort of precision, then a GMAT-based mission design should work just as well in Orbiter (provided that one knows how to move between the two slightly different coordinate systems).
 
Last edited:
Top