# What is the cause of variations in lunar eccentricity?

#### fizzy

I'm still working on understanding some of the subtleties of the lunar orbit.

We know that the lunar nodes ( where the lunar orbit crosses the plane of the ecliptic ( a cryptic term for the plane of the Earth's orbit.)) shift progressively and complete a cycle in 18.61 years: the period of lunar nodal precession.

We also know that the lunar orbit, like most orbits, is not round but more like an ellipse, with a point of closest approach ( perigee ). Of course nothing is simple. The eccentricity varies and the alignment of the major axis also turns with time, taking about 8.85 years to return to the same position.

Using Tony's amazing gravity sim to get some data, I have made the following plot of position of the lunar nodes and the argument ( angle ) of periapsis.

We see the gradual drift ( precession ) of both of these obital "elements" and a small roughly six month oscillation in each one.

The oscillation in the periapsis is modulated by the 8.85 year cycle.

Now as far as I can tell, this modulation is due the change in eccentricity. When the lunar obit is more eccentric, there is a greater variability and when is less eccentric ( closest to being circular ) there is a lesser variation.

Now I would have thought at first sight that the variation in eccentricty would be due to the pull of the sun. When the major ( long ) axis aligns with the direction of the sun at perihelion, the eccenticity would be greatest. When the minor axis aligns at perihelion, this would tend to make the orbit rounder : less eccentricity.

However, the plane of the lunar orbit is inclined by about 5.3 degrees to the ecliptic orbital plane and this as we have seen rotates in 18.61y. So as far, as my mental gymnastics can conceive, the change in eccentricity is not due to the direction of pull of the sun.

Now I've tried running the gravsim with the mass of the planets set to zero and the plot is almost identical, so while they may have contributed to pseudo-stable lunar orbit as it is at any point in real time, they do not seem to be a significant player in the 8.85 or 18.61y cycles.

So what is changing the eccentricity of the lunar orbit?

#### Attachments

• 72.3 KB Views: 427
Related Astronomy and Astrophysics News on Phys.org

#### DaveC426913

Gold Member
Not exactly a trusted reference, nor very helpful, but:
The eccentricity of the orbit is changing almost on a daily basis due to complex variations in gravitational effects depending on the relative positions of the sun and the earth, and also Jupiter and Venus.
http://clivebest.com/blog/?p=5525

#### fizzy

Thanks.[/PLAIN] [Broken] Not a authority on astonomy but led me to this paper:

http://arxiv.org/abs/1102.0212

A recent analysis of a Lunar Laser Ranging (LLR) data record spanning 38.7 yr revealed an anomalous increase of the eccentricity of the lunar orbit amounting to de/dt_meas = (9 +/- 3) 10^-12 yr^-1. The present-day models of the dissipative phenomena occurring in the interiors of both the Earth and the Moon are not able to explain it. We examine several dynamical effects, not modeled in the data analysis, in the framework of long-range modified models of gravity and of the standard Newtonian/Einsteinian paradigm. It turns out that none of them can accommodate de/dt_meas. Many of them do not even induce long-term changes in e; other models do, instead, yield such an effect, but the resulting magnitudes are in disagreement with de/dt_meas. In particular, the general relativistic gravitomagnetic acceleration of the Moon due to the Earth’s angular momentum has the right order of magnitude, but the resulting Lense-Thirring secular effect for the eccentricity vanishes. A potentially viable Newtonian candidate would be a trans-Plutonian massive object (Planet X/Nemesis/Tyche) since it, actually, would affect e with a non-vanishing long-term variation. On the other hand, the values for the physical and orbital parameters of such a hypothetical body required to obtain the right order of magnitude for de/dt are completely unrealistic. Moreover, they are in neat disagreement with both the most recent theoretical scenarios envisaging the existence of a distant, planetary-sized body and with the model-independent constraints on them dynamically inferred from planetary motions. Thus, the issue of finding a satisfactorily explanation for the anomalous behavior of the Moon’s eccentricity remains open.

Oh man, so the reason I'm having difficulty finding this stuff is that we don't know half of it.

Last edited by a moderator:

#### mfb

Mentor
Oh man, so the reason I'm having difficulty finding this stuff is that we don't know half of it.
No. Check the magnitude of the effect they are investigating: a few parts per trillion per year. This is orders of magnitude smaller than the overall changes, mainly coming from the sun. Those are well understood.

#### fizzy

Thanks. So, what is the cause of variations in lunar eccentricity?

Can you provide something more explicit than "sun". As far as I have been able to ascertain, the periodic variations in eccentricity match neither the nodal precession nor the precession of the line of apsides.

Last edited by a moderator:

#### mfb

Mentor
Don't use larger font sizes please.

I'm sure there are papers discussing this, but I don't know them so I don't have links. There is no particular reason why those periods should match. The inhomogeneous part of the gravitational attraction of sun leads to some complex perturbation pattern, influencing different parameters in different ways.

#### fizzy

Sorry about the font, I copied the original question and got the large bold font. I managed to kill the bold but could not find how to change character size. ( I've found it now. )

OK, so you can't help. Thanks. Maybe someone else can.

Sure it's complex, otherwise I would not be asking.

#### tony873004

Gold Member
I thought mfb's answer was very helpful. He pointed out that what you're searching for and what is in that paper are not the same thing. Apollo astronauts left a mirror on the Moon so we can measure its distance very accurately. That paper is wondering why our measurements differ by our theory by a fraction of a millimeter. You're wondering about the causes that create the Moon's aphelion and perihelion to differ by thousands of kilometers over multiple orbits. And you seem convinced its caused by something other than , or in addition to the Sun.

You can also this in the simulator. Start with the same simulation, but replace the code in AutoPilot> perGraphicUpdate with the following:
Code:
if (elapsedTime > APnv1) {
ComputeOrbitalElements(11, 4);
var L = oeEcc.toString();
var P = (oePeri * 180 / Math.PI).toString();
var d = UTC(elapsedTime * 1000 + startDate);
d = d.substr(11,5) + " AD";
txtAreaCollisionLog.value = txtAreaCollisionLog.value + UTC(elapsedTime * 1000 + startDate) + "," + L + String.fromCharCode(10);
APnv1 = APnv1 + 1 * 86400;
}
This will output the Moon's eccentricity once per day. You can graph this, then try setting the planets' masses to 0 to see if they have an effect. Then set the Sun's mass to 0 and see if the eccentricity stops changing. I haven't tried this, but I suspect that you'll find that the Sun is responsible for virtually all of it.

#### fizzy

Thanks for the code snip Tony. I had thought of asking you how to output ecc. but the sim is so slow it's a bit limiting. I did a run with normal planets and I got about 10y sim time from an overnight run. With zeroed planets I get about 100y. I'd probably be better using JPl for normal configs but I don't know whether I could directly output elements like eccentricity. The telnet interface allows pretty voluminous output.

The possibility to print various parameters in the sim is great, I'll give it a try as you suggest.

mfb's original reply was helpful in pointing out the scale of the anomaly but the point of the question here is that I'm trying to understand what causes these periodic precessions. Like I want to see why ecc. changes , I don't just want "the sun" and then go away.

I'm trying to understand why the 366.3 year period pops out when combing nodal and apsidal precession. This is the way I have always approached science. Don't just learn blindly and accept and memorise a result; try to understand why it happens. That is how our knowledge and understanding grows. That is the difference between science and religion. Though many seem to take scientific knowledge in a religious way, just accepting what the "high priests" say and accepting it on faith. For many, science just replaced the church but they have the same relationship with the wise ones.

IMHO this is not what science is about and not why I chose to study it. My aim is to understand. Thanks again for your help in that endeavour.

Once I understand the mechanism which causes apsidal precession I may be able to see the difference that causes the 366.3d frequency difference. For the moment , if everything is caused by the sun, I cannot see why the phase slippage is one earth rotational period per year.

Is this an indication that part of the precession is caused by some gravitational linkage to the Earth's rotation or is it just the result of different reference frames for the two lunar precessions? This is what I'm trying to understand.

These are very fine differences which is why I think the anomaly may be relevant. It shows that, when we start to look closely, even the most complex models don't fully explain the moon's cycles.

The range finder project is one of the inputs to the high precision figures I am using, so the small differences in period include that information.

Maybe that is why I get 366.33 and not 366.242 ??

#### fizzy

I've got the ecc. data printing to the quick help window, thanks.
Is is possible to get a more plottable date , I really don't want to have to write script to parse the clunky month strings and calendar days etc. Is possible to just get a floating point julian day or something?

Update:
I tried the following it seems to give time since unix ( 1970).
<code>
if (elapsedTime > APnv1) {
ComputeOrbitalElements(11, 4);
var L = (oeLAN * 180 / Math.PI).toString();
var E = oeEcc.toString();
var P = (oePeri * 180 / Math.PI).toString();
var d = UTC(elapsedTime * 1000 + startDate);

var jd = ((elapsedTime +startDate/1000)/86400).toString();
d = d.substr(11,5) + " AD";
txtAreaQuickHelp.value =
txtAreaQuickHelp.value + jd + " " + E + String.fromCharCode(10);

APnv1 = APnv1 + 1 * 86400;
}
</code>

BTW is is possible to resize help window ?
Also how to format code on the forum?

This code gives output like:
16670.283275462964 0.06920132516212354
16671.3203125 0.06972383079973248
16672.20920138889 0.07004547555578639
16673.246238425927 0.0706024014196229

Those dates are not exactly one day intervals, what's wrong?
Thanks

PS sorry, another question, what is this oeEcc from? Is it an intermediate part of the calculation or just a metric derived from instantaneous values of velocity, position and their time derivatives?

Last edited:

#### mfb

Mentor
It is impossible to read every scientific paper ever written, or even keep up with new ones - arXiv alone receives ~300 submissions per day. You chose to study the eccentricity of moon in more detail: fine. Just don't blame others if they are reading particle physics papers instead, and stay at the level of "the sun is causing this" with their knowledge.
If you want to understand the large effects on the eccentricity of moon, the paper you quoted is a good starting point: it references previous analyses, those are discussing larger effects (and subtracting them from measurements) to find this small discrepancy the recent paper is about.

#### fizzy

I'm not "blaming" anyone for thier lack of knowledge . I said "OK, so you can't help. Thanks. Maybe someone else can."

I found that paper thanks ot DaveC's initial reply.

I thought there might be more specialist knowledge on an astronomy forum and was not expecting replies from particle physicists who don't consider themselves too familiar with the subject.

Tony's been very helpful with the gravsim, but also says the "why" is not what he really knows about.

Last edited:

#### fizzy

Tony could you just confirm what this eoEcc is?

going from 0.024 to 0.065 in 15 days, and back again, I'm not sure that this is the orbital eccentricity.

Last edited:

#### tony873004

Gold Member
Yes, that's eccentricity.
oeSMA is semi major axis in meters.
oeEcc in eccentricity in dimensionless numbers.
oePeri is argument of perihelion in radians
oeLAN is longitude of ascending node in radians
oeMA is mean anomaly in radians

#### fizzy

Wow, that's one badly behaved "ellipse" and that's with point mass earth.
Spectral analysis of that data gives 205.5 d and 31.7d peaks and very little else.
A little short of J2000 Apsides but your sim ran from 2015 .

1/(2/365.25-2/pApsides) = 205.888

So the 'why' of that seems to depend upon the alignment of the apsides in relation to the EMB- Sun direction and not to be dependant on the phase of the nodal precession. Simple elongation.

Is it likely that your gravsim will be slightly off from a complete model like JPL emphemeris that has lots of tweaks to ensure that things end up in *exactly" the right place at the right time.

It's just a gravity sim with point masses, right? I should not expect exact agreement with observations.

This is all very educational , many thanks.

Last edited:

#### tony873004

Gold Member
I got about 10y sim time from an overnight run.
It should run much faster than that. Even my 4-year old Android smartphone runs it faster. Can you get your hands on a newer Windows or Mac, or iPad? Perhaps at work, school or the library? It should only take a few minutes to do 10 years at time step 256.

Is is possible to get a more plottable date , I really don't want to have to write script to parse the clunky month strings and calendar days etc. Is possible to just get a floating point julian day or something?
You can directly output "elapsedTime", which is seconds since the simulation began. If you want Julian Date, use "julianDate = elapsedTime / 86400 + julianStartDate / 86400;" and then output JulianDate.

BTW is is possible to resize help window ?
Yes, just drag the bottom right of the white text area to resize.

I'd probably be better using JPl for normal configs but I don't know whether I could directly output elements like eccentricity. The telnet interface allows pretty voluminous output.
Don't use Telnet. Use their Web interface.
Change Ephemeris Type from "Observer" to "Orbital Elements". Change "Target Body" to "301" and Observer Location to "@3" or "@399". "@3" is EM barycenter and "@399" is Earth. You'll need to write a script to parse their output.

Also how to format code on the forum?
put the word "code" inbetween square brackets before your code, and "/code" in square brackets after your code.

Those dates are not exactly one day intervals, what's wrong?
You're outputting data every time the program updates the graphics. If you want closer to exact, clear the Auto Pilot "per Graphics Update" and hit "Update" on that screen. Then open Auto Pilot "per iteration" and paste the code there.

It will be closer, but not perfect unless 86400 is evenly divisible by your time step. But either way should be fine for your purposes.

what is this oeEcc from? Is it an intermediate part of the calculation or just a metric derived from instantaneous values of velocity, position and their time derivatives?
Yes, its an instantaneous value. If you were to set the mass of all objects but Earth and Moon to 0 at that point, that's the value it would remain at in its now purely-keplerian unperturbed orbit.

It's just a gravity sim with point masses, right? I should not expect exact agreement with observations.
Over time it will diverge from observation because of numerical error, forces not modeled, and the precision of the starting conditions. Even JPL's will diverge over time. That's why they refuse to give you any planetary data beyond about 100 years.

To test to see how much it diverges, change Target Object to Sun, Camera Object to Earth. Then in the Display menu, open "Cities A". Choose a city on Earth where a known total or annular solar eclipse took place. Run the sim backwards [>>] button on the Time Step Interface until that date and see if the eclipse happens. If you keep your time step under 2048 seconds, it'll successfully reproduce eclipses +/- 100 years.

#### fizzy

Thanks for such a thorough reply.

Even JPL's will diverge over time. That's why they refuse to give you any planetary data beyond about 100 years.
I don't think that is the case. I recently got Earth-Sun distance back to 1220AD at hourly intervals and I only stopped there because I got bored. The point of using telnet is that it's less laggy than the web interface but mainly seems to allow large output files and provides an ftp download for the results. I was able to get 200 y chunks at hourly resolution. The web interface seems to tighter restrictions , presumably to stop people loading the system too much. I guess they recon if you can manage telnet they can trust you a bit further.

I have to say that is an amazing public service.

It's quite interesting to see the dips in perihelion every 12 years and how the pattern is different around 1800 when the phase of the other planets lines up differently. It's more like two dips per 12y period. I thought this might be visible in the timing of lunar cycles but it's very small.

#### fizzy

About the speed problem: have you tested it on different browsers and platforms? There's more uniformity now than there was ten years ago but it's still a problem. You may like to consider different screen sizes. I could not find the collision box to start with, I finally zoomed out and found it hiding off screen. We don't all have 16:9 panoramic monitors ;)

This was also a problem because scrolling does not scroll the window as expected but moves the animation. I have to use the browser zoom to shrink the whole thing, move the windows to where I can access ( see ) them and then zoom out again.

User feedback: the low contrast blue on grey ; blue on black of the interface windows are very hard to read in small compact fonts. I have to stick my nose to the screen to read them. More contrasted backgrounds for text would make it a lot more enjoyable to use.

I just checked by disabling all the firefox plugins that I have, in case any were interfering and slowing it down. It did not look obviously quicker.

Last edited:

#### fizzy

Change Ephemeris Type from "Observer" to "Orbital Elements". Change "Target Body" to "301" and Observer Location to "@3" or "@399". "@3" is EM barycenter and "@399" is Earth. You'll need to write a script to parse their output.
Are you saying that can be used to get eccentricity?

#### fizzy

OK, I've got the eccentricity element from JPL too. A quick spectral analysis is largely very similar. The periods produced by the sim differ by about 1/400 . eg the circa 6mo peak: 205.892 cf 205.382 (sim) .That means that the apsidal precession will be off by a similar factor.

What is rather interesting is that the peaks are about twice as broad for the sim data.

Accepting JPL ephemeris as a very close reproductions of the observed system this would seem to suggest that the entropy of the real solar system is less than a gravity only model of it.

#### tony873004

Gold Member
I recently got Earth-Sun distance back to 1220AD at hourly intervals
It seems your right about the Earth and Moon. I guess they're more confident about Earth and Moon than other solar system objects. Trying some extreme dates in the web interface gives me the following error messages:
Code:
No ephemeris for target "Earth" after A.D. 9999-DEC-31 12:00:00.0000 CT
No ephemeris for target "Mars" prior to A.D. 1900-JAN-04 00:00:00.0000 CT
About the speed problem: have you tested it on different browsers and platforms?
There's probably slightly less than infinity ways to pair browsers with platforms, so no, not on all of them. Personally I own or have easy access to a very new Windows 10 computer, a very new Mac, a very new iPad, an old iPad, an iPhone, an old Android phone, and a few ancient Windows computers. All of them perform 10 years of sim time in a few minutes on every browser I've tested (FF, Chrome, Safari, IE, Edge). Usually the program crashes the Android.
Feedback I've got from other reports similar results. That's why I'm surprised that you report your computer needs to pull an all-nighter to do 10 years.

I have to use the browser zoom to shrink the whole thing, move the windows to where I can access ( see ) them and then zoom out again.
Sorry for putting it there. Its just that if all the interfaces are open at once they don't fit on the screen, so I push the seldomly-used ones far to the right. You can always drag it to another position, and then save the simulation.

User feedback: the low contrast blue on grey ; blue on black of the interface windows are very hard to read in small compact fonts. I have to stick my nose to the screen to read them. More contrasted backgrounds for text would make it a lot more enjoyable to use.
I agree with you. Its even worse if you try running it on an iPhone. In the future I'm going to allow the user to "skin" the program and adjust all those settings.

What is rather interesting is that the peaks [from JPL data] are about twice as broad for the sim data.
Can you post the graphs? I've found good agreement in every test I've run.
Are you using Earth(399) or Earth-Moon barycenter (3) as your "body center" in JPL Horizons. The instructions I've given you for my program will give you elements wrt Earth (399), although it can be set up for EMB(3).

#### fizzy

skins are nice user options but in the meantime it would be preferable to provide more readable defaults since you agree on that point.

The JPL data I recovered was EMB, so that would explain the narrower peaks. There will be more variations if E is used, although it seems odd that this would affect the lunar apsidal precession period.

I am a little confused about this term "eccentricity" it seems to be simply the distance from the reference point. I thought it was referring to eccentricity of keplerian elliptical orbit.

Spectra below. both were 1d resolution. Test periods were similar but not identical. Gives you an idea though.

Yes I have found polynomials for lunar periods giving 12 sf. !! Probably thanks to lunar range finder. Jupiter's orbital period I have only 8 s..f. , makes sense in view of nature of the target and the distance.

This is why I am interested in all these lunar cycles. It's a bit like Douglas Adams' "fundamental interconnectedness of all things. I think we have a level of precision in lunar motion that should tell us things about other planets and the SS itself. A bit like Arthur Dent's brain.

It occurs to me that the difference I noted between the sim and JPL is about the same magnitude as the curious one day per year phase drift in the two cycles derived from the high precision Jean Chapront polynomials.

#### Attachments

• 18.4 KB Views: 223
• 15.1 KB Views: 223
Last edited:

#### fizzy

Are you using Earth(399) or Earth-Moon barycenter (3) as your "body center" in JPL Horizons. The instructions I've given you for my program will give you elements wrt Earth (399), although it can be set up for EMB(3).
The sim you provided shows target body : Earth and barycentre is checked. If that is not EMB I can not see how to do that with the options provided, could you explain please?

#### tony873004

Gold Member
skins are nice user options but in the meantime it would be preferable to provide more readable defaults since you agree on that point.
I probably won't get a chance to modify the code until Summer. Until then, you can use CSS and the Auto Pilot to modify anything you want. Right click on the object and choose "Inspect Element" to get the object's id. Then add some javascript to modify the CSS for that object into the Auto Pilot. If you want more specific instructions, tell me which one you want modified.

The sim you provided shows target body : Earth and barycentre is checked. If that is not EMB I can not see how to do that with the options provided, could you explain please?
The EM barycenter is a ficticious object with the combined mass of the Earth and the Moon and sits at the center of mass of the Earth and Moon.
It would be much easier to ask JPL for Earth-centered elements. The problem with asking for the Moon's orbit wrt the EB is that the Moon's mass would count twice in the equations. Once because it is part of the ficticious EB object, and once more because it orbits this point.

If you want to do it:
Compute the EB position:
EBx = (objMass[4] * objx[4] + objMass[11] * objx[11]) / (objMass[4] + objMass[11]);
repeat for y and z.

Compute the EB velocity:
same except use objvx instead of objx, etc.
repeat for y and z.

Compute mass of EB:
EBmass = objMass[4] + objMass[11];

Then view the source of the code and copy and modify the function called
function ComputeOrbitalElements(objElements, objReference) {
. Modify the inputs to accept the newly-created data and paste into Auto Pilot.

#### fizzy

Thanks for the CSS idea, I had not thought of doing that.

EMB is no more "fictitious" than the point mass at the centre of the earth or the moon. ;)
It is EMB that is orbiting the sun not the earth or the moon.

Messing with the sim is far too complex for this. As you say this is better done the other way around. It would be interesting to get an apple to apples comparison.

Could you clarify what is meant by this "eccentricity" term? Is it just the distance from the centre or an instantaneous value of the elliptic eccentricity which is varying enormously throughout one orbit. In which case the orbit is far from being an ellipse.

### Physics Forums Values

We Value Quality
• Topics based on mainstream science
• Proper English grammar and spelling
We Value Civility
• Positive and compassionate attitudes
• Patience while debating
We Value Productivity
• Disciplined to remain on-topic
• Recognition of own weaknesses
• Solo and co-op problem solving