Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Moon Semi-Diameter and Horizontal Parallax used by Celestial plugin is off by up to +/- 8%. Change Moon SD/HP to approach Nautical Almanac precision. #25

Open
rbossert149419 opened this issue Jan 19, 2025 · 15 comments

Comments

@rbossert149419
Copy link

rbossert149419 commented Jan 19, 2025

Problem: The Moon Semi-Diameter and Horizontal Parallax is used to determine Observed Altitude (Ho). In the plugin, it is a constant based on average SD and the relationship that SD=.27346*HP. The SD and HP used by Nautical Almanac varies up to +/- 8% from the average.

Impact: In 2 moon sight reduction examples, the Plugin’s Observed Altitude (Ho) was 1 to 4.7 arc-minutes too small and the Estimated Position (single body sight) was off by 1 to 4.7 nautical miles. The proposal substantially reduces the Observed Altitude (Ho) variances between Nautical Almanac and Celestial Plug-in.

Request: The plugin to use a more precise Moon SD and HP to approach the Nautical Almanac precision. SD and HP for Sun, Mars, Venus remain unchanged, for now. The Nautical Almanac for table based sight reductions has Moon’s SD is fixed for 3 Days, and Moon’s HP identified per whole hour. NA documents a sight reduction based on formulas (page 280-281), and only requires getting the Moon’s hour based HP. There is a free software product that doesn’t need internet to reduce sights and has precise Moon SD/HP. OpenCPN can match that product.
The Plugin’s Sight Properties and Calculation form shows the formulas and intermediate calculations starting with Measured Altitude (Hs) and ending with Observed Altitude (Ho). The calculation form is useful. It should be kept current when the plugin changes.

Current and Proposed. The Moon Semi-Diameter used by the Plug-in is documented to be 15.5’ constant (per Sight Properties/ Calculations form). But in the plugin’s Limb correction, the constant 0.2591° (15.546 arc-minutes) is used. That value is closer to the average Moon SD (15.53872’). HP’s 56.9’ / .94833° value under “Almanac Data for Moon”, is changed to .9475° when calculating Moon’s parallax correction. The plugin’s HP constant is based on SD = .27346HP. The Nautical Almanac’s confirms “SD = .2724*HP” (page 285, step 5). NA adds Earth Oblateness (OB) to the parallax equation (page 280, step 4). The solution might be to extract a HP data (not use average) from a source of record, and then calculate SD (page 280, step 5). ADD OB equation to the Parallax calculation for the moon only

Algorithm and Code (updated 1/26/2025)
Celestial Tools a software product owned by America's Boating Club (aka US Power Squadrons) uses a version of Jan Meeus algorithms documented in Chapter 25 of his 1991 book "Celestial Algorithms". I tested it on my PC. The Moon SD and HP output is within .1' of Nautical Almanac's version of truth. I received part of the code (written in C# aka C sharp). The code sent to me DOES NOT include what is necessary to compute SD and HP. It does show how the developer went about Moon's position. The code actually follows Meeus's book pretty closely. The developer will send more code of specific functions if necessary. It was programmed in VB and the developer has been converting it bit by bit to C sharp over time.

As a workaround for the code's missing SD/HP calculation details, I want to send a spreadsheet (Apple Numbers...I can export to powerpoint if you don't have a Mac) that shows the full computations (including full tables) and explanation. It includes 7 test case worksheets from 1992, 2001 to 2025. GitHub doesn't seem to allow me to update NUMBERS (just PDF). So, I'll try to email the spreadsheet. It isn't large. You'll want to review the spreadsheet cells which are formulas. The worksheet includes everything. For this problem, you only need the cells pertaining to SD and HP.

Each Test Case is a worksheet. The input to each worksheet (Julian Date (Delta_T should be included in the Julian Date). The output is HP, SD, and Ecliptic Latitude and Longitude, and Equatorial Latitude and Longitude assuming a constant for epsilon (Earth Tilt) and Longitude Nutation (Earth wobble along the spinning axis). If you need it, I'm confident I can work it out from Meeus's book.

Attachment. Analysis of the impact and Examples included as attachment.

CTSRFMoonFunctions.txt

Open CPN Celestial Plugin Moon Semi-Diameter:HP accuracy issue PDF.pdf

@rgleason
Copy link
Owner

Wow. This is a gift. Thank you. Hopefully we will find a good programmer.

You advise:

There is a free software product that doesn’t need internet to reduce sights and has precise Moon SD/HP. OpenCPN can match that product.

Do you have the name for this product? Perhaps we can get the tables from that?

@rbossert149419
Copy link
Author

rbossert149419 commented Jan 20, 2025 via email

@rgleason
Copy link
Owner

rgleason commented Jan 20, 2025

Dear Bob,
I do not recall, but the last time a very capable fellow updated and improved our accuracy with new tables and I think I added all of this information in the manual. Which I worked on quite a lot. It is probably not up to standards but it is our attempt at honoring this still very useful information and craft.

The manual format has changed and I did not have complete control over that, but I think the guys did a pretty good job transferring it. It is housed in github now and not opencpn.wiki. I can still edit it and so could you if you find the need or desire.

Out of curiosity, are you an OpenCPN user? https://opencpn.org/wiki/dokuwiki/doku.php?id=opencpn
Here is the plugin list https://opencpn.org/wiki/dokuwiki/doku.php?id=opencpn:manual_basic:set_options:plugin_manager Celestial Nav is under Navigation

Here is the manual https://opencpn-manuals.github.io/main/celestial_navigation/index.html

On accuracy https://opencpn-manuals.github.io/main/celestial_navigation/index.html#_comparison_of_plugin_astronomical_data_and_nautical_almanac_data

and further down....

https://opencpn-manuals.github.io/main/celestial_navigation/index.html#_comparison_of_plugin_astronomical_data_and_nautical_almanac_data

@rbossert149419
Copy link
Author

rbossert149419 commented Jan 20, 2025 via email

@rgleason

This comment has been minimized.

@rbossert149419
Copy link
Author

rbossert149419 commented Jan 24, 2025 via email

@rgleason
Copy link
Owner

@rbossert149419 Bob that is great, and it is C++

@rbossert149419
Copy link
Author

rbossert149419 commented Jan 24, 2025 via email

@rgleason
Copy link
Owner

rgleason commented Jan 24, 2025

Jean Meeus's name is familiar. "Jean Meeus in Astronomical Algorithms Chapter 45 Position of the Moon."

How big is the code when zipped? You can add a zip file to these comments. That might be a good way to do it.

Astronomical Table of the Sun, Moon and Planets, 3rd edition its about $130 used
Astronomical Algorithms 2nd Edition $54
Or a whole list https://www.goodreads.com/author/list/239773.Jean_Meeus

@rgleason
Copy link
Owner

From Bob's 2/6/25 email.
.. spreadsheet that demonstrates the Moon SD/HP algorithm with test cases. In all of the test cases, the algorithm worked quite well.

From Bob's 2/8/25 email

I have a C++ program that calculates only Moon Semi-Diameter and Parallax. I tested it with the same examples as the spreadsheet I sent. The spreadsheet scope was bigger. It completely calculates the moon's position as well as SD and Parallax. And that goes beyond the problem I'd like to have fixed. The plug in needs to be upgraded to use this program's parallax and semi-diameter rather than use an average semi-diameter and parallax. Thus the C++ program is limited to Moon Semi-Diameter and Parallax.

There are a couple additional things I could do.....I used long double for most of the non integer numbers. I can change to double....Double should work fine since we only need to meet Nautical Almanac standard precision (0.1 minutes).

My program currently has Main() where I input Julian date (for key test data). Within Main(), I do have some equations that might already exist in the plugin code for other purposes. And from Main(), there is a simple function I wrote that does modulo on Large Degree values that need to be rounded down to between 0-360 degrees. Then Main() calls my key function which calculates Distance from Earth to Moon (km) which changes enough in an hour to have an impact on Parallax and Semi-Diameter. For our needs, Semi-Diameter and Parallax is based solely on this distance by the way. The last part of Main() then calculates Semi Diameter and Parallax based on Distance.

Bob's email 2/9/25

Thanks for offering to reach out to Sean Depagnier for his help to integrate this and another piece of C++ code that I'll send to you. I bet he can make the coding changes quick. Hopefully he is happy with this code. Please let him know that, i'll be very pleased to test.

Attached is my C++ source code for Moon Semi-Diameter and Parallax. There is a self contained function that calculates Earth-Moon Distance using time dependent tables and equations. The function's input is TT (Julian Date converted to Y2000 epoch century). I suspect the plug in already calculated TT and can feed that as input to the function.

The function's output is Distance (in km). Then there are 2 simple 1 line equations in Main() that he can use to replace his existing 2 equations for Semi-Diameter and Parallax. This code's Semi-Diameter and Parallax are in arc-minutes (to match Nautical Almanac), although he might want them in degrees. Either way works for me.

I made comments in the code and I kept the trace statements to output intermediate and final results to the terminal. I expect the output statements will be commented out.

You could send him my issues documentation for background of various bugs and suggested improvements.

I'm also attaching an Apple NUMBERS spreadsheet that was my pilot (if he needs it in excel, I can convert and resend). The worksheets show my unit test script and results.

Moon Parallax and SemiDiameter rev1.cpp.txt

@rgleason
Copy link
Owner

rgleason commented Feb 11, 2025

Bob, Povl Abrahamsen, 2/26/2017 did the Calculation & Accuracy: Plugin Improvements

He writes

  1. transform_star.cpp has been written by me, using equations from the US Naval Observatory Circular No. 179
  2. epv00.cpp comes from the SOFA library http://www.iausofa.org/, with a wrapper function written by Povl Abrahamsen.
  3. Also we would like to acknowledge the use of the SOFA function and library. See Article: Earth Rotation and Equatorial Coordinates below for general information about the error.

I hope this helps.

@rgleason
Copy link
Owner

Bob, As I recall, I would have to look into it further, but some part of this was not done.

I have a question on the Plug-in's Line of Position plot. I read the user
documentation from the link, and I'd like to test my understanding about
how the Celestial Plug in LOP was determined. It doesn't need the DR/Fix
(or boat location). If DR changes, Plot remains constant. It is based on
Ho and the GP of the body at the time the sight was taken. And somehow
solving a Nautical Triangle with Ho (or 90 - Ho, Co-Ho) and GP as knowns.
What algorithm does it use? I don't see an issue, just seeking to
understand.

I believe Sean wrote the fix part. He is a math genius I think.
I found this note at the bottom of my old tests.

NOTE
The altitude & azimuth given with the “FIND” button is without the Parameter’s Tab corrections, so it will not be as accurate as an actual Sight.

@rgleason
Copy link
Owner

What is this?

There is a free software product that doesn’t need internet to reduce sights and has precise Moon SD/HP. OpenCPN can match that product.

@rbossert149419
Copy link
Author

rbossert149419 commented Feb 11, 2025 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants