<p>You can begin with any starting point. The numerical integration process doesn't &quot;know&quot; anything about ellipses, perhelion, or what the orbit is supposed to look like. The same iterative process is applied at all points on the orbit, so you can start anywhere.</p>
<p>It is a good idea to use astronomical units (AU, Solar mass, years) rather than SI units. With SI units, the intermediate calculations can involve very large and very small numbers and this can result in a loss of accuracy.</p>
<p>A symplectic integrator should do well enough, but note that the NASA values include all kinds of perturbations (by other planets, by the non-spherical sun etc) and a two-body model isn't going to match perfectly. Also remember that the sun is also moving, so if your x-y-z are relative to the centre of the sun, that is an issue. To deal with it, you would need to include other planets and the sun in your model.</p>
<p>For speed you probably will want to move to a &quot;real&quot; programming language.  Spreadsheets are optimised for business calculations, rather than solving differential equations.</p>

CC BY-SA 4.0
2022-07-19T07:57:16.850Z
Thanks for that. JPL offers the following choice of state vector units: km and seconds; AU and days; km and days. However, they give GM for the Sun in units of $\mathrm{km}^{3}\mathrm{s}^{-2}$. I've tried using this value of GM in the spreadsheet with distances in km, but the results come out exactly the same as with using metres and seconds. I haven't been able to find a figure for GM in AU and some other time units (days or years?).
Peter
CC BY-SA 4.0
2022-07-19T08:12:25.777Z
in units of "sun mass, AU and years"  G = GM = 4pi^2
James K
CC BY-SA 4.0
2022-07-19T09:36:43.807Z
Well, I never saw that coming. What an amazing result.
Peter
CC BY-SA 4.0
2022-07-23T18:23:48.610Z
@Peter What James said about GM is true, but it depends on how you define "AU" & "year". See  https://en.wikipedia.org/wiki/Gaussian_year & links therein.
PM 2Ring
CC BY-SA 4.0
2022-07-23T19:01:11.147Z
Yes, there is a slight of hand,  If you define "Year" as the time that a body in circular 1 AU orbit around a mass of the sun, you can see how the various units are related, and so the G=4pi^2 result becomes somewhat less surprising.  Astronomers conventionally take 1 year = 365.25 days (exactly) for which G is only very close to 4pi^2
James K
CC BY-SA 4.0
2022-07-19T06:32:19.003Z
2022-07-19T06:32:19.003Z
James K
<p>I'm modelling planetary orbits using a spreadsheet and Feynman's numerical method given <a href="https://www.feynmanlectures.caltech.edu/I_09.html" rel="nofollow noreferrer">here</a>. I have put together a spreadsheet (10,000 rows) to model Mars' orbit in three <span class="math-container">$\left(x,y,z\right)$</span> dimensions. I'm using SI units with a time interval of 3600 seconds. I'm using initial state vector data from JPL Horizons. I believe Feynman's method is called leapfrog integration. I've also tried the Runge-Kutta method, but with no significant improvement in accuracy.</p>
<p>In terms of the orbit cycle, does it matter when I take the initial JPL Horizons data? Aphelion or perihelion, for example, or some other point in the orbit?</p>
<p><strong>EDIT</strong>. Just to be clear what I'm asking. The first row of my spreadsheet uses state vector data <span class="math-container">$\left(\mathbf{x},\mathbf{y},\mathbf{z},\mathbf{v_{x}},\mathbf{v_{y}},\mathbf{v_{z}}\right)$</span> from JPL Horizons for an arbitrary date and time. I've chosen 2000-Jan-01 12:00:00.0000 TDB. Will I get more accurate results if I use a date and time for a specific point in Mars' orbit? Aphelion or perihelion, for example? If the answer is yes, an explanation would be useful.</p>

CC BY-SA 4.0
2022-07-18T07:21:25.327Z
Don't use SI units!  They cause all sorts of floating point issues.  AU, Solar mass, year are much better set of units for solar system modelling than metre, kg, second.
James K
CC BY-SA 4.0
2022-07-18T13:38:36.237Z
As I note in https://astronomy.stackexchange.com/questions/2416/where-can-i-find-a-set-of-data-of-the-initial-conditions-of-our-solar-system/13491#13491 you might want to use the same initial conditions JPL does.
Barry Carter
CC BY-SA 4.0
2022-07-18T13:49:12.480Z
Yes, that's Leapfrog. There are a few variants of Leapfrog. I illustrate a couple of them here: https://astronomy.stackexchange.com/a/48477/16685
PM 2Ring
CC BY-SA 4.0
2022-07-18T13:53:29.687Z
Numerical integration can use any starting point. Analytical orbit calculations tend to use perihelion, because that's where the mean, eccentric, and true anomalies are measured from. However, there are practical issues in determining the exact moment of Earth's perihelion, as I mention here: https://astronomy.stackexchange.com/a/49605/16685
PM 2Ring
CC BY-SA 4.0
2022-07-18T15:51:34.300Z
@PM2Ring - I was surprised that the Runge–Kutta method wasn't (for me) much of an improvement on leapfrog. It took me ages to realise that comparing the radius of my predicted position and JPL's isn't very useful. If the Earth was a perfect sphere and Tom was standing on a table next to me our radii would be slightly different. If Tom travelled to the opposite side of the planet our radii would be the same though our positions on the Earth's surface would be very different.
Peter
CC BY-SA 4.0
2022-07-18T16:11:59.303Z
Leapfrog is symplectic, Runge-Kutta isn't. https://en.wikipedia.org/wiki/Symplectic_integrator That gives Leapfrog an advantage for simple orbit integrations like this: your orbit conserves energy, so it won't spiral in or out due to accumulated integration errors. 4th order Runge-Kutta can be better than  plain Leapfrog, especially with highly eccentric orbits, but 4th order Leapfrog is even better. ;)
PM 2Ring
CC BY-SA 4.0
2022-07-18T20:12:59.340Z
Many useful suggestions in the comments :) but I am kind of missing the point of the question. What is it asking exactly?
Prallax
CC BY-SA 4.0
2022-07-19T06:07:39.923Z
@Prallax - I've edited my question to make it clearer what I'm asking.
Peter
CC BY-SA 4.0
2022-07-19T15:07:46.077Z
If I were a pathological nitpicker, I'd point out that coordinates not from the "epoch" are given as polynomial approximations to the real solution and are therefore *trivially* less "accurate". Of course this "inaccuracy" is vastly smaller than the inaccuracy of the positions themselves.
Barry Carter
<orbital-elements><ephemeris><modeling>
Orbital modelling - best choice for initial JPL Horizons data?
Peter
# Orbital modelling - best choice for initial JPL Horizons data?

(Asked by: username_0 on 2022-07-18)

I'm modelling planetary orbits using a spreadsheet and Feynman's numerical method given [here](https://www.feynmanlectures.caltech.edu/I_09.html). I have put together a spreadsheet (10,000 rows) to model Mars' orbit in three $\left(x,y,z\right)$ dimensions. I'm using SI units with a time interval of 3600 seconds. I'm using initial state vector data from JPL Horizons. I believe Feynman's method is called leapfrog integration. I've also tried the Runge-Kutta method, but with no significant improvement in accuracy.

In terms of the orbit cycle, does it matter when I take the initial JPL Horizons data? Aphelion or perihelion, for example, or some other point in the orbit?

**EDIT**. Just to be clear what I'm asking. The first row of my spreadsheet uses state vector data $\left(\mathbf{x},\mathbf{y},\mathbf{z},\mathbf{v\_{x}},\mathbf{v\_{y}},\mathbf{v\_{z}}\right)$ from JPL Horizons for an arbitrary date and time. I've chosen 2000-Jan-01 12:00:00.0000 TDB. Will I get more accurate results if I use a date and time for a specific point in Mars' orbit? Aphelion or perihelion, for example? If the answer is yes, an explanation would be useful.

**Tags:** orbital-elements, ephemeris, modeling
> **Comments:**
> **username_1**: Don't use SI units!  They cause all sorts of floating point issues.  AU, Solar mass, year are much better set of units for solar system modelling than metre, kg, second.  
> **username_2**: As I note in https://astronomy.stackexchange.com/questions/2416/where-can-i-find-a-set-of-data-of-the-initial-conditions-of-our-solar-system/13491#13491 you might want to use the same initial conditions JPL does.  
> **username_3**: Yes, that's Leapfrog. There are a few variants of Leapfrog. I illustrate a couple of them here: https://astronomy.stackexchange.com/a/48477/16685  
> **username_3**: Numerical integration can use any starting point. Analytical orbit calculations tend to use perihelion, because that's where the mean, eccentric, and true anomalies are measured from. However, there are practical issues in determining the exact moment of Earth's perihelion, as I mention here: https://astronomy.stackexchange.com/a/49605/16685  
> **username_0**: @PM2Ring - I was surprised that the Runge–Kutta method wasn't (for me) much of an improvement on leapfrog. It took me ages to realise that comparing the radius of my predicted position and JPL's isn't very useful. If the Earth was a perfect sphere and Tom was standing on a table next to me our radii would be slightly different. If Tom travelled to the opposite side of the planet our radii would be the same though our positions on the Earth's surface would be very different.  
> **username_3**: Leapfrog is symplectic, Runge-Kutta isn't. https://en.wikipedia.org/wiki/Symplectic_integrator That gives Leapfrog an advantage for simple orbit integrations like this: your orbit conserves energy, so it won't spiral in or out due to accumulated integration errors. 4th order Runge-Kutta can be better than  plain Leapfrog, especially with highly eccentric orbits, but 4th order Leapfrog is even better. ;)  
> **username_4**: Many useful suggestions in the comments :) but I am kind of missing the point of the question. What is it asking exactly?  
> **username_0**: @Prallax - I've edited my question to make it clearer what I'm asking.  
> **username_2**: If I were a pathological nitpicker, I'd point out that coordinates not from the "epoch" are given as polynomial approximations to the real solution and are therefore *trivially* less "accurate". Of course this "inaccuracy" is vastly smaller than the inaccuracy of the positions themselves.  

---

## 1 answers

### Answer by username_1 on 2022-07-19. Score: 3 | Accepted answer

You can begin with any starting point. The numerical integration process doesn't "know" anything about ellipses, perhelion, or what the orbit is supposed to look like. The same iterative process is applied at all points on the orbit, so you can start anywhere.

It is a good idea to use astronomical units (AU, Solar mass, years) rather than SI units. With SI units, the intermediate calculations can involve very large and very small numbers and this can result in a loss of accuracy.

A symplectic integrator should do well enough, but note that the NASA values include all kinds of perturbations (by other planets, by the non-spherical sun etc) and a two-body model isn't going to match perfectly. Also remember that the sun is also moving, so if your x-y-z are relative to the centre of the sun, that is an issue. To deal with it, you would need to include other planets and the sun in your model.

For speed you probably will want to move to a "real" programming language. Spreadsheets are optimised for business calculations, rather than solving differential equations.

> **Comments:**
> **username_0**: Thanks for that. JPL offers the following choice of state vector units: km and seconds; AU and days; km and days. However, they give GM for the Sun in units of $\mathrm{km}^{3}\mathrm{s}^{-2}$. I've tried using this value of GM in the spreadsheet with distances in km, but the results come out exactly the same as with using metres and seconds. I haven't been able to find a figure for GM in AU and some other time units (days or years?).  
> **username_1**: in units of "sun mass, AU and years"  G = GM = 4pi^2  
> **username_0**: Well, I never saw that coming. What an amazing result.  
> **username_3**: @Peter What James said about GM is true, but it depends on how you define "AU" & "year". See  https://en.wikipedia.org/wiki/Gaussian_year & links therein.  
> **username_1**: Yes, there is a slight of hand,  If you define "Year" as the time that a body in circular 1 AU orbit around a mass of the sun, you can see how the various units are related, and so the G=4pi^2 result becomes somewhat less surprising.  Astronomers conventionally take 1 year = 365.25 days (exactly) for which G is only very close to 4pi^2  

---

