NavList:
A Community Devoted to the Preservation and Practice of Celestial Navigation and Other Methods of Traditional Wayfinding
Re: In Honor Of Jeremy Two Stars Full Lan's : One Upper And One Lower Culmination
From: Peter Hakel
Date: 2009 Sep 21, 09:15 -0700
From: "antoine.m.couette@club-internet.fr" <antoine.m.couette@club-internet.fr>
To: NavList@fer3.com
Sent: Sunday, September 20, 2009 11:27:20 PM
Subject: [NavList 9833] Re: IN HONOR OF JEREMY TWO STARS FULL LAN's : ONE UPPER and ONE LOWER CULMINATION
Sep 21, 2009
RE NavList 9823
Dear Peter,
Thank you for your replies to both submitted Star LAN's. I can see that you are a very active and quick meber of NavList.
Just a few explanations :
*******
IMPORTANT TO ALL PLAYERS IN THIS EXERCISE (Re : NavList 9823)
I did mention not only Ship's course and and speed ( as read from the Loch and (true) gyrocompass - BUT ALSO sea current speed and direction, which means that in order to get Speed and Course made good, i.e. on the Earth bottom, you need to "vector-add" both vessel's speed/direction and sea current speed/direction. This is important, and especially for the South Atlantic example, when we were experiencing a 2.5 kt current over a quite significant period of time.
*******
As regards Observation # 7 in the Mediterranean example, if you use Marc Saint Hilaire's method, then you can fully process it, as it is a good and valid observation. On the other hand, if you process Local Apparent Noons through dedicated specific Programs, such as the one used by Andr?s Ruiz (see NavList 9791), you need to be fully aware of such software limitations. Most generally they cannot adequately accomodate observations too far away (timewise) from local apparent noon time. And in the Med example, because DENEB culminates so high, and accordingly varies so fast "height-wise", a time second degree algorithm/approximation - as apparently And?s might be using - might not be "powerful" enough to adequately deal with such conditions (culmination so close to zenit) while in most cases (if not all) the Marc Saint Hilaire Method can still be used with rather safely. Its only real limitation is when all azimut are too close (+/- 180?) .... and I appreciate that we are here on "the borderline" in both examples, but if we have nothing else, better use it while being aware of its limitations.
Specific algorims limitations is one of the topics I wish to address in an upcoming message to NavList dealing with the "pro's" ,and "con's" about LAN's, or "LAM's" as Jeremy has them ... since it may not be sufficiently covered elsewhere, at least to the best of my knowledge (and I apologize to who ever has already adressed it in depth).
Such document will require some careful preparation from my side, so I need time and will publish it here if this topic seems of some interest to our NavList community.
Now, and as regards your results - the reply you have been longing/looking for ... - your Med result is fairly close from what I got (then independently crossed check by TRANSIT fixes), but for the South Atalntic results, it seems to me that your Longitude results could be significantly improved. ... unless I might have typed erroneous values, in spite of the great care I took in proof reading this message yesterday. I will take some further time as soon as I can in order to verify the data I published on both examples.
And by the way, what method did you use to work both LAN's ? If you rework both examples from your published results as DR positions and go with the Azimut/Intercept method (i.e. the so-called Marc Saint Hilaire), do you still get the very same final fixes ?
Thank you again for your interest. I will do my best to cross check once more the data I published yesterday in this LAN dual example, and get back to you afterwards. You certainly deserve, at the least, that I should not get your time and attention with uncorrectly copied/reproduced typed data.
Until then, please accept my Very Best Regards
Good Luck and enjoy ...
Antoine M. "Kermit" Couette
--~--~---------~--~----~------------~-------~--~----~
NavList message boards: www.fer3.com/arc
Or post by email to: NavList@fer3.com
To , email NavList-@fer3.com
-~----------~----~----~----~------~----~------~--~---
From: Peter Hakel
Date: 2009 Sep 21, 09:15 -0700
Hello Antoine,
Thank you for providing us with real-life examples to solve.
For these meridian transit examples I rigged my "noon_motion.xls" spreadsheet which was designed for the noon Sun (see the third item on http://www.navigation-spreadsheets.com/noon_shots.html ). The theory behind this technique is described in post #9079 from July 2009. The algorithm first advances all altitudes to a common time (for which I chose the last observation), and then calculates a parabolic fit to this prorated data. By Taylor's theorem, ALL "smooth" data sets with a local extremum are locally parabolic, whether the extremum is a maximum or a minimum. Therefore this method should work for all transits, upper and lower, and even for culminations near zenith. The Deneb example seems in line with that statement, as do my reductions of Jeremy's observations.
As for the Rigil example, this morning my fresh eyes discovered my error: in the spreadsheet I had cells F4 and F5 saying "North," which was a left-over from working the Deneb example... (!!!!) I switched them to "South" and now the UT of transit reads 09:17:50... Following that leads to these 09:30:00 coordinates:
S 48 deg 15.7'
W 17 deg 08.8'
Much better...
Another aspect is the error determination which my spreadsheet does not do. I did simple statistics for Jeremy's Moon examples but those were done with the intercept method and in a Fortran program. Furthermore, my fixes were much better than my huge standard deviations would indicate. I have not looked into this since. The least-squares procedure (used for the parabolic fits) can estimate the uncertainties by constructing and then inverting the curvature-matrix constructed out of second derivatives of Q^2. This is also on my wish-list. Another question regarding the Taylor's theorem application is what "local" really means. Your Rigil example taken over a substantial time interval indicates that this may not be a huge complication for processing of transits. So many questions, so little time...
Peter Hakel
Thank you for providing us with real-life examples to solve.
For these meridian transit examples I rigged my "noon_motion.xls" spreadsheet which was designed for the noon Sun (see the third item on http://www.navigation-spreadsheets.com/noon_shots.html ). The theory behind this technique is described in post #9079 from July 2009. The algorithm first advances all altitudes to a common time (for which I chose the last observation), and then calculates a parabolic fit to this prorated data. By Taylor's theorem, ALL "smooth" data sets with a local extremum are locally parabolic, whether the extremum is a maximum or a minimum. Therefore this method should work for all transits, upper and lower, and even for culminations near zenith. The Deneb example seems in line with that statement, as do my reductions of Jeremy's observations.
As for the Rigil example, this morning my fresh eyes discovered my error: in the spreadsheet I had cells F4 and F5 saying "North," which was a left-over from working the Deneb example... (!!!!) I switched them to "South" and now the UT of transit reads 09:17:50... Following that leads to these 09:30:00 coordinates:
S 48 deg 15.7'
W 17 deg 08.8'
Much better...
Another aspect is the error determination which my spreadsheet does not do. I did simple statistics for Jeremy's Moon examples but those were done with the intercept method and in a Fortran program. Furthermore, my fixes were much better than my huge standard deviations would indicate. I have not looked into this since. The least-squares procedure (used for the parabolic fits) can estimate the uncertainties by constructing and then inverting the curvature-matrix constructed out of second derivatives of Q^2. This is also on my wish-list. Another question regarding the Taylor's theorem application is what "local" really means. Your Rigil example taken over a substantial time interval indicates that this may not be a huge complication for processing of transits. So many questions, so little time...
Peter Hakel
From: "antoine.m.couette@club-internet.fr" <antoine.m.couette@club-internet.fr>
To: NavList@fer3.com
Sent: Sunday, September 20, 2009 11:27:20 PM
Subject: [NavList 9833] Re: IN HONOR OF JEREMY TWO STARS FULL LAN's : ONE UPPER and ONE LOWER CULMINATION
Sep 21, 2009
RE NavList 9823
Dear Peter,
Thank you for your replies to both submitted Star LAN's. I can see that you are a very active and quick meber of NavList.
Just a few explanations :
*******
IMPORTANT TO ALL PLAYERS IN THIS EXERCISE (Re : NavList 9823)
I did mention not only Ship's course and and speed ( as read from the Loch and (true) gyrocompass - BUT ALSO sea current speed and direction, which means that in order to get Speed and Course made good, i.e. on the Earth bottom, you need to "vector-add" both vessel's speed/direction and sea current speed/direction. This is important, and especially for the South Atlantic example, when we were experiencing a 2.5 kt current over a quite significant period of time.
*******
As regards Observation # 7 in the Mediterranean example, if you use Marc Saint Hilaire's method, then you can fully process it, as it is a good and valid observation. On the other hand, if you process Local Apparent Noons through dedicated specific Programs, such as the one used by Andr?s Ruiz (see NavList 9791), you need to be fully aware of such software limitations. Most generally they cannot adequately accomodate observations too far away (timewise) from local apparent noon time. And in the Med example, because DENEB culminates so high, and accordingly varies so fast "height-wise", a time second degree algorithm/approximation - as apparently And?s might be using - might not be "powerful" enough to adequately deal with such conditions (culmination so close to zenit) while in most cases (if not all) the Marc Saint Hilaire Method can still be used with rather safely. Its only real limitation is when all azimut are too close (+/- 180?) .... and I appreciate that we are here on "the borderline" in both examples, but if we have nothing else, better use it while being aware of its limitations.
Specific algorims limitations is one of the topics I wish to address in an upcoming message to NavList dealing with the "pro's" ,and "con's" about LAN's, or "LAM's" as Jeremy has them ... since it may not be sufficiently covered elsewhere, at least to the best of my knowledge (and I apologize to who ever has already adressed it in depth).
Such document will require some careful preparation from my side, so I need time and will publish it here if this topic seems of some interest to our NavList community.
Now, and as regards your results - the reply you have been longing/looking for ... - your Med result is fairly close from what I got (then independently crossed check by TRANSIT fixes), but for the South Atalntic results, it seems to me that your Longitude results could be significantly improved. ... unless I might have typed erroneous values, in spite of the great care I took in proof reading this message yesterday. I will take some further time as soon as I can in order to verify the data I published on both examples.
And by the way, what method did you use to work both LAN's ? If you rework both examples from your published results as DR positions and go with the Azimut/Intercept method (i.e. the so-called Marc Saint Hilaire), do you still get the very same final fixes ?
Thank you again for your interest. I will do my best to cross check once more the data I published yesterday in this LAN dual example, and get back to you afterwards. You certainly deserve, at the least, that I should not get your time and attention with uncorrectly copied/reproduced typed data.
Until then, please accept my Very Best Regards
Good Luck and enjoy ...
Antoine M. "Kermit" Couette
--~--~---------~--~----~------------~-------~--~----~
NavList message boards: www.fer3.com/arc
Or post by email to: NavList@fer3.com
To , email NavList-@fer3.com
-~----------~----~----~----~------~----~------~--~---
NavList
What is NavList?
Get a NavList ID Code
A NavList ID Code guarantees your identity in NavList posts and allows faster posting of messages.
Retrieve a NavList ID Code
Enter the email address associated with your NavList messages. Your NavList code will be emailed to you immediately.
Email Settings
