Moon.cfg in orbiter beta

[martins]

The beta versions of orbiter (available at http://orbitervis.wiki.sourceforge.net/OrbiterPublicBeta ) have introduced some changes to the parameters in Moon.cfg. Most notably, the orientation of the moon has changed from (0.75049+0) rad to (4.78084319+2.17119075) rad (calculated as SidRotOffset + LAN), so there is a difference in rotational state of

0.75049 - (6.95203394-2pi) = 0.0816 rad = 4.68 deg.

There is also a small change in the obliquity value:

old: 0.0269 rad
new: 0.0274 rad

resulting in a difference of 0.029 deg.

The rotational period has not changed, so the offsets remain constant as a function of time.

The old values were guesswork on my part, while the new values have been contributed (by Chode, if I remember correctly) from IAU values, although I don't have precise source references. These changes have been present in the betas from an early stage.

I've been informed by the AMSO developer that this change would have a significant effect for all of the Apollo scenarios, so before I introduce the changes into the next release, I want to make sure that they are justified.

I would like to invite comments on the changes from anybody qualified to check them, and in particular from NASSP developers who will have to cope with the changes as well, if they are brought forward to the release version. This includes the absolute values, as well as their stability and rate of change over time, which has an impact on their validity during the Apollo era.

 

[jarmonik]

One problem is that precession period of the Moon's pole is about 18 years. That will make the LAN shift about 0.05 degrees per day. But since the inclination to ecliptic is only 1.5 degrees the error due to LAN shift is not huge.

 

[BrianJ]

Sorry to go a little off-topic here, but this seems like a good opportunity to raise a couple of points that have been bothering me regarding the moon.cfg Obliquity and LAN parameters in the current Orbiter version 060929.

I had a pretty careful look at these parameters while putting my Lunar Reconnaissance Orbiter add-on together, since the final lunar orbit of LRO is determined by the LAN parameter in particular.

In the moon.cfg it has the following in the "Physical parameters" section.

Obliquity =  0.02692024985275    ; rad(1.5424167)
LAN = 0                          ; ascending node of equator - CHECK!

1. In the Orbiter.pdf document p.99 (Planet Rotational parameters) it defines the LAN parameter as:
"LAN (Float) Longitude of projection of rotation axis onto reference plane [rad]"

Is that true? If it were true, I would expect to see the plane of the Moon's equator cut the ecliptic at 90deg and 270deg. However, using the "Visual Helpers" Target Equator display function, it looks like the plane of the Moon's equator cuts the ecliptic at 0deg and 180deg. Is the Orbiter.pdf definition correct?​

2. Again, using the "Visual Helpers" Target Equator display, and assuming the "direction" of the displayed green line runs in the same direction as the Moon's rotation, the ascending node (where the green line cuts the ecliptic going from South to North) is at 180deg, rather than 0deg.​

Well, I've probably got everything backwards, my apologies if so. But maybe not. Thought I ought to mention it.​

All the best,
Brian​

---------- Post added at 02:41 AM ---------- Previous post was at 01:52 AM ----------

Bah! Disregard point 2 above. I see from the other planet config files that the Rotational LAN parameter refers to the "longitude of solar transit" (not something I've ever heard of or can find a definition for elsewhere) which I assume is 180 degrees offset from the ascending node of the equatorial plane relative to the ecliptic.

Sorry!

 

[tblaxland]

One problem is that precession period of the Moon's pole is about 18 years. That will make the LAN shift about 0.05 degrees per day. But since the inclination to ecliptic is only 1.5 degrees the error due to LAN shift is not huge.

The error was large enough for it to be discussed in detail on the old forum here and later on Meadville here. BrianJ also had issues here.

Martin, what happened to Chode's proposal (last post in this thread) to model the precession? Is it just too hard/not worth the effort to implement?

 

[n72.75]

I think it is apparent now that the next verision of orbiter will be one of the biggest revolutions in the orbiter world.

I think that the change of value is an important and nessecery step, because I like perfection. but that's just me.

The best value that I can find for the Lunar Obliquity is "about 1.6°" , needless to say i think we need more precision then the tenths place.

I will look at the Library.

Matt

 

[tblaxland]

The best value that I can find for the Lunar Obliquity is "about 1.6°" , needless to say i think we need more precision then the tenths place.

The issue is not so much the value of obliquity itself but how Orbiter handles (or doesn't handle, as the case is presently) the precession of the pole, or the LAN of the obliquity.

Brain-fart: Is it possible to make an extension to the CELBODY class (CELBODY2?) so that a planet module can specify its own obliquity/LAN of obliquity? This would allow precession and nutation to modelled, at the planet developer's discretion (might be useful for asteroids in particular).

 

[jarmonik]

Brain-fart: Is it possible to make an extension to the CELBODY class (CELBODY2?) so that a planet module can specify its own obliquity/LAN of obliquity? This would allow precession and nutation to modelled, at the planet developer's discretion (might be useful for asteroids in particular).

It's probably not good idea to incorporate rotational parameter in CELBODY class because user may need to modify them. For an example when flying Apollo mission with virtual AGC, in some cases Orbiter must be configured to match the configuration of vAGC.

It would be possible to improve the situation by adding theta-rate (i.e. LAN-rate) parameter in configuration file. That would be all that's needed for the Moon from Apollo point of view. Of course, it's not perfect solution but shouldn't require much efforts to implement.

EDIT: Suggestion above is the same as the Chode's proposal refered by tblaxland

 

[tblaxland]

It's probably not good idea to incorporate rotational parameter in CELBODY class because user may need to modify them. For an example when flying Apollo mission with virtual AGC, in some cases Orbiter must be configured to match the configuration of vAGC.

Which, IIRC, at the moment is done by Project Apollo by providing a custom Moon.cfg at least (and their own sol.cfg?). Could a parameter in the cfg file be used to overcome this? So if the line "HasObliquityParams = TRUE" appears in the cfg file then Orbiter uses parameters from the cfg file, otherwise it uses the planet module. Alternatively, projects like Project Apollo could provide a custom cfg and custom planet module. The planet module would only need to be a wrapper module that calls the default Moon.dll for all parameters except those that you explicitly want to change, so it should not be too difficult to write (EDIT: this solution to a slightly different problem was proposed by cjp here).

 

[ACSoft]

NukeET asked to me by private message:

"how would these changes affect AMSO scenarios?"

I decided to write my answer/explanation here, so everybody may eventually try or give his feeling about this problem.

If, in my private "Config\AMSO\Moon.cfg", I use the following new Orbiter 2009 beta parameter values:

SidRotOffset = 4.78084319 ;IAU J2000
Obliquity = 0.02740413 ;IAU J2000
LAN = 2.17119075 ;IAU J2000

Instead of the old Orbiter 2006 parameter values:

SidRotOffset = 0.75049 ; rotation offset at J2000.0
Obliquity = 0.02692024985275 ; rad(1.5424167)
LAN = 0 ; ascending node of equator - CHECK!

I have, for example, the following anomalies:

If I start the scenario "Miscellaneous > Apollo 15 final landing in dust". I am supposed to see the LM coming down from the top of the screen for a landing in dust. But I can't see it, because the LM isn't located where it was, when the scenario was saved. If I go into the cockpit view, I will discover that the LM still very far from the landing site (I can see, in the far, the montains of landing).

An other example: if I start scenario "As-506 > Apollo 11 step 15.scn" (the PDI start), I will discover that I can't start the PDI program P63, because PDI conditions aren't satisfied, which should be normally the case.

To my view, SOMETHING MUST BE WRONG HERE.

Here are my arguments why:

All other AMSO scenarios, where the LM is landed, show a LM right where it should be. So, how could be the LM kilometers far away from the location it is supposed to be, just because it is not already landed ? In my example "Apollo 15 final landing in dust", the LM is hovering over the landing location and is just going down slowly. So why it appear KM far away ?

To be sure, I made right now the following test:

With Orbiter 2006, I generated two Apollo 15 scenarios, both with a fixed location outside camera. The first one, just half second before touch down. the second one, just half second after touch down.

Now, if I play these scenarios in Orbiter 2009, in the first scenario, the LM is not here (far away), in the second one, the LM is here, normally landed. SO AGAIN, I STRONGLY SUSPECT THAT SOMETHING IS WRONG HERE, no matter which parameter values are correct in the absolute. Hopefully Martin or some other specialist in celestrial physics may found what happen here.

ACS

 

[jarmonik]

Which, IIRC, at the moment is done by Project Apollo by providing a custom Moon.cfg at least (and their own sol.cfg?). Could a parameter in the cfg file be used to overcome this? So if the line "HasObliquityParams = TRUE" appears in the cfg file then Orbiter uses parameters from the cfg file, otherwise it uses the planet module.

Yes, That sounds like a good idea.

---------- Post added at 03:41 PM ---------- Previous post was at 03:19 PM ----------

All other AMSO scenarios, where the LM is landed, show a LM right where it should be. So, how could be the LM kilometers far away from the location it is supposed to be, just because it is not already landed ?

When a vessel is landed, orbiter will store it's longitude and latitide in a scenario file. If the rotational state of the Moon is changed the vessel will be still landed in the same location. However, when the vessel is not landed (it's airborne) it's state vector in ecliptic frame of reference will be saved in a scenario file. That will cause it to appear over a different surface location.

I don't think it's possible to fix rotation state of the Moon without breaking compatibility of some older scenarios.

 

[n72.75]

I don't think it's possible to fix rotation state of the Moon without breaking compatibility of some older scenarios.

I see a long road of sceneriao editing ahead.

 

[jarmonik]

If the theta-rate (LAN-rate) parameter is implemented that would also effect in every MFD application using rotation parameters.
From the IMFD point of view this is not a problem since I can modify RotationAxis() and MeridianAxis() sub functions to take the theta rate in account. But this may not happen so easily for the rest of the applications.

---------- Post added at 05:01 PM ---------- Previous post was at 04:45 PM ----------

Of course, if oapiGetPlanetTheta() would return planet theta for current Sim MJD. Wouldn't that solve the problem in most cases ?

 

[Tschachim]

I would like to invite comments on the changes from anybody qualified to check them, and in particular from NASSP developers who will have to cope with the changes as well, if they are brought forward to the release version. This includes the absolute values, as well as their stability and rate of change over time, which has an impact on their validity during the Apollo era.

As already mentioned, we're using our own Moon.cfg anyway, so we aren't affected by the change.

Jarmo calculated the currently used values for us to match the rotational model used by the historic flight software (which apparently was working fine in reality ), the LAN setting is mission specific because of the forementioned restrictions:

; === Physical Parameters ===
Mass = 7.34763862e+22            ; reverse calculated with Orbiter's gravitational constant to match GSOPs G*M
Size = 1.73809e6                 ; mean radius
JCoeff = 207.108e-6              ; GSOP R-577-sec5-rev4-5.9.1
SidRotPeriod = 2360595.092       ; optimized to match the VAGC calculations
Obliquity = 0.0267907

LAN = 0.0879                     ; Apollo 8
SidRotOffset = 0.5694711441

; === LAN for other missions ===
; LAN = 6.2333                   ; Apollo 10
; SidRotOffset = 0.7072213853
; LAN = 6.1787                   ; Apollo 11
; SidRotOffset = 0.7618474775
; LAN = 6.0658                   ; Apollo 12
; SidRotOffset = 0.8747221331
; LAN = 5.9309                   ; Apollo 13
; SidRotOffset = 1.0096206417
; LAN = 5.6566                   ; Apollo 14
; SidRotOffset = 1.2838879423
; LAN = 5.4923                   ; Apollo 15
; SidRotOffset = 1.4481901253
; LAN = 5.2478                   ; Apollo 16
; SidRotOffset = 1.6927261877
; LAN = 5.0297                   ; Apollo 17
; SidRotOffset = 1.9107681137

These values are working fine compared with the predictions of the historic flight software, but as Jarmo calculated them I can't tell you more about them.

I'd prefer to not have an own Moon.dll but be able to do all settings like a "LAN-rate" in a config file.

Cheers
Tschachim

EDIT: Jarmo provided new, better values, the Moon.cfg snippet above is changed.

 

[martins]

Ok, I would certainly be happy to consider including precession calculations, although this goes a bit further than what I had indended with this thread.

However, this would need some careful planning. For example, obliquity values are currently given with respect to the ecliptic. If I include a rate of precession, then this may no longer be valid in general, except for the moon. As I understand it, the fact that the moon's axis appears to precess around the normal of the ecliptic is a result of the fact that its orbital plane and axis are precessing at the same rate. I don't know if this is true generally. If it isn't, then the obliquity would have to be defined with respect to the orbital plane (e.g. 6.69 deg instead of 1.57 deg for the moon), and the precession would take place around the normal to the orbital plane. If the definition of the obliquity value in the config files changes, this would also affect all other celestial body config files.

 

[ACSoft]

When a vessel is landed, orbiter will store it's longitude and latitide in a scenario file. If the rotational state of the Moon is changed the vessel will be still landed in the same location. However, when the vessel is not landed (it's airborne) it's state vector in ecliptic frame of reference will be saved in a scenario file. That will cause it to appear over a different surface location.

I don't think it's possible to fix rotation state of the Moon without breaking compatibility of some older scenarios.

Thanks Jarmo, now I understand the problem.

In the meantime, I have verified that AMSO scenarios, fully generated with the new values of these parameters are fully OK. So, nothing is wrong here, as I suspected. Just a banal backward compatibility problem.

Now, the question is, which values I should adopt now for AMSO ?

To adopt these new values will mean all AMSO scenarios in the Moon vicinity won't probably work as expected. Of course, I can redo them, even if it will take a lot of time. It was more or less in my intention already, to solve other small compatibility problems.

But what about all the scenarios not under my control ? They are probably ton's of them saved on every AMSO fan PC's. They are even a lot of scenarios published with tutorials (for both NASSP & AMSO) or other Moon addons. I even wonder if some scenarios belonging to official Martin distribution version are not suffering of this change.

In fact, the decision BELONG MORE TO JARMO RATHER THAN ME: Will IMFD and the future LTMFD still work well, if the backward compatibility for these parameters is maintained by keeping the old values ?

Speaking of the values to adopt for the official "Moon.cfg", I think Martin should ask himself if these corrections bring more advantages than inconvenients.

ACS

 

[tblaxland]

However, this would need some careful planning. For example, obliquity values are currently given with respect to the ecliptic. If I include a rate of precession, then this may no longer be valid in general, except for the moon. As I understand it, the fact that the moon's axis appears to precess around the normal of the ecliptic is a result of the fact that its orbital plane and axis are precessing at the same rate. I don't know if this is true generally. If it isn't, then the obliquity would have to be defined with respect to the orbital plane (e.g. 6.69 deg instead of 1.57 deg for the moon), and the precession would take place around the normal to the orbital plane. If the definition of the obliquity value in the config files changes, this would also affect all other celestial body config files.

The precession of the LAN of obliquity should always be measured against a normal to an invariant plane, eg, the ecliptic. The orbital plane (especially in the case of the Moon) is no such plane because its LAN precesses and should not be used otherwise you would need some fudge-factor values in there to match real-world axis precession. Consider the Moon: what you are saying is that you would have an orbital precession period of 18.6 years and a obliquity precession period of 0 (or infinity, take your pick). Physically, this is clearly not the case, the system just happens to be in a Cassini State - both periods are 18.6 years - but this is far from universal. Consider a hypothetical state where the Earth was perfectly spherical, and hence the orbit plane would not precess, but nothing would stop the LAN of obliquity from precessing.

Now, the question is, which values I should adopt now for AMSO ?

Since you have your own system defined, you can realistically use any values you want. I really don't have any issues if you decide to use the old values in order to maintain backward compatability, provided they are internally consistent (which I'm sure they would be - one of the virtues of your excellent work BTW ). Just bear in mind that using the old values will prevent maximum historical accuracy being acheived by your users (see the Project Apollo issues with regard to the vAGC and sun-horizon angles I linked to earlier).

Speaking of the values to adopt for the official "Moon.cfg", I think Martin should ask himself if these corrections bring more advantages than inconvenients.

Well, I think that is the point of this thread. Going back to the OP, IMHO the changes are justified only if the precession of the LAN of obliquity is to be modelled in some form or another, either by way of a precession rate parameter in the cfg file (adequate) or by way of an extension to the CELBODY class (preferred).

 

[martins]

The precession of the LAN of obliquity should always be measured against a normal to an invariant plane, eg, the ecliptic.

Ok, I'm still not quite sure I understand, so let me just confirm:
It is preferable to describe the precession of the axis with respect to an invariant reference axis. The precession is then described by a constant obliquity value, and a constant rate of change of the LAN of obliquity. This sounds reasonable. However, I assume that there is only one such reference axis, and that for the moon it just happens to be the normal of the ecliptic. Generally, this may not be true, so the orientation of the reference axis must be included in the parameters that describe the precession. So you would end up with the following parameters:

- orientation of reference axis (vector)
- obliquity against reference axis (scalar)
- LAN of obliquity at a reference date (scalar)
- rate of change of LAN (scalar)

Does this sound correct? From your description I wasn't sure if in your opinion the precession of any body can be described with respect to the ecliptic.

The orbital plane (especially in the case of the Moon) is no such plane because its LAN precesses and should not be used otherwise you would need some fudge-factor values in there to match real-world axis precession. Consider the Moon: what you are saying is that you would have an orbital precession period of 18.6 years and a obliquity precession period of 0 (or infinity, take your pick). Physically, this is clearly not the case, the system just happens to be in a Cassini State - both periods are 18.6 years - but this is far from universal. Consider a hypothetical state where the Earth was perfectly spherical, and hence the orbit plane would not precess, but nothing would stop the LAN of obliquity from precessing.

I don't think I am saying that. I think that even in the rotating frame defined by the orbital plane, the precession period would still be 18.6 years (but phase-shifted by 180 degrees), and the obliquity would still remain constant (although with a different value).

If the inclination of the moon's orbital plane is 5.1 deg, and the obliquity of the moon's axis against the orbital plane is 6.7 deg, then at time t0, when the orbital LAN=0, and the LAN of obliquity=180, the inclination of the moon's axis against the normal of the ecliptic is 6.7-5.1 = 1.6, as required. At time t0+9.3 years, the orbital LAN=180, the LAN of obliquity=0, and the inclination of the moon's axis against the normal of the ecliptic is -6.7+5.1 = -1.6, as expected. So I would argue that you can describe the precession w.r.t. the rotating frame of the orbital plane, still with constant obliquity and constant LAN rate, without the need for fudge factors. Having a rotating reference frame would certainly be inconvenient, but my question was if this would be a more general definition, because it doesn't need the reference axis from the list above to describe the precession.

 

[tblaxland]

So you would end up with the following parameters:

- orientation of reference axis (vector)
- obliquity against reference axis (scalar)
- LAN of obliquity at a reference date (scalar)
- rate of change of LAN (scalar)

Does this sound correct? From your description I wasn't sure if in your opinion the precession of any body can be described with respect to the ecliptic.

You have understood me correctly. No, a normal to the ecliptic cannot be used as a universal precession axis. The ecliptic is sufficiently stable to use as a reference for measuring the precession axis against over time scales that I presently care about (18 arcseconds/century) .

So I would argue that you can describe the precession w.r.t. the rotating frame of the orbital plane, still with constant obliquity and constant LAN rate, without the need for fudge factors. Having a rotating reference frame would certainly be inconvenient, but my question was if this would be a more general definition, because it doesn't need the reference axis from the list above to describe the precession.

The angular distance between a moons axis of rotation and its orbital plane need not be constant. Having a constant obliquity w.r.t. the rotating frame of the orbital plane implies that the precession axis is always normal to the orbital plane. If the orbital plane is rotating w.r.t. an inertial frame, that further implies that the precession axis is also rotating w.r.t. to an inertial frame. But the direction of the precession axis will be constant when measured against any inertial reference frame - after all, what would change it? (as mentioned above, the ecliptic should be close enough to inertial for our purposes). The moons axis only has constant obliquity w.r.t. to its orbital plane because the precession rate of its axis and the precession rate of its orbit are the same.

 

[Nerull]

I think Martin should ask himself if these corrections bring more advantages than inconvenients.

I had thought this was a spaceflight simulator, not values-convenient-for-lazy-developers game. If something is off from reality, it should be corrected. If people can't be bothered to update their stuff, that's just too bad.

 

[BrianJ]

Don't know if this paper "Obliquity of Jupiter" is any help:
http://www.iop.org/EJ/article/1538-...quest-id=3b806eb3-f4e4-43ea-b51d-92a4500072d7

Part.2 "Precessional Equations" seems to imply that a planet's rotation axis precesses around the normal to the orbital plane, but the maths is mostly beyond me so I'm not sure.

Just one more thought - is it the case that for planets, the precessional period is in the order of 10,000's to 100,000's of years? If so, is it really worth bothering about? Is the Moon a special case? (in respect of it's short precessional period and importance as a target for historical simulations)

Cheers,
Brian