NavList:

David C, you wrote:
"LD = arccos[sin(Dec1)*sin(Dec2) + cos(Dec1)*cos(Dec2)*cos(GHA2-GHA1)]   so to for the calculated LDs all you need is Dec and GHA. The GHA can be approximate. You pick a time consistent with your DR."

First, this process of calculating the geocentric lunar distances is only required if a modern navigator does not have access to pre-computed lunar distance tables. Historically, up until the early 20th century, these were included in the various nautical almanacs. And with rare exceptions, they were computed for every three hours of every day for the Sun and a few convenient stars and planets when they were in range and observable. Using one of the web apps on my web site, you can easily reproduce tables like this. If you don't have access to either pre-computed lunar distance tables or a tool like the one on my web site, then you can readily build them yourself from the GHA and Dec data for the Sun and Moon. This is just a standard great circle distance calculation for the two bodies on the celestial sphere. Your DR enters into this only to the extent that it gives you an approximate value for GMT, but you could just as easily ignore your DR and directly use whatever approximate value for GMT you may have available. Let's consider an example...

You're sailing in the Golden Globe Race in the South Pacific. You're near 165° W. It's about 9 AM local time on November 29, 2018, and you notice the Sun and Moon are nicely separated by about 90° (just a rough visual estimate at this point), which, as a competent lunarian, you know is a great geometry for lunars. As they used to say, "the Moon is in distance". Your chronometer got knocked around in a recent storm, and you are worried that it may be unreliable, so you decide to shoot a lunar. You've got the directions, but unfortunately you did not bring along any pre-computed distance tables. Time to roll your own. The chronometer currently reads 20:05:00, which is consistent with the approximate time of day and your longitude, but you still want to double-check. So you get out your almanac and you pull out the declination and the GHA of the Sun and Moon for 2000 UT and for 2100 UT. You run the numbers through the above great circle equation computation, and now you have the true geocentric distances for those two hours bracketing your observing time: 92° 20.2' and 91° 47.7'. You note here that the true distance is falling at a rate of 32.5' in 60 minutes of time or 0.5417' per minute of time. Then you shoot the lunar at 20:15:00 exactly, as displayed by your chronometer. You get an observed value (maybe 92° 23.5'), you run it through a clearing process and your cleared lunar distance is 92° 12.3'. So how did you do? Well, if the chronometer is correct, we can directly interpolate between the two computed values: the time is one-quarter of an hour along from 2000 to 2100 so the value should have changed by one-quarter of 32.5, which is 8.1'. That means that we should have found a cleared distance of 92° 12.1'. This differs only 0.2' from what we actually observed, which is within an acceptable margin of observational error. At this point we could reasonably conclude that the chronometer is correct and go no further. But what would you have done if the cleared distance had turned out to be 92° 21.4'?? In that case, we are actually outside our bracketing values, but we could still reasonably extrapolate linearly, and then we could conclude that the actual UT at the time of the observation was 19:58. This would imply that the chronometer is 17 minutes fast, implying that your longitude could be wrong by over 4 degrees. An interesting dilemma with many possible strategies to resolve it! But you better figure it out before you get to Cape Horn... 

You added:
"The parallax, refraction and SD must be known to clear the measured LD.  This requires an altitude sight close to the time of the  distance measurement. How accurate must the  observed altitude be? Looking at the Air Almanac the P in A is 45' for altitudes between 36° and 38° which suggests that  altitude need be measured only to the nearest degree. This would make the altitude  sight a lot easier.  Of course the NA may give more precise corrections."

Your general idea here is right. However the accuracy of the observed altitudes affects the clearing process in two distinct ways. First, if you want accuate altitude corrections, you need the altitudes to the nearest 5' of arc or so. You can't use the rough altitude corrections from the Air Almanac. They're junk for lunars. There is a second factor at work which is geometric. The altitude accuracy impacts the values of the "corner cosines" or the fraction of each altitude correction acting along the lunar arc. Under certain interesting circumstances, these two two different "forces" compensate and cancel each other out. There's no benefit for the altitude of the other body (the Sun, star, or planet), but it's a major benefit for the altitude of the Moon. When the lunar distance is close to 90°, like in the example above, the accuracy of the Moon's altitude can be quite low. You can shoot the Moon's altitude without a care in the world. Even if it's wrong by a degree or three, it will not impact the clearing process significantly.

You added:
"Very easy for 21st century Lunerians with massive computing power in their pockets but probably  something a pen and paper navigator would avoid."

I'm not sure I understood your point here, but I will try... This was in reference to the final step of interpolation between the predicted lunars. Whether you want to avoid it or not, it's part of the process. There was a system for manual computation involving so-called "proportional logarithms" in the early days of lunars, but it was less important in later decades when lunars were used for checking chronometers, like in the example above, since then there's not necessarily any division required. In any case, it's still just trivial interpolation.

An aside: for your reference, proportional logarithms are nothing fancy. For any number x, P.log(x) = log(3/x) which by the properties of logs implies P.log(x) = K - log(x) where K is a constant for all proportional logarithms and is equal to the log of 3 (since 3 might actually be 3 hours converted to seconds of time that could actually be the log of 10800, but it's the same conceptually either way). Thus to create a table of proportional logarithms, all you have to do is take a table of common logarithms, and for every entry value, subtract the log you find from some fixed constant number. Just that easy.

You concluded:
"Descriptions of Lunars I have read seem to concentrate on clearing the distance which to me is a side issue. It is like explaining cellnav by discussing in detail how to correct an observation for refraction, IE and SD without explaining anything about intercepts."

That's probably because you are looking at it from the perspective of a modern navigator. In lunars, everything but the clearing process is really quite trivial. The real meat of the problem is the process of clearing for all those small effects which modern navigators usually ignore and dealing with the fact that the altitude corrections are applied at "skewed" angles to the observed lunar arc. That's the genuinely exotic part of working a lunar.

Frank Reed
ReedNavigation.com
Conanicut Island USA ... where we have about a nanosecond of snow on the gound, and it's still falling.