What is the cause of variations in lunar eccentricity?

In summary, the lunar eccentricity 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.
  • #1
fizzy
193
17
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

  • sim_plot.png
    sim_plot.png
    52.3 KB · Views: 808
Astronomy news on Phys.org
  • #2
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
 
  • #3
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:
  • #4
fizzy said:
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.
 
  • #5
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:
  • #6
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.
 
  • #7
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.
 
  • #8
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.
 
  • Like
Likes Trinity777 and Greg Bernhardt
  • #9
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 ??
 
  • #10
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?
ThanksPS 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:
  • #11
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.
 
  • #12
I'm not "blaming" anyone for their 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:
  • #13
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:
  • #14
Yes, that's eccentricity.
oeSMA is semi major axis in meters.
oeInc is inclination in radians.
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
 
  • #15
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:
  • #16
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.
 
  • #17
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.
 
  • #18
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:
  • #19
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?
 
  • #20
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.
 
  • #21
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).
 
  • #22
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

  • JPL_gravsim_peaks.png
    JPL_gravsim_peaks.png
    12.1 KB · Views: 613
  • JPL_gravsim_specta.png
    JPL_gravsim_specta.png
    10.4 KB · Views: 586
Last edited:
  • #23
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?
 
  • #24
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.

fizzy said:
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.
 
  • #25
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.
 
  • #26
I just tried the sim on the laptop : older Fedora , older FFx; ten times quicker ! One orbit in about 6s.

I'll have to look into what is wrong with the desktop PC's firefox.
 
Last edited:
  • #27
fizzy said:
The sim you provided shows target body : Earth and barycentre is checked
That checkbox is only for the display. Now that you've got the sim running faster, you'll notice that Earth isn't stationary. It wobbles as the Moon orbits it. Uncheck the barycenter box and the the Earth will be locked to the center of the screen.
 
  • #28
Thanks for the explanation.

I've realized that the peak shift is probably due to the non integer days of print out. I've just got a new JPL sequence using 399 ref frame and am doing a sim run with 128 sample step ( which is an integer submulitiple of 86400 ) , using the 'per iteration 'option rather than 'per update'. The non interger steps would also occasionally skip a day which would broaden the peaks. It should be more consistent this time.

Hopefully this will give apples to apples comparison.

OK, you will pleased to hear it is damn near identical to JPL output, to judge by visual inspection. I'll post if I see anything in the spectra but I doubt it.
 
Last edited:
  • #29
OK, I have got oeECC for the moon from JPL and done a frequency analysis. It is dominated by two peaks 31.8122 and 205.888 days.

The latter is due to the alignment of the lunar apside ( or its major axis ) with the earth-sun direction. It is half that period since alignments at either end of the ellipse have very similar effects. The first figure is the temporal coincidence of the new moon ( syzygy ) and the 205.9d cycle :

1/(1/31.8122 -1/29.5305888 ) = 411.74 = 1/(1/365.25 -1/3232. )

So the variability is fundamentally solar and due to the obvious alignments.
That gives quite a lot on insight about the variations but does not provide an analytic description of the underlying torque that produces the steady net precession.

That's what I was looking for with the original question, but maybe this is not the right place to get such a technical explanation.
There are some also-rans at 27.5546, 365.2, 411.6 , 1094.20 (2.996a),
14.7645 = 29.53/2 , though no 29.53
a couple of small peaks that appear to be sub-multiples ( odd harmonics ) of 2 years:
31.8119 = 365.25/11.48 = 2a / 22.96
34.8474 = 365.25/10.48 = 2a / 20.96

So most of the change in eccentricity is due to the sun elongating the orbit when its long axis aligns with the sun. It is interesting to note how the periods get changed.

I would not have associated 31.81d with any lunar period.

plus
37.63d and 9.61d ( which I can't see any reason for ).
 
Last edited:

1. What is lunar eccentricity?

Lunar eccentricity refers to the degree of elliptical shape in the orbit of the Moon around the Earth. It is a measure of how much the Moon's orbit deviates from a perfect circle.

2. What causes variations in lunar eccentricity?

The main cause of variations in lunar eccentricity is the gravitational pull of other celestial bodies, such as the Sun and Jupiter. Their gravity can influence the Moon's orbit and cause it to become more or less elliptical over time.

3. How does lunar eccentricity affect the Moon?

Lunar eccentricity can affect the Moon in several ways. A more elliptical orbit can lead to variations in the Moon's distance from Earth, causing changes in its apparent size and brightness. It can also affect the tides on Earth, with higher tides occurring during periods of higher eccentricity.

4. Can changes in lunar eccentricity impact Earth?

Yes, changes in lunar eccentricity can have an impact on Earth. As mentioned, it can affect the tides, which can have consequences for coastal ecosystems and human activities. It can also influence the Earth's rotation and tilt, potentially leading to changes in our climate.

5. How do scientists measure lunar eccentricity?

Scientists measure lunar eccentricity by observing the Moon's position in the sky over time and using mathematical calculations to determine the shape of its orbit. They also use data from spacecraft and lunar missions to gather more precise measurements of the Moon's orbit and eccentricity.

Similar threads

  • Astronomy and Astrophysics
Replies
2
Views
2K
  • Astronomy and Astrophysics
2
Replies
36
Views
15K
  • Astronomy and Astrophysics
Replies
3
Views
3K
  • Astronomy and Astrophysics
Replies
4
Views
3K
  • Astronomy and Astrophysics
Replies
6
Views
4K
  • Sci-Fi Writing and World Building
Replies
4
Views
2K
  • Astronomy and Astrophysics
Replies
2
Views
3K
  • Astronomy and Astrophysics
Replies
18
Views
6K
  • Sci-Fi Writing and World Building
Replies
21
Views
852
  • Astronomy and Astrophysics
2
Replies
45
Views
81K
Back
Top