Lunar Distance by Calculator — The Letcher Method

The lunar distance method is a way to find UTC by measuring the angular distance between the moon and an adjacent body (sun, star or planet).  The measurements are called "lunars." And finding UTC is equivalent to finding your longitude. Recall we can find an accurate latitude without knowing the correct time, but standard procedures requires accurate time to find longitude. Lunars are thus a way to fill in your position if you have lost accurate time—or, starting from scratch, you never had accurate time.

It is an advanced skill in cel nav, because it requires very accurate sights and special analysis. Finding UTC to an accuracy of ± 30 sec or so is considered good work. We have notes on the history and practice of the method (starpath.com/lunars), which shows that there are essentially three approaches to the solution.

The first solution is the easy one. There are numerous apps online and for sale that solve lunars. Our own StarPilot was one of the first ones.  With these apps, you can just enter your DR position, the date and best guess of the right time, the name of the body you are using, and the lunar distance. There is usually an optional input for the measured altitudes of the moon and body, but these are not needed accurately, so they can be computed from the DR position. 

Everything else is computed and the output is the right time and right longitude, keeping in mind the uncertainty of the process: namely, every 0.1' of error in the  measured distance or clearing process leads to about 12 sec of time error, which corresponds to 3' for longitude error. 

The second solution is just the opposite: do it all by books and tables, like it was done in the late 1700s to early 1800s. The only math required is adding and subtracting longish numbers, but the tables and procedures can be complicated. With that said, this is the only logical solution, in that it is waterproof and no batteries are required.

Luckily, we have a modern all-paper solution created some years ago by Starpath friend and associate the late Bruce Stark. His book Stark Tables for Clearing the Lunar Distance — And Finding Universal Time by Sextant Observation has become a modern classic in cel nav studies. Experts consider his solution superior to some of those actually used historically (see discussion in the lunars link above.) But like the historic versions, doing this all with tables takes some practice before it becomes routine.

The third solution, which is the subject at hand, is a compromise of sorts between the first two. Namely we use a set of four trig equations that we can solve on any simple trig calculator along with standard sight reduction tables and a Nautical Almanac, and we compute the solution "by hand."

To my knowledge, this method was first put together by John S. Letcher, Jr in his excellent 1977 book on cel nav called Self-Contained Celestial Navigation with H.O. 208.  He was also a major technical authority and innovator of self steering devices, as presented in his 1974 book Self Steering for Sailing Craft. Both books are rare, but still found periodically in used book sites.

Below is an outline of his method. It has been elaborated upon in the 1980 book by Shufeldt and Newcomer called The Calculator Afloat, which is online in full. 

To help learn this process, we made an app (Letcher Lunar Distance Calculator)  and spreadsheet that solves the Letcher method that can be used to double check that you are computing the terms correctly. The app includes the examples presented in both books above. There is no logic to using this for actual solutions as there are other apps that are equally, if not a bit more, accurate that require much less input. The app and spreadsheet are purely training tools.

The idea here is you practice this a few times then write this prescription in your logbook to fall back on as needed, keeping in mind that the StarPilot, which covers all aspects of ocean and inland navigation computations, includes a lunar solution if needed.

It is important to skim over the discussion in the lunars link above. The summary is:

1) We measure the distance between moon and another body , which will be edge to edge. Then we use the Almanac to find the semi diameter of the moon (and sun if using it) so we can correct the edge to edge to get D, the lunar distance center to center, at time Ts which is our best guess of the UTC. In practice we need to take several sights and plot them D vs T then do a best fit to the line and find our best estimate of D and its corresponding Ts.

2) Then we "clear" that distance, which in this case means applying two corrections to D, refraction (R) and parallax (P). These corrections require us to compute the Hc of the moon (Hm) and of the body (Hb) at time Ts, which we do by looking up their GHAs and Decs, and then compute the distances with the formulas below. 

Note if you are underway, or have good horizon for the bodies on land, you can measure these heights in the normal way, and plot them to find a fix. The Lat of that fix will be correct, but the Lon will be off by the error in Ts, which we are finding from the lunars.

3) Once we have the cleared lunar (Dc) we need to see what time the two bodies where that far apart. We do this by computing the distance a the whole hour before Ts and at the whole hour after Ts.

Note that the lunar distance is just the zenith distance (z) to the moon assuming you are standing at the GP of the body being used. Thus D = z = 90º - Hc, which we can compute using the navigation triangle formula below (we just change our a-Lat to the dec of the body and our a-Lon to the GHA of the body).

Here is how the app input looks, showing also the Almanac data we need to enter.

Here is the sample solution from the Shufeldt book.

Once we have our measured Dc, we need to find out what time were these two bodies that far apart, keeping in mind the main premise of this measurement being that the moon moves eastward relative to the other bodies in the sky at a rate of about 12º per day, which is about 2' per minute. Not much, but right at the edge of our being able to measure this with standard sextant.

We figure this by interpolation as shown below:

Then within the accuracy of this method, Tc is he right time and Tc - Ts is our watch error.  The corresponding Lon error is 15'/1 min of time error.

The app is essentially two worked out examples that you can test with your own calculator.  The spreadsheets are there for those who want to look at that to see how these equations are entered into Excel.

Note that both examples given in the app are from May 27, 1973, so to follow though each step, here is the almanac data for that date that shows where the input came from.

These data are also needed if you want to check any of the online apps, as they typically want input of raw sextant data and then they compute everything, so to use them we have to unfold the two heights to Hs values and the LD they want is edge to edge, then they make the corrections in the apps.  Convenient for use underway, but not convenient for checking the Letcher method, so let me just add that the Letcher method does indeed work, and can be improved a bit more by adding easy corrections for augmentation of the moon's SD and earth oblateness.

 

Wind on the Water: A Sailor's Perspective

For sailors, wind speed is given in knots, and the direction of the wind is the direction it comes from. A north wind is blowing from the north toward the south. A sea breeze is blowing from the sea toward the land.  A land breeze is from the land toward the sea.

On the boat, we typically read the wind speed from an anemometer located at the mast head. Its spinning cups measure the speed, and an associated wind vane aligns with the direction of the wind, with the fin downwind, with the arrow pointing in the direction the wind comes from. The data are then transmitted digitally to instruments at the nav station and on deck.

The wind vane is calibrated to be oriented along the centerline of the boat, so the "wind direction" measured is not an actual direction on the horizon, but rather it is a wind angle relative to the heading (HDG) of the boat, called the apparent wind angle (AWA), which can vary from 0º for wind dead ahead, or 90º for wind on the beam, on around to 180º for wind on the stern. Wind dials or meters will then label the direction to be port or starboard, with the starboard side considered positive, if signs are given. Likewise, the wind speed we measure is called the apparent wind speed (AWS).

This measured wind from the masthead of a sailboat is called "apparent wind," because that boat can be moving, and when it starts to move, it creates its own wind.  For example, if there were no wind from nature at all at the moment (dead calm), and the boat took off at 6 kts headed due west, the AWS would read 6 kts and the AWA would read 000º, wind dead ahead. We are making this wind with our own motion. 

Figure 1. A boat creating its own wind, as it might appear in nav app meters.

Now if an actual meteorological wind from the north started to blow across the  water at 8 kts, the anemometer would then feel two winds: 6 kts from the west created by the boat's motion and 8 kts from the north created by a local weather pattern. The anemometer would then reflect the combination of these two winds, which leads us immediately to the concept of vectors, which we cannot avoid when discussing wind on the water.

The speed (of anything) is just a number, called a scalar, but the velocity (of anything) is a vector, it has both a speed and a direction. When we combine two winds, we are adding two velocity vectors to obtain a resultant third vector. Vector addition can be solved mathematically or depicted and solved purely graphically, as shown in Figure 2. When depicted graphically by arrows, the length of the arrow is proportional to the speed, and the direction of the arrow is direction of motion. 

With wind velocity vectors, we must distinguish between the direction the wind is flowing, or being created, as in the case of the boat motion wind (BW), and the name of that wind, which is the opposite of the direction it flows. A true wind (TW) from the north flows toward the south (its vector points toward south), but the name of the wind displayed on a meter (true wind direction, TWD) is the opposite. This is illustrated below and can be important for understanding such diagrams.

Figure 2. Basic wind vectors on the left with arrows indicating wind flow, compared to the same triangle with arrows indicating named wind directions, plus sample meter displays.

In the top left we see how vector addition is presented graphically. The TW vector plus the  BW vector is equal to (gets you to the same point as) the AW vector. You can draw these on paper and get the right answer: 8 units down, 6 units to the right, then measure what the AW is using a ruler on the same scale and a protractor.

Here we have added three more meters (true wind angle, speed, and direction) to reflect what we have determined ourselves about this from the moving boat, even though all we had to measure was the apparent wind we actually felt. This is done by mathematically solving the vector triangle on the right, which is based on the measured AWS and AWA, along with the measured boat speed (knotmeter) and measured heading from a digital heading sensor. This is carried out either by the wind instrumentation itself, or, maybe more often, from within the nav app we are using to compile and analyze the instrument data.

We can learn a couple general wind rules from looking at these vector drawings. First,  the true wind is always aft of the apparent wind. If we have wind coming over the beam in a moving vessel, we know the true wind on the water is coming from more toward the quarter. Apparent wind on the bow, means the true wind is more toward the beam. 

Second, the faster we go in the same true wind the more the apparent wind moves forward.  In the extreme case where the true wind is very small compared to our speed, then the apparent wind will be essentially dead ahead, as in Figure 1.

Figure 3. Apparent wind moves forward as our speed increases in the same true wind, and vice versa if we slow down.

We also learn very quickly that for these computations to be useful, all of the instruments involved must be carefully calibrated and checked on all points of sail: AWS, AWA, HDG, and BSP. The vector solutions can be very sensitive to small errors in any one of them. This is a big task for the navigator.

So big, in fact, that it is fair to ask, why should we go to all of this trouble, and indeed expense,  in getting and calibrating quality instruments? You could say that we sail by the apparent wind and that is all we need to know; why do we care so much about the true wind?

The answer is, from the navigator's and tactician's point of view, the true wind is everything!  

The sail trimmers and helmsmen live by and respond immediately to every change in the apparent wind, but the desired heading, determined by the navigator, and when it should change, is all based on the true wind. Plus, the evaluation of the present performance of the boat is based on the true wind, i.e., for the present TWS and TWA are we going as fast as we should be?

When we tack, our heading will change by twice the TWA, centered on the TWD. When we jibe, our stern crosses the TWD and our heading changes by twice (180 - TWA). 

Figure 4. How TWD and TWA relate to our sailing tracks and laylines.

We will come back later to how the TWA enters into the important task of evaluating sailing performance using polar diagrams, which is also the basis of computing optimum routes across a varying wind forecast. 

_________

In the above basic description, we determined the TWS, TWA, and TWD from AWS and AWA corrected for boat speed BSP and HDG through the water. Thus we were talking there about true wind relative to the water, and we have assumed that the water itself is not moving, meaning no current. 

Once we are sailing in water with current, we have to be more aware of our terminology. It does not matter for sailing analysis what the cause of the wind might be, but in the presence of current, we have to be aware that the wind we are calling the "true wind" is not the same as what meteorologists, forecasts, and buoy reports call "true wind." These official wind forecasts are relative to the fixed ground. 

If the local buoy reads 10 kts from the north (the meteorologist's true wind), and I hop in my boat headed due north in a current that flows 2 kts toward the north, and I am not yet moving through the water (BSP = 0; underway, but not making way), then I will read AWS = 12 kts with AWA = 00 (10 kts from the wind + 2 kts from the current). Then as a sailor I will interpret this as a true wind of 12 kts, and indeed my sails would respond accordingly. 

Once I start moving through the water, the AWS and AWA will change, but once I correct for HDG and BSP I will come back to a sailor's TWS = 12 and TWD = 360.

The way sailors distinguish these two true wind values is to call the meteorological true wind the ground wind. Thus we call wind relative to the water true wind and wind relative to the fixed earth ground wind.  (It has been proposed that the sailor's true wind should be called the water wind, but this never did catch on, in part because sailors have used the term true wind for a long time, plus the polar diagrams use the term true wind as well.)

Figure 5. Finding sailor's true wind in the presence of current. The sailor has no knowledge of the presence of current with just this information. It will take GPS measurements to reveal the presence of current. Sailors call the true wind relative to ground the "ground wind."

The distinction between how we compute true wind vs ground wind is very direct once we have GPS data. True wind is the measured apparent wind corrected for a boat wind determined by (BSP, HDG), whereas the ground wind is found by correcting the same apparent wind for a boat wind determined by (SOG, COG), which will be different if there is current and or leeway, as shown in the figure below.

Figure 6. Computing true wind vs ground wind. The true wind using HDG and BSP assume there is no leeway taking place. Later when we introduce leeway, these will change to CTW and STW for course and speed through the water.

__________________

The above is the background to wind on the water for sailors, but we are not done if we want to do our very best with navigation and routing. We have dealt with idealized measurements and have not accounted for the important factors of heel and leeway, which have separate and related influences.

Heel has a basic geometric effect on the wind vane, in that when it is tilted the wind vane does not feel the full force of the wind, because the component perpendicular to the centerline is diminished. The net effect is the AWA and AWS we measure when heeled over are slightly too small, so we have to correct them. This in turn will affect the all important TWA and TWS.

 The heel in turn is usually associated with a leeway that will further affect the most accurate values of TWA, TWS, and TWD, as well as GWS and GWD

The AW corrections, derived below, are sometimes corrected within the wind instruments (such as B&G H5000 or newer) or more commonly, within the nav app reading the apparent wind and computing the true wind. Here AWAm and AWSm are the measured values from the anemometer, and AWAc and AWSc are the corrected values that are used to compute the true wind. It is up to the nav app to decide which of these it chooses to display.

AWAc = atan [ tan(AWAm)/cos(heel) ]

AWSc = AWSm x cos(AWAm)/cos(AWAc)

Suppose wind instruments measure AWAm (34.3º) and AWSm (14.5 kt), and our digital inclinometer measures a heel angle (23º). 

AWAc = atan [ tan(AWAm)/cos(heel) ] 

            = atan [ tan(34.3)/cos(23) ] = 36.5

AWSc = AWSm x cos(AWAm)/cos(AWAc)

            = 14.5 x cos(34.3)/cos(36.5) = 14.5 x 1.03 = 14.9

These are both small changes, but they all add up, and these are the values that should be used in the final true wind computations. (For quick estimates, heel narrows the correct apparent wind angle by just under a factor of cos(heel), which at 20º heel is 0.94 or 6%.)

Figure 7. Overview of heel angle errors on AWA. For AWA = 30º with a heel of 25º, the uncorrected AWA will be too small by 2.5º. Diagram adapted from Ref 8

The derivation of the AWA and AWS corrections are shown below.

Figure 8. AWA and AWS corrections due to heel. When heeled over, the AWA and AWS we measure are slightly too small by the amounts indicated. We start with an apparent wind vector (AWSx, AWSy, 0), which means we assume the air flow over the meter is parallel to the water, without notable upwash from the sails. We are also neglecting the effect of mast twist. This is a common assumption, but it overlooks what could be an important correction. We look into how to incorporate that later on. When the boat heels, the y component (athwartship) of the apparent wind narrows, but the x component along the centerline does not change.

__________________

Now that we have corrected AWA and AWS for heel (putting off for now the upwash correction), we can look into finding an improved true wind. The presence of heel is often a reminder that the boat could be slipping to leeward to some degree, called the leeway angle (LWY), but it is important to note that heel does not cause leeway. A boat can stand essentially straight up and slip to leeward, especially in light air. 

With leeway, the track of the boat through the water, called course through water (CTW),  is not the same as the heading of the boat. Instead, we have:

CTW = HDG + LWY.

When the boat is slipping to leeward,  the proper reference for the true wind over the sails is not the centerline (HDG), but rather the track line (CTW). Leeway can, with some effort, be measured from the angle the wake relative to the centerline. The wake will tilt to windward by the LWY angle. Some wind instruments suggest dropping a series of markers off the stern and then taking a bearing to the line they make to compare with your heading.  In principle, no-moving-parts electromagnetic knotmeters that measure both forward and sideways speed can be used to determine leeway, but they are considered problematic by some racers.

 

It has been found, however, that a workable approximation to leeway can be made from the theoretical balancing of the force on the sails and the lifting force of the water flow over the keel. This leads to the commonly used expression for LWY in degrees:

LWY = k x Heel / STW^2, 

where k is called the leeway coefficient, which is typically 9 to 16 for sailboats; Heel is in degrees; and STW^2 is the square of the boat speed through the water in kts. With a measured heel angle, we can compute the LWY and from that get CTW, and then relate the heel-corrected apparent wind to the CTW for an improved value of the true wind. We also get a better value for the current speed (CS) and current direction (CD) correcting for leeway in this manner.

The geometry to be solved is shown in Figure 9.

Figure 9. Correcting apparent wind for heel and leeway. The bottom image is adapted from Ref. 1. In this image, the apparent wind and boat speed are assumed to be the values corrected for heel, thus: AWA=AWAc, AWS=AWSc, and STW=STWc. 

We can solve for TWS as: TWS^2 = TWSy^2 + TWSx^2, where TWSy =AWSxSin(AWA+LWY) and TWSx=AWSxCos(AWA+LWY)-STW] and AWA = ATan(TWSy/TWSx).

Alternatively, define the AW vector as (AWS, AWD) with AWD=CTW+LWY+AWA, and the BW vector as (STW, CTW) and solve for the vector difference between them. For ground wind, use the same AW vector corrected for the BW vector relative to the ground, (COG, SOG).

__________________

To help understand the wind corrections that your favorite nav app is making, we created an app (WindCor) that computes the winds with No corrections, Corrections for heel only, and Corrections for heel and leeway. Below is the use of the app comparing to the outputs from the popular navigation and tactics app Expedition, to which we sent these simulated NMEA sentences for HDG, STW, AWS, AWA, COG, SOG, and Heel by UDP:

$GPGGA,040000.000,3813.55991,N,6848.559458,W,1,10,1.8,1,M,,,,,*28

$GPMWV,48.9,R,19.09,N,A*1E

$GPRMC,040000.000,A,3813.55991,N,6848.559458,W,10.788,145.1,230624,14.1,W*64

$GPVHW,161.2,T,,M,8.833,N,,K*46

$GPXDR,A,-25.61,D,HEEL,P,101789,P,PRESSURE*58

Figure 10. Meters (Number Boxes) in Expedition from expeditionmarine.com. Top has no Heel nor LWY input; middle data adds Heel input, but has k=0 to rule out LWY corrections; and bottom  shows all inputs and all corrections. Data on the right are computed with WindCor using the formalism describe above. This GWS sample has the wind cups at 10 m. The same example below shows results at 15 m.

The agreement is very close, but we would need more comparisons to conclude that this is the same formalism in use. We note a common convention of displaying the measured AWS and AWA, even though it appears that the corrected values are used for the true wind data.

The WindCor app can be used to check these results. The app is stored in our starpath.com/calc index to various computers.  Below is a sample output.

Figure 11. Sample screen from WindCor

The importance of true wind for navigation is outlined above, but we also need the best value of TWS and TWA to evaluate sailing performance relative to the polar diagram for the boat.  The original forms of these diagrams made by a VPP (velocity prediction program) or yacht designer assume the TWS and TWA are the actual values the sails are seeing, which means they are relative to the water not the boat.

The ORC VPP is a physics simulation that solves equilibrium equations for the boat as a body moving through the water. In that model, the boat experiences hydrodynamic forces along (and perpendicular to) its actual direction of motion through the water — i.e., its track through the water, not its centerline. 

So in principle the best TW values to use when evaluating performance or building a better polar would be the TW value corrected for both heel and leeway.

Figure 12. Sample wind display from a big boat on a fast reach. From an A and T Instruments brochure.

Our accurate measurement of ground wind is used to evaluate model forecasts that predict the wind at 10 meters above the water, whereas anemometers at the mast head are typically higher than that. The wind speed increases with height above the water as it becomes less slowed by friction, so we must typically reduce the measured GWS  to get the 10m values. This can be computed several ways, but a common one we use in WindCor is GWS10 = GWSc x (10/h)^0.11. This power can vary from 0.10 to 0.15.

References

1. Yacht Performance with Computers by David R Pedrick and Richard S. McCurdy, Chesapeake Sailing Yacht Symposium, January, 1981. (McCurdy was a co-founder of Ockam Instruments.)

2. bandg.com/en-nz/service/BG-knowledge-base/?contentTitle=H5000-What-is-Leeway-Corrected-Wind&contentId=023_006-565

3. evolution-tactic.com/en/polar-curves

"When polar curves are created by VPP programs, all TWA are measured from the wind to the boat’s course, NOT to its centerline..."

4. Introduction to Polar Diagrams and Optimum VMC davidburchnavigation.blogspot.com/2022/02/VMC.html

5. orc.org/organization/velocity-prediction-program-vpp

6. orc.org/uploads/files/ORCsy/2025/2025-VPP-Documentation.pdf
Figure 3.2 states explicitly that the forces are balanced about the "track axis."

7. These nuances of true wind determination are discussed in Appendix 9 of Modern Marine Weather. This book includes extensive discussion of the practice and value of using measured ground wind and pressure to evaluate model forecasts.

8. sailboatinstruments.blogspot.com/2011/02/corrections-to-apparent-wind-angle.html

9. davidburchnavigation.blogspot.com/2018/04/effect-of-leeway-on-knotmeter-speed.html

10. davidburchnavigation.blogspot.com/2020/01/progress-to-weather.html
More notes on leeway.

New Tidal Current Resource for Swiftsure and R2AK Sailors

The excellent (free for Mac and PC)  navigation app qtVlm has just added a new optional feature that is free for testing until May 15, 2026—after which it becomes a subscription option. Namely they have added an internal GRIB server that now includes the Operational Forecast System (OFC) model for tide and current forecasts, as well as other models. 

This means we are no longer limited to the NOAA harmonic predictions of the currents at spot locations, at just a few specific times, but now we have currents at all locations at all times. Plus the OFS model takes into account local wind and pressure as well as river run off, which makes the forecasts more accurate than the harmonic predictions, which do not account for local environmental conditions. (We still need to use the harmonics for specific data at narrow passes where NOAA has metered stations.)

Sample of OFS currents in San Francisco

The OFS updated four times a day, with forecasts every hour out to 2 days in most cases, but 3 days in the Pacific NW, which is covered by Salish Sea and Columbia River region (SSC-OFS). This region takes us to the north end of Vancouver Island, where we would switch to the West Coast region (WC-OFS) — but the Canadian harmonic data would still be valuable along the Canadian waters of the Inside Passage.

Likewise, Randy Washburne's book Southeast Alaska Current Atlas remains a leading reference for those waters.

For all of Swiftsure and for any racing in Puget Sound or the San Juans, the OFS SSC data are certainly the most important source, which now can be loaded with a button click into qtVlm, which also has state of the art presentation of NOAA charts.

We can now, for example, add the OFS currents to the HRRR winds and do realistic optimum sailboat routing on inland waters. The new qtVlm GRIB server lets you load both of these at once into one of three Grib slots.

OFS currents are described in detail in Modern Marine Weather, 4th ed. 

To learn how we use qtVlm in our online training courses, see this note on Getting Started with qtVlm. The Training Mode discussed there expedites learning qtVlm that has so many features, plus it adds charts, harmonics, and other resources.  qtVlm is among the top of the line in weather analysis and routing, and it is in fact the top of the line in electronic navigational chart (ENC) presentation.

Here is a short video showing how to access these OFS current data, which starts with downloading and installing the latest version: https://www.meltemus.com/index.php/en/download (which you can do from the Getting Started page, with video examples.)

Video demo of viewing OFS currents. See our qtVlm playlist for more info on qtVlm

Once the free intro period is over (May 15, 2026), the main app remains free, but the convenient GRIB service will be come a subscription add-on.

Below are the regions West Coast and Pac NW regions covered by the OFS. The workhorse is the Salish Sea and Columbia River (SSC-OFS). The WC data along route to Ketchikan (north of the SSC limit) is not as precise, but should supplement the US and Canadian harmonic predictions.

Grib Offsets for Routing in qtVlm

When we compute the optimum sailing route in a nav app like qtVlm, we use the polar diagram of the boat to provide its performance expectations in various wind conditions, and we rely on a numerical weather model forecast of the wind, such as the GFS global model for ocean routes and the HRRR regional model for the inland and coastal routes leading to the ocean.

Once underway, the route always starts from our present position and present time, using the forecasted wind for that time and place. It is indeed always a forecast we are using, because even if we download the forecast when first available it will be based on the most recent synoptic time (00, 06, 12, 18z), which will be some 5 hr in the past when we get it.

It could be, for example, that the model's surface analysis, valid at the synoptic time, was very close to the actual winds we had then, but now, at the time of the route computation, 5 or 6 hours later, the wind could differ from what the model forecasted.

Here is an example. At the start time and place, the forecast for the wind is 8.6 kts from 219, but when we determine the true wind from our own (calibrated) instruments it is 12.5 kts from 248. It would not make sense at all, to compute a route starting with this wrong wind. The result could be significantly wrong, and difficult to correct.

Luckily, most sophisticated routing routines give us the option to account for this wind difference, and here we look at how qtVlm does this.  The function is accessed from the Grib Config page under Corrections (windsock icon in the toolbar).

Here we force the wind to be the right speed and direction observed, and then choose how long you want it to take to linearly blend back into the forecasted value. When doing this underway, there is a button to read the wind instruments values, and to set the start time to now.

qtVlm has an excellent way to learn what the average offset is for wind speed and direction in the Voyage Data Recorder (VDR) option. We can graph the model wind and the measured wind and compare the two.

This sample shows two model winds and the gusts from one compared to the measured wind at the masthead corrected to 10 meters of the model wind (discussed below). Here we have to decrease the model wind by 10.3/11.5 = 0.90 = 90%. A similar plot gives the direction offset.

The VDR data can be exported as a CSV and loaded into Excel for more accurate averages.

The masthead offset is entered in the VDR settings page.

In the example below we choose to blend our forced wind back to the grib value in 3 hr. Then we would have to compare again the forecast with the wind instruments. If the wind is steady in the forecast and instruments, we could extend this longer, if not, we reset the wind, and run the route computation (called a routing in qtVlm) again. A running VDR plot of the two winds helps us choose how and when to blend back to pure model wind.

_____________

To see how this works, you can load a grib wind forecast, then create a 4 or 5 hour route across the wind, and to simplify the analysis, turn the engine on at a fixed speed of say 6.0 kts.  

Then we can set the route's logbook display to a 60-minute interval. This lets us see what the app thinks the wind is for routing at each hour along the route. Below are sample outputs.  At the end there is a link to a video that shows more specifically how this can be set up for testing. 

In the above, the set up screen is on the right, and top left is the model forecasted wind at each hour with the forced wind turned off.  Next to it is the wind at each hour with the forced start time wind turned on and set to return to the grib in 3 hr.

This is an easy to use tool, and indeed required operation for any routing underway. It is the navigators job to monitor the forecasts with the observations to know when to re-tweak the winds and run the route again.

_____________

Now we need to say (or at least mention) the often unspoken part: for this to work, we need to have accurate (calibrated) instruments. We measure the apparent wind (AW), typically at the masthead, and then we convert that to true wind (TW) at 10 meters (33 ft) above the surface, which is what the forecasts tell us.  Some sophisticated wind instruments do all this for us, but with basic  instruments, we count on qtVlm to make the vector conversion from measured AW to derived TW based on the COG and SOG from the GPS.  

The anemometer height correction for the speed is explained in Appendix 9 of our textbook Modern Marine Weather — in a steady wind, the wind speed increases with height above the water, because the surface friction slowing it down decreases as we get farther from the water.

Since the anemometers of boats over 25 ft or so in length are higher than 10 m above the water level, the wind they read will be greater than the wind at 1o m. For a 70 ft (21 m) mast, the correction would be about +10%; taller masts have larger corrections. 

In other words, with a 10% height correction, a model forecast of 8.6 kts means you should read 1.10 x 8.6 = 9.5 kts TWS for exact agreement. In the example above, we read 12.5 kts, so the actual correction we want is 12.5/9.5 = 1.32, which is an improvement over the 1.46 we used above. 

In other words, when you press the "Wind from instruments" button mentioned above, it reads the wind from the masthead (12.5 kt), but we would want the forecast at 10 m to be 10% less, so we should reduce that to 12.5/1.10 = 11.4, then we are making the right scaling 11.4/8.6 = 1.32.

Which, granted is a small correction. Indeed, the accuracy of the wind forecasts and actual official wind measurements from buoys, stations, and ASCAT is something like ±2 kts, and we should be happy if our own measurements are that accurate, but that does not mean we should throw out or ignore corrections of that magnitude that we know exist. The force of the wind is proportional to the square of the wind speed, so we don't want to lose any accuracy we do not have to. There are enough other uncertainties in the routing process to deal with.

_____________

qtVlm also has an option for simply shifting the wind to desired values and leaving it at those values till it is changed. But this is more for just creating a wind without any grib input for practice with simulated routes and routing. This is illustrated below. 

Here we see the wind throughout the forecast (top right) is increased by 146% and shifted by 29º relative to the underlying grib wind (top left). However, we would get this same wind if we just shut off the grib forecast completely. In other words, this function is not presented as an underway routing aid, it is more a simulation and training aid.

_______________

The treatment of currents in routing is another crucial factor in many cases. When we do a routing computation we load at least two grib files. One for the wind and one for the currents. Global wind models extend out 10 to 16 day, but ocean current forecasts often do not extend out over the full duration of an ocean route (see table below), but routing apps usually have the option to extend the last currents forecast to the end of the route. In qtVlm this is done at menu Config/Gribs and Harmonics/Grib and turn on "Automatically extend Current grib last date."

Generally this is not a problem because most ocean currents do not change rapidly with time. In some cases, it could mean that the ends of longer routes into areas with notable current may not be right on early route computations, but this is often the case, even without currents. We will be running the routing computation multiple times a day, so this takes care of itself.

Current data from Modern Marine Weather.

In some ocean popular races, Newport to Bermuda and Sydney to Hobart come to mind, currents can be a key factor in optimum routing, and navigators usually spend a long time trying to figure what the best data will be. But the current, like the wind, is something we can measure underway, and then correct the  current forecasts accordingly. 

The measurement is similar to measuring wind for wind corrections in that we need well calibrated instruments: in this case a heading sensor, to get course through the water (CTW), and a knotmeter, to get speed through the water (STW). Then, like the wind, we need qtVm to do the vector math to get the current, which is the vector difference between [CTW, STW] from your instruments and [COG, SOG] from the GPS.

This is not an instantaneous measurement. The vector solution will bounce around, but we can get a useful average with time to compare with the forecasts.  We can, for example,  view a plot of the current speed (CS) and direction (CD) in the histogram tab in the route log, and this way find good values to use for the present current. 

Once we know the current we have two options in qtVlm for corrections.

(1) With no current model to work with, we can just force the current to be what we measure and use that for short term routing.  This is also the control we use to just simulate current for practice with current sailings and routing.

(2) If we have a model forecast, we can figure the percent correction in speed and direction, and enter it, but even with a model forecast we have to monitor this. In some areas we have steady currents over large areas and time, but in others we have to deal with meanders and eddies. In some cases the eddies in the middle of the ocean can be just some several hundreds of miles in diameter.  

We might run across vagabond rivers (sides of an eddy) of over a knot in the middle of the ocean, that could be a goldmine or lead balloon, depending on what side we are on.  Knowing this and careful monitoring is key.  You will know from the forecasts if such eddies are likely, but they are not likely to be precisely where forecasted.

An important use of the current offsets comes with the use of the OSCAR current data for ocean routing. See starpath.com/OSCAR. In many cases we have found that the flow pattern of the OSCAR data are the best guideline for ocean routing, but you may find that the OSCAR speeds are too low by 20 or 30%, because they are an average over 24 hr. So you can download the OSCAR data (it will be for one day alone, 3 days ago) and then extend it as noted above to the end of your wind grib data, and then enhance the speed at the start of the routing by say 125%, but leave the direction unchanged. Then once you get some reliable current measurements you can adjust the corrections.

Note this is for ocean routing. In US waters, we would start off with the Operational Forecast System (OFS) tidal currents till we get some distance off shore. They account for local tides, winds, and pressures. 

We have more general notes on currents at starpath.com/currents.