SDK Question CELBODY2 flags

[cristiapi]

Suppose that I want to write a CELBODY2 DLL to tell Orbiter where Deimos is.

The only working way I found is:
1) DLL1 calculates Deimos position wrt Mars;
2) DLL2 calculates Mars position wrt Sun;
3) DLL3 calculates Sun position wrt Solar System Barycenter.

All the 3 DLLs return the flags:
EPHEM_TRUEPOS | EPHEM_TRUEVEL | EPHEM_PARENTBARY | EPHEM_BARYISTRUE
and the result is correct.

I'd like to tell Orbiter the coordinates of Deimos directly wrt SSB.
Please, could somebody tell me which flags clbkFastEphemeris and clbkEphemeris should return?

Thank you
Cristiano

 

[Keithth G]

I'm not particularly familiar with the Orbiter SDK, but I suspect that you need three DLLs to specify the position of a Moon because of some fundamental distinctions that Orbiter appears to make between: a Star, a Planet, and a Moon.

This tripartite division is clearly evident in the Solar System configuration file. But it is also evident in the Orbiter's reliance upon the VSOP87 ephemeris solution for solar and planetary positions:

1. For the Sun, Orbiter makes use of the VSOP87B solution which gives the position of the Sun with respect to the Solar System Barycentre (which in the original VSOP87 theory is located at origin of the coordinate system of the theory).

2. For the Planets, Orbiter makes use of the VSOP87E solution which gives the location of the barycentre of each of the planetary systems in heliocentric coordinates.

3. Finally, for the Moons, Orbiter makes use of planet-centric measures of their orbital motion around the parent Planet. In calculating, the position of the Moons and the Planets with respect to the Solar System Barycentre (or, at least, the origin of the coordinate system), Orbiter ensures that barycentre of each of the planetary systems follows the trajectory specified by the VSOP87E solution - given the assigned masses of those bodies.

Now, there may be a way of short-cutting this approach. But I suspect that this tripartite view of the world is hard-wired into Orbiter's core algorithms. If you do manage to find a work-around, I would be interested in hearing of it.

 

[cristiapi]

1. For the Sun, Orbiter makes use of the VSOP87B solution which gives the position of the Sun with respect to the Solar System Barycentre (which in the original VSOP87 theory is located at origin of the coordinate system of the theory).

2. For the Planets, Orbiter makes use of the VSOP87E solution which gives the location of the barycentre of each of the planetary systems in heliocentric coordinates.

I read in "Astronomy and Astrophysics" 202, that only the E version is barycentric, all the other versions are heliocentric.

Now, there may be a way of short-cutting this approach. But I suspect that this tripartite view of the world is hard-wired into Orbiter's core algorithms.

I think the same, because it seems that all the flags in CELBODY2 allow to send coordinates that are referred to the parent body or to the barycentre of the parent body’s system.

If you do manage to find a work-around, I would be interested in hearing of it.

I hope that in the next version of Orbiter the coordinates can be expressed wrt the origin of the global reference frame.

P.S. Of course, one way of circumventing all of this may be to define all bodies as 'Stars' in the Solar System configuration file. In this case, Orbiter may interpret the DLL as something that returns the coordinates of the body with respect to the Solar System Barycentre.

I tried something like that for the Pluto System (including the barycentre of Pluto System as a fictitious massless body), but some MFDs don't work well.

 

[Keithth G]

I read in "Astronomy and Astrophysics" 202, that only the E version is barycentric, all the other versions are heliocentric.

Yes, I had 'E' and 'B' the wrong way around.

I tried something like that for the Pluto System (including the barycentre of Pluto System as a fictitious massless body), but some MFDs don't work well.

I guess we'll have to work with what we've got for the time being.

 

[cristiapi]

But I suspect that this tripartite view of the world is hard-wired into Orbiter's core algorithms.

I did an experiment to see whether the method used by Orbiter introduces any kind of error.

I wrote 3 DLLs:
1) Sun wrt SBB;
2) Pluto wrt Sun;
3) Nix wrt Pluto.

I wrote an MFD which read the state of Nix using oapiGetGlobalPos() at every simulation step. The MFD saves in a file the MJD and the coordinates of Nix (15 digits each number).

I calculated the position of Nix wrt SSB from outside Orbiter for the MJD saved in the file; I used exactly the same code written for the DLLs. The Nix position is given by: Nix_xyz + Pluto_xyz + Sun_xyz.

I expect to see exactly the same coordinates, whereas there are (small) fluctuations.
I sampled 379 point and the mean distance from the two points is 13.1 mm. Yes, the value is negligible, but the method seems to introduce some kind of "bias" which ships don't like too much when they land on a small body.

 

[Keithth G]

Unfortunately, we don't know what intermediate coordinate transformations Orbiter is performing. For all I know, it may take rectilinear coordinates (xyz) and convert to orbital elements and then, when you interrogate the system using oapiGetGlobalPos(), it may convert back to rectilinear coordinates. This would introduce some rounding error due to the imperfections of performing trigonometric functions in floating point arithmetic.

Or it could be something else entirely.

Simply put, Orbiter's internal calculations are a 'black box'.