Moon.cfg in orbiter beta

[tblaxland]

the difference between ICRF and EME2000 (Earth Mean Equator) is so small that it probably doesn't matter in the Orbiter.

I agree.

Based on the documentation, the origin of right ascension should be the vernal equinox. (Intersection of ICRF and ecliptic)

Yeah, I agree, my misunderstanding (Note to self: top up on coffee before attacking scientific papers...)

It seems that the LAN of the Earth's equator respect to ICRF is 90 degrees and the inclination is zero (in the epoch of J2000). Where as the LAN of the Earth's equator respect to ecliptic is 0 degrees and the inclination is 23.5

I agree with two minor differences: the LAN of the ecliptic w.r.t. Earth's equator is 0 (not the other way around), and I am using 23° 26' 21.448'' as the obliquity of the ecliptic (per our discussion above).

I haven't computed any values but that sounds like it's correct. Note that LAN has changed 90 degrees as well.

If I understood Martin correctly, SidRotOffset should be measured from the LAN of the equator in the precession axis frame. In the case of the Earth the precession axis frame is aligned with the ecliptic frame and the LAN of the ecliptic w.r.t. to the equator is 0. We established above that the LAN of the equator in the ICRF is 90 deg and 3.3186912 is the offset from the LAN of Earth's equator in the ICRF, so the total offset from the LAN of the precession axis frame is 3.3186912 + PI/2 = 4.8894875.

 

[tblaxland]

I've attached a drawing to illustrate what I have described above. Hopefully it makes sense (the green frame is ICRF, black is ecliptic). BTW, I am also working on the basis of "PrecessionLAN = LAN of ecliptic wrt plane normal to precession axis (precession plane)" and "L0 = LAN of precession plane wrt equator", consistent with the discussion in posts 69-71.

So here are my values for Earth from the IAU/IAG data (beta values presented in comments for comparison):

; === Rotation Elements ===
SidRotPeriod = 86164.09623 ; (23h 56m 4.09623s) ;86164.09        ; 23h 56m 4.09s (check new reference: 23h 56m 4.0906s)
SidRotOffset = 4.88948754      ; IAU J2000
Obliquity = 0.409092804 ;0.40909280         ; IAU J2000
LAN = 0                        ; IAU J2000
LAN_MJD = 51544.5              ; J2000
PrecessionPeriod = -9412846    ; precession period (days) = 25771.5 years

The biggest difference is in SidRotPeriod and I am curious where the value of 23h 56m 4.0906s came from.

 

[jarmonik]

The biggest difference is in SidRotPeriod and I am curious where the value of 23h 56m 4.0906s came from.

The higher one is a star fixed rotation period and the lower one is LAN fixed rotation period.

Star to Star: 23h 56m 4.098 903 691
Vernal equinox to Vernal equinox: 23h 56m 4.090 530 832 88 (not the same as star to star due to shift of vernal equinox)

http://en.wikipedia.org/wiki/Rotation_period

EDIT: Just noticed that 23h 56m 4.0906s is the initial value in Earth.cfg, so it seems that it's not correct.

 

[Chode]

The biggest difference is in SidRotPeriod and I am curious where the value of 23h 56m 4.0906s came from.

Pre-precession Orbiter versions assumed that the vernal equinox is fixed in space. In that case, you would want SidRotPeriod to be the period from vernal-equinox to vernal-equinox, so the sun would pass overhead roughly around local noon on the Earth. In that case, the best value to use in Orbiter would be SidRotPeriod = 86164.090 531 as stated by jarmonik. Pre-precession versions of Orbiter used values of 86164.09 (Orbiter 2006-P1) and 86164.0906 (in more recent betas). While the value of 86164.09 was acknowledged as being only an approximation, the value of 86164.0906 is only about 0.00007 seconds off from the best known value at present, and represents an error of less than one degree in 10,000 years. So I hope that clarifies where the .0906 came from.

Regards

 

[tblaxland]

Thanks for the info guys. It seems the higher value should be used since Orbiter subtracts the precession of the equinoxes now.

The difference between this value:

Star to Star: 23h 56m 4.098 903 691

and mine seems to be the difference between the rate of mean solar time and the rate of terrestrial time. I think that the value in terrestrial time (23h 56m 4.09623s) should be taken since I expect that would be the time scale used by ephemerides calculations such as VSOP.

EDIT: Reviewing that further, I am still confused. Because of the slowing rotation of the Earth, UT1 should tick slower than TT so the period measured in TT should be longer by about 0.00174s/day (see here) or 23h 56m 4.10064s. I assume I've gone wrong somewhere, but where?

EDIT2: I think I have it now. The rotation rate in the IAU/IAG document includes a correction for the precession rate. I calculate that to increase the stellar day by 0.004212s, giving a total stellar day of 23h 56m 4.10044s (TT). That agrees much better with the period I calculated above for the stellar in TT (there is a reasonable variation in the tick speed of UT1 wrt TT so I would place more weight on the IAU/IAG derived value). On that basis I recommend using a period of 23h 56m 4.10044s. That should also work well with the VSOP (as far as having rotation data match ephemerides) because as far as I can determine VSOP would be based on the TDB time scale which is functionally equivalent in terms of tick speed to TT.

 

[jarmonik]

I have compared lunar rotation parameters from this post http://orbiter-forum.com/showpost.php?p=97945&postcount=58 to AGC model after translating vessel's state vectors to different epoch of 01-Jan-1969 using these equations http://www.mps.mpg.de/homes/fraenz/systems/systems2art/node3.html

The error in vessel's geocentric longitude and latitude is approximately 0.002 degrees (in epoch). So, the lunar rotation parameters should also fit in AGC scenario in theory.

When a statevector information is transfered from the Orbiter into the AGC, it could be easily translated into a different epoch via vector-matrix multiplication, but the real problem is when a data is transfered visually by a user from a navigation MFD into the AGC. In that case the Orbiter and the AGC must use the same epoch, otherwise the data would be invalid. Currently the Moon and the Earth configuration files are altered to match the epoch of AGC however Moon.dll and Earth.dll are unchanged and still refering to J2000.

But this is really not an issue to worry about in this thread.

 

[tblaxland]

But this is really not an issue to worry about in this thread.

Maybe not but while I'm thinking of it, would it be feasible to use a wrapper dll to do the epoch conversion? Eg, Project Apollo could ship with a custom Moon.cfg (it does anyway IIRC) that references a wrapper dll, say ProjectApolloMoon.dll, which would load the base install's Moon.dll and use it to get CELBODY data after doing the epoch conversion.

 

[jarmonik]

Maybe not but while I'm thinking of it, would it be feasible to use a wrapper dll to do the epoch conversion? Eg, Project Apollo could ship with a custom Moon.cfg (it does anyway IIRC) that references a wrapper dll, say ProjectApolloMoon.dll, which would load the base install's Moon.dll and use it to get CELBODY data after doing the epoch conversion.

I actually allready wrote such wrapper during last night but haven't had time to test it yet, but anyway, it's still unclear how this would effect in behaviour of MFDs. There could be still some hardcoded epochs in MFDs.

It's possible that only a few MFDs are required during a mission and those could be modified to display data in different epochs. That could also solve the problem without a need to alter the epoch from the Orbiter.

 

[Chode]

Another thing to consider is that the IAU model for Earth may not be all that accurate. A quote from the IAU working group report: "

Expressions for the Sun and Earth are given to a similar precision as
those of the other bodies of the solar system and are for comparative purposes only."

ref here:
http://astrogeology.usgs.gov/Projects/WGCCRE/WGCCRE2003preprint.pdf
​

On that basis I recommend using a period of 23h 56m 4.10044s. That should also work well with the VSOP (as far as having rotation data match ephemerides) because as far as I can determine VSOP would be based on the TDB time scale which is functionally equivalent in terms of tick speed to TT.

That looks like a good number, but I would test it in Orbiter to see if it gives consistent results.

My approach to determining the best values for SidRotOffset and SidRotPeriod in Orbiter is based on keeping everything self-consistent:

Earth: the sun should be where you'd expect around local noon over a long span of time.

Moon (and all other tidally locked bodies, which covers the majority of all moons):
keep meridian pointed toward parent body.

Other planets and moons: find the best fit to IAU models

Comments welcome.

Regards

 

[jarmonik]

Another thing to consider is that the IAU model for Earth may not be all that accurate. A quote from the IAU working group report: "

Certainly not, it doesn't include any nutations.

---------- Post added at 01:51 PM ---------- Previous post was at 01:50 PM ----------

Another thing to consider is that the IAU model for Earth may not be all that accurate. A quote from the IAU working group report: "

Certainly not, it doesn't include any nutations.

---------- Post added at 03:03 PM ---------- Previous post was at 01:51 PM ----------

This should give pretty good information about equator of the Earth. http://www.mps.mpg.de/homes/fraenz/systems/systems2art/node3.html

 

[tblaxland]

Another thing to consider is that the IAU model for Earth may not be all that accurate. A quote from the IAU working group report:

I agree, and second Jarmonik's comment, although as a mean they seem to work well with other data that I can find. An Earth.dll that used IERS data would of course be better but even their predictions only run out 12 months. And we have to wait until Martin adds support for that in any case.

That looks like a good number, but I would test it in Orbiter to see if it gives consistent results.

My approach to determining the best values for SidRotOffset and SidRotPeriod in Orbiter is based on keeping everything self-consistent:

I agree. In particular, I am interested in checking Earth surface based observations of the other planets relative to the stars and comparing it with other astronomical software.

 

[tblaxland]

It looks like the Mean Obliquity is 23° 26' 21.448'' http://www.geoastro.de/obliquity/index.html the same information can be found from wikipedia.

Wouldn't be bad idea to use that data to double check the orientation of ICRF. However, the difference between ICRF and EME2000 (Earth Mean Equator) is so small that it probably doesn't matter in the Orbiter.

I finally got around to checking Allen's data against what you provided. I get an obliquity of the ecliptic in the ICRF of 23°25'51.95'', a difference of 29.5 arcseconds. I'm not sure if that is worth worrying about or not.

 

[jarmonik]

I finally got around to checking Allen's data against what you provided. I get an obliquity of the ecliptic in the ICRF of 23°25'51.95'', a difference of 29.5 arcseconds. I'm not sure if that is worth worrying about or not.

I agree. It's not even close but there's no need to worry about it.

 

[tblaxland]

I agree. In particular, I am interested in checking Earth surface based observations of the other planets relative to the stars and comparing it with other astronomical software.

Looking at Stellarium and Celestia:

Stellarium: does not support precession of Earth's equinoxes so not useful for testing (it is listed as a future feature though)
Celestia: supports precession of Earth's equinoxes but does not include data for it in the vanilla install (there is some commented out data in the ssc file but the rotation period is the same as for the non-precessing period - 23h 56m 4.09s which I think we have established is not the correct value). I think precession would be modelled if I used SPICE kernels but I am getting into unknown territory for me.

Thinking about this, I should get pretty obvious differences between planet positions using Orbiter's precessing model and the Celestia or Stellarium non-precessing models if the period is out by 0.1s. I don't have a beta install up and running yet but I'll test it out when I do.

In the meantime, can anyone suggest any other software that models precession of Earth's equinoxes that I could use as a basis for comparison?

I agree. It's not even close but there's no need to worry about it.

Yep, I'll continue to use the 23° 26' 21.448'' value. I guess the invariable plane data in Allen's is out since I am converting from ecliptic/equinox -> invariable plane -> ICRF.

 

[jarmonik]

In the meantime, can anyone suggest any other software that models precession of Earth's equinoxes that I could use as a basis for comparison?

How about JPL Horizon ? It can compute Observer tables with R.A. and Dec information for a specified surface location.

1. Get a state vectors of Mars from Horizon for specified date.
2. Get R.A. and Dec of Mars for the same date.
3. Compute R.A. and Dec from the state vectors using Orbiter
4. Compare R.A. and Dec

I have never used Horizon to acquire any information in Observer mode but it should work.

 

[mjessick]

> In the meantime, can anyone suggest any other software that models precession of Earth's equinoxes that I could use as a basis for comparison?

edit: also useful for "In particular, I am interested in checking Earth surface based observations of the other planets relative to the stars and comparing it with other astronomical software" but you might have to go to the trouble of installing and setting up the JPL ephemeris system for the planets. NOVAS internally just has methods for the Earth and Solar ephemerides for purposes of checking the NOVAS installation.

I'm not certain, but I imagine that the NOVAS C language version likely has an internal algorithm for this (doesn't require the JPL ephemeris). (Yes: see precession and nutate in file novas.c)
http://aa.usno.navy.mil/index.php
This is software essentially the same as that used to generate the Astronomical Almanac tables (when coupled with the JPL Ephemeris, though.)

If not, the Astronomical Almanac or the Explanatory Supplement to the A.A. would have a somewhat standard low precision algorithm. See discussion in this paper by Simpson at Goddard:

AN ALTERNATIVE LUNAR EPHEMERIS MODEL FOR ON-BOARD​

FLIGHT SOFTWARE USE
http://www.davidgsimpson.com/software/slunar.pdf
(Interesting in its own right. Simple polynomial curve fit to the Moon's position relative to Earth expressed directly as J2000 cartesian coordinates. Saves having to do the rotation from mean of date to J2000 and from ecliptic to equatorial and conversion from polar to cartesian. It is quoted as having about 3 times the error of the Astronomical Almanac's low precision formula and using all the rotations mentioned.)

IAU's Standards Of Fundamental Astronomy (SOFA) Libraries (Fortran and C):
http://www.iau-sofa.rl.ac.uk/

 

[tblaxland]

^ Thank you gents. I probably won't get to look at this again until next week but I'll let you know what I find.

 

[tblaxland]

How about JPL Horizon ? It can compute Observer tables with R.A. and Dec information for a specified surface location.

Unfortunately that does not help because RA and Dec are largely independent of surface location, for any large distance anyway. Any errors would be lost in the noise of errors in VSOP87 ephemerides and JPL ephemerides.

I'm not certain, but I imagine that the NOVAS C language version likely has an internal algorithm for this (doesn't require the JPL ephemeris). (Yes: see precession and nutate in file novas.c)
http://aa.usno.navy.mil/index.php

NOVAS-C looks promising so I'll do some work in that direction.

In the meantime I have been giving some consideration to my estimate of Earth's rotation period of 23h 56m 4.10044s. My thought was that the precession angular velocity cannot be simply added to the body angular velocity. They should be vector summed instead, which for the common case of Tp >> Ts would be approximated by adding the precession angular velocity multiplied by the cosine of the obliquity. This correction yields a period of 23h 56m 4.10007s. Logically, the higher the obliquity the less effect the precession of equinoxes will have on the observed star-star rotation period.

This also makes me think that a similar correction should be made to equation 7 of precession.pdf (see attached).

 

[jarmonik]

Unfortunately that does not help because RA and Dec are largely independent of surface location, for any large distance anyway. Any errors would be lost in the noise of errors in VSOP87 ephemerides and JPL ephemerides.

Sorry, I mixed-up the R.A. and Azimuth. But the Horizon is able to give the azimuth and elevation as well.

Azi_(a-appr)_Elev = Airless apparent azimuth and elevation of target. Corrected for light-time, the gravitational deflection of light, stellar aberration, precession and nutation. Azimuth measured North(0) -> East(90) -> South(180) -> West(270), elevation with respect to plane perpendicular to local zenith direction.

My thought was that the precession angular velocity cannot be simply added to the body angular velocity....
...This also makes me think that a similar correction should be made to equation 7 of precession.pdf (see attached).

I agree. But I am not sure is the equation 7 proper place. How about adding the correction directly in the value of T_s before the equation 7 ?
See posts 42 and 46.

 

[tblaxland]

Sorry, I mixed-up the R.A. and Azimuth. But the Horizon is able to give the azimuth and elevation as well.

Ah, so it can. I didn't see that before.

I agree. But I am not sure is the equation 7 proper place. How about adding the correction directly in the value of T_s before the equation 7 ?
See posts 42 and 46.

Funny how we have come full circle and I didn't even realise it. The idea of defining a star-to-star rotation period has been bothering me because the angle Lrel was never measured in the same plane as the angle phi and I couldn't see how the two could be added together. What if we were to change to defining Ts as the node-to-node period (this is how the IAU/IAG do it). Eq 7 would become phi(t) = 2*pi*t/Ts + Delta_phi. I make the node-node rotation period of the Earth to be 86164.09170 s(TT) by the IAU/IAG data. This is consistent with a value of 86164.090 531 s(UT1) that was quoted above.