Welcome to the NavList Message Boards.


A Community Devoted to the Preservation and Practice of Celestial Navigation and Other Methods of Traditional Wayfinding

Compose Your Message

Add Images & Files
    Name or NavList Code:
    Re: Lunar4.4. vs Frank's online calculator
    From: Frank Reed
    Date: 2023 May 8, 12:16 -0700

    Modris Fersters, you wrote:
    "I would like the software to be more accurate than the limits of sextant sights (0,1’) at least by factor of 2 or 3 (2”…3”) "

    While that is not impossible, it's also not necessary.

    "This is a question why do I need certain accuracy. In historical lunars even temperature and pressure were frequently ignored. And oblateness of the Earth (typically about additional 0,1’ error). But this was because of practical purposes—to do all the math faster."

    An alternative explanation, and maybe more likely, is that they knew they were at the limit of the observations themselves. The plan for most ardent lunarians --the people who took dozens, even hundreds from a single location--- was to average the results to cancel out random sources of error. And you should consider that many lunars on land were not worked up "live". The observations were transported home and then calculated at leisure. And in that process a small amount of additional computation was no real problem. So that argues against your speculation that it was all about doing the "math faster".

    Also, on general terms, what size of correction mattered historically? No matter what explanation we come up with, we have to consider the additions to the standard methods that were actually included in the work. Consider our favorite tables: David Thomson's slick and efficient lunar tables. He included small separate tables for the parallax of the Sun. At most this was a correction of 9 seconds of arc, and for altitudes above about 45° it was less than a tenth of a minute of arc. Why include those tables at all? Maybe they weren't needed. Actually, my preferred solution for modern versions of Thomson's tables is to include the Sun's parallax as the normal case instead of listing it as a separate additional correction.

    You asked:
    "But is it possible to get 2”…3” accuracy out of the software? ... As far as I understood, Frank thinks that this is impossible."

    No, I haven't said that. First and foremost, I would argue that 2" is un-necessary. But certainly less than 6" is desirable. I have also said that if you want to get down to a few arcseconds or better, then the lunar limb is the "elephant in the room" (although this is an English-language euphemism, I think it translates well enough without further explanation). Once we get down below six arcseconds, the lunar limb limits everything we do. There's no point talking about a single arsecond, let alone milliarcseconds (!), unless we deal with the problem of the Moon's limb (more below).

    You added:
    "Paul and Antoine thinks it is possible."

    Do they? Are you sure? When you asked Paul about the accuracy of his software, he replied (more than once!) regarding his "mas" (milliarcsecond) accuracy stellar positions. I feel that this was misleading. First, he didn't really answer you, did he? He didn't answer about the accuracy for lunars. As for the beliefs of Paul and Antoine regarding their fascination with computation, they have a long history of going wildly beyond the requirements of celestial navigation. Of course it's good clean fun --and there's nothing wrong with good clean fun!-- so long as we recognize that it has ceased to be about celestial navigation by any measure and certainly far outside the realm of traditional celestial navigation. That makes it off-topic for NavList, albeit only a couple of steps removed. My only hard standard for what counts as off-topic is when I get complaints from NavList contributors/readers of long-standing. Given the radical decline in participation in NavList discussions in the past three years or so, that's not really much of an issue anymore --if there's no one in a drafty room, there's no one to complain about the draft, right?

    Instead of thinking about the declarations of computation fans, why not consider your own experiences with lunars? I'm sure in your many, many observations you've done some Moon-Jupiter lunars. Let's focus on those... Given the limits of human vision, and given the angular size of Jupiter, we can make certain theoretical estimates and compare them with your own actual experience. Jupiter's average angular diameter is about 38 seconds of arc or 0.6'. The resolution of excellent human vision is about 0.8'. So without optical aid, we all agree that Jupiter appears to be an unresolved point of light.

    But your sextant has a scope. Specific to your experiences, Mordris, I can't recall if you have ever specified the magnification of the telescope on your preferred sextant. Let's suppose is a four-power scope -- a magnification of 4x. That implies that your visual resolution looking through the scope is just about 0.2', right? And that would imply that the image you see of Jupiter is three times larger than the limiting resolution. In effect it's as if it's three "pixels" across. How does that compare with what you see when you bring Jupiter to the limb of the Moon? For me with 3-4x magnification, that sounds about right. I can just make out the difference between one side of the planet's disk, distinct from the "middle" of the disk, and again distinguished the other side of the disk. So I can with some degree of repeatability attempt to place the middle of Jupiter cleanly on the limb of the Moon. Does that match what you see when you make observations with Jupiter? If you think you can go beyond that, how "resolved" does Jupiter appear to you? Can you decide between 60% of the distance across the disk of Jupiter and 70% of the disk? Probably not, right? But if you could, a ten percent "slice" of Jupiter would be about 4" thick --four seconds of arc across. Can you see ten distinct slices across the disk of Jupiter? Anyone who has ever made any sort of Jupiter observation with a sextant knows that such small divisions of the disk are probably not realistic. Do you disagree, Mordris? Do you think you can see 4 seconds of arc with your sextant? Or is it more like 12 seconds of arc?

    Incidentally, you might wonder why I don't ask Paul and Antoine about their own lunar observation experience. Basically, they have very little, if any. I don't believe Paul Hirose shoots lunars at all. Antoine has done some small number, I think, but no significant experience.

    You wrote:
    "Frank’s lunar calculator after the last updates differs from Lunar4.4 in some cases 0,13’ (I checked only some examples)."

    It's always possible that there's still a bug somewhere in my code that I missed, but right now this information is not worth much. Can you provide a specific example? 

    You wrote:
    "If I understand correctly, Frank’s philosophy is not to try achieve higher accuracy than 0,1’-0,15’ (Frank, please correct me, if I am wrong)."

    The ephemeris data in my apps is accurate to about +/- one second of arc. Nothing more is necessary or meaningful for celestial navigation. The various corrections for lunars should be good to about 3-6 seconds of arc, so, yes, my target is a little better than the numbers you're suggesting here --not hugely different though (only a factor of two).

    By the way, in my lunars clearing web app, you may have noticed that it only provides the error to a hundredth of a minute of arc when the error is near zero. This was a feature I added long after the app was originally created, a modification designed to satisfy some users who had specific cases where they wanted that precision. The extra digit should be treated as a guide and not an exact figure. I could add some text on that issue, but I'm not convinced that it would be "educational". As I explained some years ago, the extra detail was actually already present in a sort of "stealth" feature, so displaying the extra digit was just a convenience anyway. If it has become a distraction, I should probably hide it again.

    You added:
    "Paul’s philosophy is different. He tries to get out of his software the limits of the possible."

    His claims regarding milliarcsecond accuracy are probably misleading. You understand that he does not include the lunar limb, right? And you understand that this is the most important property missing from any of these apps, yes? And incidentally, I've been pointing out to anyone interested for over a decade that this is the missing piece. If you believe that there is any merit in going much below a tenth of a minute of arc, then you must include some sort of lunar limb correction! I find that most of the algorithm fans reject this on semi-aesthetic grounds. They prefer to think of the Moon's disk as a perfect astronomical circle. If we start talking about mountains and valleys, well "ick!", that's not astronomy! That's geology! Myself, I have done some work on this issue, and I would be happy to discuss it, but it's not really that important. Maybe I will add limb corrections some day --for entertainment value perhaps. It's a low priority.

    Have you seen representations of the Moon's limb? Years ago, before he retired, Fred Espenak used to produce detailed charts for solar eclipses that included all sorts of interesting information including the unique limb profile for each eclipse. I'm including an example in this post (below; attached). These profiles were based on pre-Apollo charts of the limb which have, only just recently, been superseded by LRO "digital elevation models" (topographic maps). The limb profiles in Espenak's solar eclipse charts were intended primarily to predict and understand the phenomenon of Bailly's beads during an eclipse. For lunars we need something different --a limb profile smoothed over a range of some dozens of km-- since we "brush" the other object along the Moon's limb to decide contact. The range in the limb profile from the lowest depressions to the highest plateaus is about six seconds of arc (+/- 3 arcseconds from the mean circle).

    Frank Reed


    Browse Files

    Drop Files


    What is NavList?

    Get a NavList ID Code

    (please, no nicknames or handles)
    Do you want to receive all group messages by email?
    Yes No

    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

    NavList ID Code:

    Custom Index

    Start date: (yyyymm dd)
    End date: (yyyymm dd)

    Visit this site
    Visit this site
    Visit this site
    Visit this site
    Visit this site
    Visit this site