Moon Phase formula - updated

mikeoday · February 20, 2019, 11:39am

Update: 2nd March 2019:

Moon Phase =

(((#DNOW#/2551442844-0.228535)
+0.00591997sin(#DNOW#/5023359217+3.1705094)
+0.017672776sin(#DNOW#/378923968-1.5388144)
-0.0038844429sin(#DNOW#/437435791+2.0017235)
-0.00041488sin(#DNOW#/138539900-1.236334))%1)

The result is a real number in the range 0 to 1, where 0 means the moon is new, 0.5 means it is full, etc.

Max error ~ 60 minutes
Median error ~19 minutes

…

original post continues below:

…

I recently looked into how to calculate the phase of the moon in order to add an “age of the moon” indicator and a changing moon image display.

as in …

After reading posts on this forum and doing some online research, I came up with the following:

age of the moon ( in days ) ~= ((((#DNOW#-585122000)/86400000))%29.530588)

This gives the age of the moon in days ( assuming a fixed lunar synodic period of 29.53 days ).

The number 585122000 is the time in milliseconds between GMT: Thursday, January 1, 1970 12:00:00 AM ( the start date for the #DNOW# tag ) and what would have been the approximate date/time for the first new moon after that date if the synodic period was constant. This number was obtained empirically by recursively solving for the “new moon date/time” in order to minimise the RMS value of the difference between the full moon dates/times predicted by the above formula and the dates/times for the full moon over the next 10 years from published tables.

This formula results in the following variation between predicted and actual date/time of the full moon ( in days ):

with an RMS value of about 0.3 days.

Choosing an actual historic new moon date as the offset in the equation, instead of a calculated value, will, in general, produce a significant offset to the above curve, and thus exacerbating the already quite large “error” between the average synodic period based prediction and the actual moon phase.

…

If you want to convert between the “Unix timestamp” ( given by #DNOW# ) and human readable date/time you can use the online tools at:
https://www.epochconverter.com/

for example, 585122000 is equivalent to GMT: Wednesday, January 7, 1970 6:32:02 PM
( versus the actual new moon time of 596100000 or 7 Jan 9:35 pm; using this time would add an additional constant offset/error to the prediction formula of around 3hrs ).

Note that the timestamp entry in the tool is in seconds ( so, eg. 585122000 / 1000 )

andrew.dowden · February 21, 2019, 7:01am

It would still recommend:

((#DNOW#/8.64e7-6.8583)%29.5306)

Based on lunar epoch: J2440594.358333 (1970-01-07 20:36:00.0 UTC)

mikeoday · February 21, 2019, 8:21am

Thanks Andrew, could I ask why you recommend it? I assume this is the time you have for the new moon (?).

Interestingly, this site gives the time of the new moon 1 hr later
https://www.timeanddate.com/moon/phases/uk/london?year=1970

I wonder why? It would be the middle of winter so it should not be a daylight savings issue…

andrew.dowden · February 21, 2019, 8:41am

I have cited my sources in the other discussions (on this forum).

Also, I developed a (cumbersome but) more accurate algorithm and used that to validate the above (lunar simplex v0.5).

mikeoday · February 21, 2019, 9:31am

Thanks for the quick reply Andrew.

I will look up your previous posts.

Just for your info, here is a reference to a study titled “The length of the Lunar Cycle” by I. Bromberg : https://individual.utoronto.ca/kalendis/lunar/index.htm

In it he, amongst many other things, examines the variation in the lunar cycle over many thousands of lunations and at one point determines a mean value reference for the new moon as January 6, 2000 at 14:20:44 TT. ( which might be another good reference to use ).

Anyway, I have found the exercise quite interesting and I will look up you previous work - thanks for sharing.

Cheers
Mike

ps. The USNO gives the time of the new moon on Jan 7, 1970 as 20:35 concurring with yours. I will have to redo my table of predicted times for the next 10yrs using data from them.

mikeoday · February 21, 2019, 12:36pm

I reproduced my spreadsheet using 20 years of data ( staring March 2019 ) from the US Naval Observatory ( https://aa.usno.navy.mil/data/docs/MoonPhase.php ).

Solving for X in the formula: ((((#DNOW#-X)/86400000))%29.530588), such that the Root Mean Square of the prediction error was a minimum, resulted in a value for X of

lunation start time = X = 582,481,649

The graph below shows the prediction error ( in days ) for the next 20 years of full moons based on two values of the offset.

Not surprisingly, due to the way X was determined, using the value above resulted in a zero mean error ( that is half the time the error is positive and half it is negative, cancelling to zero ).

Alternatively, I think unless one chooses a particular actual new moon so that it is near to the zero point in its cycle, using it as the lunation start will result in a fixed offset.

…

Now solving instead for X, such that the RMS error of the dates of all phases for next twenty years was minimum produced a slightly different solution:

X = 583,104,471

A massive 10 minute difference

mikeoday · February 28, 2019, 9:26am

I have produced a more complex approximation for moon phase that does not require the inverse tangent function. It is empirical, that is, there is no one-to-one relationship with a physical model ( at least not one I am aware of ). It was produced by taking the simple model and adding sine waves to it ( I ended up with three ). The initial choice of amplitude, frequency and phase was made by looking at the error curve for the simple model ( versus the next 20 years of moon phase data from the USNO site ) and trying to fit sine waves to it. This was followed by a tedious process in EXCEL of solving for each variable over and over again until all variables converged.

Anyway, here is the formula:=

Moon Phase:
"(((#DNOW#-583084344)/2551442802)+0.005843543sin(((#DNOW#-583084344)/5022920569)+3.23423)+0.0175542sin(((#DNOW#-583084344)/378924049))-0.003826534sin(((#DNOW#-583084344)/437400425)+2.99521)-
floor(((#DNOW#-583084344)/2551442802)+0.005843543sin(((#DNOW#-583084344)/5022920569)+3.23423)+0.0175542sin(((#DNOW#-583084344)/378924049))-0.003826534sin(((#DNOW#-583084344)/437400425)+2.99521)))
"

The output is a number that continuously increases between 0 and 1;
where:
0 => new moon,
0.25 =>1st qtr,
0.5 => full,
0.75 => 3rd qtr.

Note that the actual meat of the formula is only half of the above, the rest is needed to convert the “lunation” number ( in the form of say, 680.2723 ) to the phase ( 0.2723 ).

…

For comparison, the equivalent simple equation is:

“(((#DNOW#-583084344)/2551442802)-floor(((#DNOW#-583084344)/2551442802)))”

…

Now, how do they compare …

The graph shows the error ( in hours ) between the predictions from the models and the “true” phase at that time. The “true” phase data comes from the US Naval Observatory site. { note that the analysis is only based on data for new moon, 1st qtr, full moon and 3rd qtr as I could not find a source for reliable intermediate phases - the upshot of this is that the errors between the phases is unknown for both models. }

The red curve is the error for the simple model and the blue for the complex.

In terms of numbers:

Simple model:
Max error: 19.32 hours
Average magnitude of error: 8.15 hours

Complex model:
Max error: 1.28 hours
Average magnitude of error: 0.36 hours

Both have a total average error of zero. ( That is, half the time the error is negative and half the time positive without a constant offset. )

The difference between the models is, I believe, not significant for the purpose of displaying a moon phase image - the visual difference of the moon over a number of hours as viewed on a small watch is not great.

However, for the purpose of showing moon orbiting around the face of a watch, the difference becomes more significant as one places the moon further from the centre of rotation. At the watch edge the difference will, at times, be noticeable. How noticeable will depend on the particular implementation.

mikeoday · March 2, 2019, 1:09am

I think the expressions will work with the MOD function ( % ) instead of FLOOR - thus simplifying the expressions to:

complex:

((((#DNOW#-583084344)/2551442802)+0.005843543sin(((#DNOW#-583084344)/5022920569)+3.23423)+0.0175542sin(((#DNOW#-583084344)/378924049))-0.003826534*sin(((#DNOW#-583084344)/437400425)+2.99521))%1)

Simple:

(((#DNOW#-583084344)/2551442802)%1)

mikeoday · March 2, 2019, 5:04am

I have kept working on trying to further reduce the error ( just because ) …

This is it for now:

Phase =

(((#DNOW#/2551442844-0.228535)
+0.00591997sin(#DNOW#/5023359217+3.1705094)
+0.017672776sin(#DNOW#/378923968-1.5388144)
-0.0038844429sin(#DNOW#/437435791+2.0017235)
-0.00041488sin(#DNOW#/138539900-1.236334))%1)

The result is a real number in the range 0 to 1, where 0 means the moon is new, 0.5 means it is full, etc.

The maximum error has reduced by about 20% to around 60 minutes. During the next 20 years, the formula will give a result that is within 20 minutes of the true phase a little over half the time ( the rest somewhere between 20 and 60 minutes ). { Again note that this error data only relates to four points in the cycle (new moon, 1st qtr, full and 3rd qtr) and I have no way of determining the error in between these points. }

GAUSS · March 3, 2019, 11:36am

Very good work. Just tested your formula with a rotational version, compared to the astronomical calendar and it works nearly perfect.

Formula modified for the rotational:

(((((#DNOW#/2551442844-0.228535)+0.00591997 * sin(#DNOW#/5023359217+3.1705094)+0.017672776 * sin(#DNOW#/378923968-1.5388144)-0.0038844429 * sin(#DNOW#/437435791+2.0017235)-0.00041488 * sin(#DNOW#/138539900-1.236334))%1) * 360)/2)

In following example i used shadowmaps and the formula should be modified/reversed to:

((((((#DNOW#/2551442844-0.228535)+0.00591997 * sin(#DNOW#/5023359217+3.1705094)+0.017672776 * sin(#DNOW#/378923968-1.5388144)-0.0038844429 * sin(#DNOW#/437435791+2.0017235)-0.00041488 * sin(#DNOW#/138539900-1.236334))%1) * 360)/2)*-1)

Greetings, GAUSS.

mikeoday · March 4, 2019, 7:51am

Cool - I’m glad you were able to confirm that it works.

greyhound.racing.tip · July 27, 2021, 5:00am

Hello to all, I am an astrology student, currently trying to use some excel funtions toi calculate the moon face with a spreadsheet, I have little knowledge of excel so no almost nothing of programming, I was looking for an answer on the internet and saw your interesting posts. Could your fprmulas be used with excel to calculate the moon phase?

Regards

cardozo198013 · July 27, 2021, 8:52am

Welcome to the Facer.community group !!! @greyhound.racing.tip

This is a group where you can meet designers, programmers, and many good people, who can help you with your questions and ideas that you need …

For now with your question …
I tell you that Facer has its individual programming, by which it can be programmed, only in its program.
Here I show you the page, with which you can program …

Facer.io

Because it has its own commands for your program. Here I show you the pages where you can see what kind of commands …