## Thursday, August 31, 2017

### Wind Speed from Beaufort Force Number

The Beaufort scale is the primary way mariners relate sea state and wind speed. It can also be used as a way to specify wind speeds without reference to the sea state, but this is not used in that manner much in the US. In the UK, however, the MetOffice often gives marine wind forecasts in terms of the Beaufort Force number, according to this standard table, as does the official GMDSS reports from the WMO. (See our Glossary entry on how wind speed got into this system originally.)

The number on the left is called the Beaufort force number (BFN). Used in this manner, it is similar to using feathers on wind barbs on weather maps, which are always ± 2.5 kts. That is, one long and one short feather is nominally 15 kts, but is actually 15 kts ± 2.5 kts. A forecasted 17.5 kt wind would get the same wind barb display as one with 12.5 kts. We do not switch to two long feathers (nominally 20 kts) until 17.6 kts. ( I am not sure how the programs handle exactly 0.5 in this application.... they likely round up.)

The range of wind speeds within a specific BFN varies from 1 to 4 kts, but the average is about 2.5, same as the wind feather spread.

This note is to document a way to estimate wind from the BFN that we have used for years, but it came up in class today that we do not have this written out anywhere.  It can be useful for those of us that are not accustomed to using BFN for windspeed designation.  Furthermore, the wind roses on Pilot charts are often expressed using BFN, in that they show arrows with feathers, and in their system the number of feathers is the BFN, as shown below.

Figure 8.2-5 Section of a U.S. Pilot Chart. August winds near Cuba are given for each 2° of Lat-Lon. In the top right corner, the wind has a 39% probability of being from the east and 32% from the southeast. When the probability is less than 29%, it is represented by the length of the line, which is relative to a printed scale not shown here.
Predicted wind speeds are in Beaufort Force numbers, with each side of a feather being one number. In the top right the E and SE winds are Force 4 (11 to 16 kts), the much less likely NE wind would be Force 3 (7 to 10 kts).
The circled numbers are the percentage calms at each location. The current arrows in this chart are marked with speed in kts with a “steadiness” depicted by the line style: a heavy line means 50% steady, thinner lines means 25% to 50% steady, and a dashed current arrow means steadiness is less than 25%. See the steady Gulf Stream near Florida, and the weak unsteady back-stream south of Cuba. Other Pilot Charts do not have the steadiness data and some give the speeds. From Modern Marine Weather, 2nd ed.

Thus we create a short cut for figuring wind speeds from BFN, namely Wind speed (in kts) = BFN x 6 - 10, or just

kts = 6N-10.

Below are statistics and errors of this method. It does not work for n = 1 (1-3 kts), nor n = 2 (4-6 kts).

## Monday, August 21, 2017

### Celestial Navigators: Save Your Eclipse Viewing Glasses.

If you were lucky enough to see the full totality, then chances are you will save your glasses Forever. But if you saw just part of it, they may wander away.  If you do cel nav, there is a use for these, so they are worth hanging onto.

The most accurate way to measure a sextant's index correction involves looking directly at the sun—which is not at all a part of normal cel nav. We normally look only to the horizon below it for regular sights, in which case the stock filters on the sextant do the job. To do the special "solar index correction," on the other hand, we look right at the sun with the sextant set to 0º 0', so we need exactly the type of filter used for the eclipse viewing. This type of filter foil is normally rather expensive. The price is lower when thousands of square yards are produced at one time, and many government agencies subsidize the production of them.

We discuss the technique and how to make the filters in both our books Celestial Navigation: A Complete Home Study Course and How to Use Plastic Sextants: with Applications to Metal Sextants and a Review of Sextant Piloting.  It is the same method used by Lewis and Clark and other early land based explorers. The special filter we need for the sextant scope can be made from these glasses, more or less as explained in those books.

Work forms for the solar index correction with some brief level of instruction can be dowloaded as part of complimentary work forms package we have at the cel nav book support page.

### Showing the Right Day Shape

Study of the International Navigation Rules is a rewarding pastime, practical and captivating. They constitute a remarkable document with an immense assigned task—the prevention of collisions between a vast array of vessels in a vast array of circumstances: vessels barely visible at 100 yards to vessels the size of horizontal skyscrapers; drifting without power or traveling at 30 knots or more; following unmarked lanes or crisscrossing open waters offering nothing more than an educated guess as to their intended course; in all conditions of weather, clear or fog, calm or storm; and often with no common language between their drivers.

But despite this enormous assignment, they do the job. Collisions can always be traced to at least one violation of the Rules by both vessels involved in the collision. Thus we teach that from a statistical point of view alone, you will not be in a collision if you obey the Rules yourself. The key to avoiding further proof of this is a thorough understanding of the Rules, and how to apply them, including the rules on what to do if an approaching vessel does not obey the rules.

Part of the Rules includes a specification of day shapes that vessels should show when for some reason they are  "unable to maneuver as required by these Rules."  After the collision, the USS John S McCain was able to make it back to port under her own power (according to reports), but was clearly restricted in maneuverability, which calls for showing one of these day shapes on the vessel. And they did show a day shape, which appears to be ball-diamond-ball.

Here is the pertinent Rule:

Rule 27 - Vessels Not Under Command or Restricted in Their Ability to Maneuver

(a) A vessel not under command shall exhibit:
(i) two all-round red lights in a vertical line where they can best be seen;
(ii) two balls or similar shapes in a vertical line where they can best be seen;
(iii) when making way through the water, in addition to the lights prescribed in this paragraph, sidelights and a sternlight.

(b) A vessel restricted in her ability to maneuver, except a vessel engaged in mineclearance operations, shall exhibit:
(i) three all-round lights in a vertical line where they can best be seen. The highest and lowest of these lights shall be red and the middle light shall be white;
(ii) three shapes in a vertical line where they can best be seen. The highest and lowest of these shapes shall be balls and the middle one a diamond.
(iii) when making way through the water, a masthead light(s), sidelights and a sternlight in addition to the lights prescribed in Rule 27(b)(i);
(iv) when at anchor, in addition to the lights or shapes prescribed in Rule 27(b)(i) and (ii), the light, lights, or shapes prescribed in Rule 30.

At this point we need to refer to the definitions, which are in Rule 3.

Rule 3 - General Definitions

For the purpose of these Rules [ and 33 CFR §83-90 ], except where the context otherwise requires:

(f) The term "vessel not under command" means a vessel which through some exceptional circumstance is unable to maneuver as required by these Rules and is therefore unable to keep out of the way of another vessel.

(g) The term "vessel restricted in her ability to maneuver" means a vessel which from the nature of her work is restricted in her ability to maneuver as required by these Rules and is therefore unable to keep out of the way of another vessel. The term "vessels restricted in their ability to maneuver" shall include but not be limited to:

(i) A vessel engaged in laying, servicing, or picking up a navigational mark, submarine cable or pipeline;
(ii) A vessel engaged in dredging, surveying or underwater operations;
(iii) A vessel engaged in replenishment or transferring persons, provisions or cargo while underway;
(iv) A vessel engaged in the launching or recovery of aircraft;
(v) A vessel engaged in mine clearance operations;
(vi) A vessel engaged in a towing operation such as severely restricts the towing vessel and her tow in their ability to deviate from their course.

So, admittedly not knowing precisely what "not be limited to" might encompass in this definition, we see two choices for the day shape:  limited maneuverability because of "the nature of her work," which would be ball diamond ball, or limited maneuverability because of "some exceptional circumstance," which would call for two balls in a vertical line.

The question we are left with is this: is a collision of a war ship with a tanker in peace time considered "the nature of her work" or is it "some exceptional circumstance?

Or more broadly, we have the question: does the vessel's choice of day shape matter at all, or is it trying to tell us something?

This is a maritime tragedy involving possibly the loss of life and certainly injuries. That is the main concern, not day shapes, but anything we might learn that could help prevent this in the future is worth pursuing.

We do have an unfortunate terminology to deal with. Essentially every vessel that is according to the Rules "not under command," is indeed under command at all times, even if they cannot, say, turn the vessel to the right or left. (The macabre nemonic we hear in the classroom "red over red, the captain is dead" is never the controlling factor, and only buffers the poor terminology.) It is a technical term, in the sense of being defined in the Rules, though not completely logical. It would seem unlikely that such reasoning could take place, but it could be difficult for the Commander of a war ship to put up a sign that says I am not under command, in which case "restricted maneuverability" could be a compromise for obtaining the needed extra right of way that is granted once either of the day shapes is shown.

It seems this collision and the return to port took place in daylight, which somewhat reduces the impact of the day shape choice. At night, this distinction would have greater bearing in the event of a subsequent collision. The extra lights corresponding to these two shapes are different (red over red, vs. red over white over red) and the potential of these being confused amongst other navigation lights becomes a possibility that has been addressed in collision court cases.  Illegal lights almost guarantees some share of liability, regardless of the primary cause of a collision.

With all that said, if you are a small craft captain and get stuck without power in the middle of the shipping lanes without a radio, you might want to have two of these on hand that you can raise in the rigging, regardless of how you are feeling otherwise.

_____

Just found this picture. Not sure if it was earlier or later than the one above. Not sure what it means, but looks like two balls in this one.  They did show up later in the transit and in port with ball diamond ball

Here is another pic from long before the collision, showing ball diamond ball during some type of maneuver that does not appear to be restricted, so it is some exercise that needs clearance or will need it shortly.

In response to Carl's comment below: I agree. The single flag showing is likely Romeo, meaning they are preparing to take on provisions or fuel.

This is a perfectly normal use of ball diamond ball. A collision is another question.

## Saturday, August 19, 2017

### Viewing Eclipse by Boat May Bring Surprises

Just learned that a friend of ours will be headed to Portland from the south during the eclipse, which brings up a couple points related to a recent post here.  Namely, what will happen when the air temp drops 10º or so when the sun is obscured?

Below is the UW WRF model meteogram for just off shore the OR coast.

It will be interesting to learn what mariners see offshore when the temperature drops rather quickly at sea. In principle, it could lead to some overcast or even fog.  Note in the pic above that the dew point and air temp are forecasted to be close to begin with, ie won’t take much deviation from this model forecast to be fog in the first place, but during the sun eclipse the temp will definitely drop to dew point.. could drop well below that.

The data are just off shore. It will be interesting to see if these thoughts show up in any of the official marine forecasts.  They should be looking at this same WRF model from UW.

On land in Ballard (Seattle), we see this is not so much an issue.

## Wednesday, August 16, 2017

### BC Canada Marine Weather Guide Back in Circulation

A wonderful resource similar to the now defunct Marine Weather Services Charts for US waters has reemerged after going missing for a long time. This one is for British Columbia.  This is a must have publication for sailing in BC. Easy to use crucial information.

We list three new links because this tends to move around and one of these then might work!  Latest version in Aug 2017 is dated 2013.  But these are new links so the implication is nothing has changed.

The last gets the pdf directly, the first two show sample pages with explanation and then the link.

HTML version on the Environment and Climate Change Canada site:
English - http://ec.gc.ca/meteo-weather/default.asp?lang=En&n=451553A6-1

English - http://www.publications.gc.ca/site/eng/9.698081/publication.html

English - http://publications.gc.ca/collections/collection_2014/ec/En56-233-2013-eng.pdf

Sample page from the booklet.

## Friday, August 11, 2017

### Comparing RTOFS and NCOM Model Forecasts to HF Radar Current Measurements

The RTOFS and NCOM ocean models and their ocean surface current predictions are discussed at the Ocean Prediction Center. RTOFS has global coverage with a resolution of 1/12º (9.3 km). NCOM covers selected waters adjacent to the US, plus HI and PR. It has resolution of 1/36º (3.1 km). RTOFS offers 3-h forecasts out to 8 days; NCOM offers 3-h forecasts out to 3 days. Both start at 00z, with daily runs, and a 16- and 12-hr delay, respectively.

The RTOFS data is very easy to obtain underway in GRIB format from several sources; the NCOM GRIB data can be obtained underway just as easily using LuckGrib on a Mac, but acquisition using a PC requires several custom steps. Racing sailors (always) and fishermen (often), and to various extents every mariner cares to have the best possible current forecasts, so the question arises as to which of these two models is best where there is overlapping coverage?

Our goal is to look into ways to make this evaluation as best we can, as we continue to look for publications that present this data. We also remain aware of the practical solution that avoids this work in some cases. Namely, we download both models underway, then measure the actual current we experience at the moment (the vector difference between COG-SOG and HDG-BSP), and see who is best... or if either is close enough to be useful. But this does not solve the main task of computing optimum routes based on wind, waves, and currents. For this we need some guidelines to what might be best current data.

Two ways to do this comes to mind. One is look for buoys that record currents and compare them over some extended period—ocean currents vary far more than our pilot charts or older textbooks might imply. But these point comparisons do not reflect the crucial flow patterns, especially the mesoscale eddies that can put much stronger current in our path than we might have guessed.

The other method is to compare coastal current measurements from HF radar stations with the two forecasts, and this note is a first step at that.

The validity of this approach is yet to be seen. Our best hope is a qualitative comparison. We would consider ± 30º and ± 0.3 kt as full agreement. Even ± 45º and ± 0.5 kts would be encouraging, meaning to know the ocean currents to that latter level of accuracy would be beneficial to ocean routing—as opposed to having them be wrong by more than that, which would be detrimental. The bar is low: do no harm.

Coastal currents include varying levels of tidal influence, and it is not clear (to me) how the models account for this. We can zoom in onto the weaker currents near shore and watch them vary on a tidal period, so some influence is definitely there. We can also see nice demos of a rotating current in some cases. HFR stations offer various resolutions from 0.5 km to 6 km along with 25-h averages over these. We have used the 6-km data as a compromise between the RTOFS (9 km) and NCOM (3 km).

For a quick overview we use a graphic analysis with readily available tools. We get the HRF graphic data from Coastal Observing Research and Development Center and we download and display the model forecasts using the Mac app LuckGrib. Then we capture the current arrows from the HFR data and overlay them on the forecasts using Photoshop.

Below is a sample of the HFR data from the link above.

The insert shows the HI data we used below. Current speeds are scaled to the colorbar on the left.

To compare speeds, we have made custom contour fill colors in the model display that match the colorbar used in the HFR display as shown below.

The color bar from the HFR (black border) is shown here on top of the gradient design page from LuckGrib, which has a color picker that allows for precise duplication of the colorbar, and an option to mute the colors with an Opacity control. A sample of the use of this scheme is below.

The colored arrows are from HFR, which are here overlaid on the model prediction for the corresponding times. The black arrows are from the model, and the speed from the model is the background color, taking into account that these colors had to be muted some (opacity control) so all arrows show. Actual colorbars used are shown in each of the pictures below.

Thus the yellow arrow at A means HFR and model speed agreed very closely. Arrow C is slightly darker (stronger current) than arrow D, but both are in agreement with the model (keeping in mind its muted color, and our lax tolerance on agreement). The orange arrow at B is about in full agreement. On the other hand the model forecast at arrow E is light blue on a yellow background, which means the model currents are too strong by maybe 0.5 kts or so. Likewise the the observed currents at F are notably stronger than forecasted.

That is the system we apply to the overlays shown below.

The above are for Aug 9, 12z.  Both models underestimate the speeds. NCOM gives hints that strong current could be present, actually matching in speed and direction at one point. The NCOM does a bit better when we look at the 2 km HFR data (not shown), though hard to choose one over the other for general flow patten. Both models call for a N to NW flow, SW of the island, which is about right. The knot or so of SE current in the bottom left of the image is better done by NCOM.

Below is the same location 4h later.

Again, similar with some bias to the NCOM, which does, for example, a good job on the eddy in the SW corner. Both miss details of the flow to the far west of the island. NCOM a bit better on the speeds.  Again, the HFR data are 6 km resolution. At the end of this note we show all stations compared to 25-h HFR averages.

(Note we chose this comparison at 4h later by simply watching the model predictions to see a change... without further thinking! In retrospect, this would have been better done in increments of 3h because the GRIB viewer had interpolated the 4h data between the 3h and 6h forecasts. The HFR data were indeed at 16z. Again, we learn from this first pass. There is a way to shut off the LuckGrib viewer interpolation in both space and time, I just forgot to do it.)

Now we look at currents in or bordering the Gulf Stream, where the colorbar scale changes from max 2 to max 3.

Here we see notable discrepancies between forecasts and measurements, and I am not sure what to say about it.  We have sent inquiries to experts.  The models are similar, with the NCOM having slightly closer speeds. In both cases we see currents >3kts, so the colorbar could  have been optimized. (We have learned several ways to improve this first pass study.) Note that both models call for a "two-lane" highway of current with a weaker band between them—which would be more interesting if the data actually reflected that. If the measurements are correct, the models have a problem in this region.

Going farther north...and noting that except for the 16z HI data, all else are 12z, Aug 9, with both forecasts being 12 h out from a 00z computation.

Again, it is not clear how to interpret this. RTOFS seems to  have the inside wall and the speeds better matched. Also it is not clear if the upper part of the measurement data might not be from a neighboring station and what implications that might have.

In short, we present this data for the hopes of getting feedback from experts.

Below shows the 25h averages HFR data for each of the above stations at 12z.

The RTOFS does notably better in this case, with the general flow and speed about right over most of the area. The higher-res NCOM, on the other hand, still maintains eddies and flows that were not there when averaged over the past day, and is wrong more often than right.

Again, this remains difficult to understand without guidance from local mariners or scientists. There appears to be a cross Gulf Stream component that is persistent over a daily average, whereas the models just run straight up the coast.

Here we see more of what we might expect on a daily average. Namely, the average directions of the forecasts are about right, but the speeds are lower because they have averaged out flow in different directions.

Several implications have arisen. If the measurements are correct, then the 12z and 16z single-time data above shows the exceptions we might expect... in these waters.  These measurements, however, are all coastal waters, so the behavior offshore could be different, presumably simpler.

We do not see reasons to change our advice over the past years. If you see a prominent eddy forecasted in your waters, then chances are there is an eddy somewhere around there. The models do after all use measured water temperatures and sea level elevations that can mark these anomalies, and they watch them over time. But they might not be precisely where they are plotted, nor of the same strength.

Such forecasted eddies or rivers of current call for careful measurements of the current plus sea water temperature on board. If you drive into one, watch how the current is changing as you proceed, and from that you can judge how to navigate to stay in it if favorable or how to likely best get out of it. If you see one that you are not in, but it could be favorable, then the layout of the forecast can dictate the value of trying to get in it. The time scale of these eddies and meandering bands of stronger currents are long enough to have initial planning done several days before getting to them. On the other hand, in near coastal waters we can see that this is a near real time exercise to find the best current.

Another point that comes clear is that we here at Starpath need to learn more. We are slowly gathering data on known model evaluation as well as known HFR accuracy. It seems we must be cautious in drawing any conclusions from this rough study.

We might learn more by comparing to the OSCAR data, which are averages over the past 10 days, without actual forecasting of the future. OSCAR currents are readily available underway in GRIB format from saildocs.

Based on notes in the References below, a first hand guess at this point is RTOFS is in general overestimating the surface current speeds and OSCAR is (understandably) underestimating it. I will follow up here as we learn more.

—A special thanks to Toby Burch for assistance with the graphics manipulations.

References:

GOFS 3.1 Validation data (2017, the underlying model used by RTOFS)

## Tuesday, August 8, 2017

### UW Soundings Generator

A couple recent notes about fog and smoke depended in the background on how the temperature of the air changes with increasing altitude above the surface.  Normally it is dropping at about 10ºC per 1,000 meters (5.5 Fº per 1,000 ft).  When it does not do that, but rather warms as it rises, we have a temperature inversion that can trap smoke or smog on the surface.  That is what was taking place over the recent fog discussion, and there is a nice way to view that, again from UW Atmospheric Sciences resources online.

We used their Meteogram on the Fly, but they also have a Soundings on the Fly display (called Timeheights on the Fly) of their WRF model, which is one of the best forecasters for local weather.  Below is a sample of that.

These are complex diagrams of temp (red) and dew point (green) as a function of altitude expressed in terms of pressure.  Other such diagrams will also have altitude on the right in km.  They are called skew-t log-p diagrams because the temp scale is rotated 45º to the left and the pressure is on a log scale.   We will have notes on these diagrams later on.

The main observation here is the air temp is going up, not down, as it rises above the surface.  We can see this better in another source of these diagrams using plain GFS (not the WRF), shown below

This is from a powerful sounding generator link at rucsoundings.noaa.gov/gwt.  Here we see the km scale on the right.  This one can also be zoomed, along with other neat user operations.

Here we see the air rising in temperature up to about 3,700 ft.  Normally the air would rise from the surface roughly like the top part of the red line, where the temp drops with increasing altitude.  More on these diagrams later on. They are crucial to the prediction of squalls and storms.

### Fog and Smoke Epilogue... the next day

The tone of yesterday's note may be a bit too glib (ie "not to worry").  Now Tuesday and we did see light fog on the Sound, but not near yesterday's coverage, even though the WRF meteogram from yesterday would seem to imply even more today.The forecast this morning, however, did include "patchy fog," so the computer models may have looked out the window yesterday.

Synopsis: PZZ100-081900- 254 AM PDT Tue Aug 8 2017 .Synopsis for the northern and central Washington coastal and inland waters...High pres offshore with lower pres inland will maintain onshore flow of varying strength through Thursday. A layer of smoke from wildfires in British Columbia will continue to drift across the area today which may impact visibilities this morning before improving during the day today. \$\$
Today
Light wind becoming N to 10 kt in the afternoon. Wind waves 1 ft or less. Smoke and patchy fog in the morning then patchy smoke in the afternoon.
Tonight
N wind to 10 kt in the evening becoming light. Wind waves 1 ft or less. Patchy smoke in the evening then smoke after midnight.

The air temp at WestPoint Lighthouse did not get close to the dew point as early, but still within 1º and maybe getting closer even at 7 am. Generally we would think that reduced visibility is one of the easier things to forecast since it is determined by broad air mass properties (temp and dew point)... in contrast to wind, which in Puget Sound is extremely sensitive to just a slight rotation of the isobars.  But it seems that adding a lot of smoke to the equation complicates the results, which makes it more difficult to predict temperatures as precisely as we need for this. Recall we were warned of record breaking temp records, that did not quite materialize, in large part because of the smoke.

But despite the wording of the visibility notices in the forecasts, the UW WRF model did do a good job on forecasting (T-TD) temperature difference, ie suppression of the wet bulb temp—a term that originates from the way dew point is measured using two thermometers, with one covered by a wet wick so it gets cooled by evaporation by an amount that depends on the relative humidity of the air.

UW forecast from 5pm last night shows lowest suppression coming at 8 am today, which is about what we saw. The one anomalous low point right at 8 am is likely a coincidence.

These are the actual measurements from West Point Lighthouse (WPOW1). Vertical scale is T - Td (ºF) (suppression of the wet bulb) and the data points are an hour apart with the scale indicated in red. There is a link at WPOPW1 for past hourly data, which can be copied and pasted into a spreadsheet to compute and plot the results.

So it seems the message of this amateur analysis is that looking at T dropping to TD is a dependable way to predict the onset of fog, but figuring the thickness of the fog does not come out of that simple analysis; that will take further analysis.

...standing by for meteorologists to tell us how we do that.

See related note on UW Sounding Generator, which shows the temperature inversion we are having.

## Monday, August 7, 2017

### Local Weather Office Forecasts Smoke, but not Fog!

Smoke is clearly on our minds these days here in Puget Sound, and for good reason. But it seems to have distracted our local weather forecasters.  They are  forecasting "patchy smoke" that does indeed put a haze over the local waters, but they are omitting completely the pea soup fog we are having in the early mornings over Puget Sound.  What is limiting the visibility here is fog, not smoke.  The smoke is just damaging our lungs.

Synopsis: PZZ100-080100- 852 AM PDT Mon Aug 7 2017 .Synopsis for the northern and central Washington coastal and inland waters...High pres offshore with lower pres inland will result in onshore flow of varying strength through midweek. \$\$
Today
N wind 10 kt or less. Wind waves 1 ft or less. Patchy smoke.
Tonight And Tue
N wind 10 kt or less. Wind waves 1 ft or less. Patchy smoke.
Tue Night Through Thu
N wind 10 kt or less. Wind waves 1 ft or less.
Fri
SW wind 10 kt or less. Wind waves 1 ft or less.

But not to worry.... We can forecast the fog ourselves very easily, especially with the aid of the UW Atmospheric Sciences Meteogram on the Fly. Here was the meteogram yesterday (1.3 km, WRF model).

When the air temp drops to the dew point, or within a couple degrees in a forecast like this, we can expect fog.  Should be even more fog tomorrow.

Here is a 3-min video on the use of the UW meteograms.

## Sunday, August 6, 2017

### Forecasting Local Winds with Meteograms

This is just a printed note of a method described in more detail in the video link at the end. It is one way to study local wind forecasts, and especially the use of the US WRF model, whose high-quality data are otherwise only available to us as rather large scale graphic images, with wind speeds presented on a color scale.

In short, this note is a quick way to decide if you want to sit through a 11-minute video!

We use the UW WRF model, one of the best for this region of Puget Sound (though typically older forecasts than we want on race day), but nevertheless very good for planning the day before.

The meteograms are at this link: http://www.atmos.washington.edu/wrfrt/on_the_fly_meteograms/

The page looks like this:

Choose latest run, 1.3 km resolution, click the point of interest to load the lat-lon, then reset the elevation to 0. The 3 marks here are about the places we tested here.

It takes a minute or so to get each picture back, but there is a warning about this in red.

The data look like this:

The video discusses these in more detail. For now we care only about the second panel of wind speed and direction.

The three regions in study were then cut from this type of picture and pasted into one graphic.

The 0 h here is the run time at UW, that was 12 aug 8, or 5 am PDT. Then the time scale goes from there.

The video first points out that this is not best example, as there is not much wind in this case, not to mention we have a layer of smoke over the Sound at the moment, which is bound to affect any forecast.  Nevertheless,  we proceed while the method is fresh in the mind.  It is also explained that the apparent chaotic wind directions are just an artifact of how they are plotted. We still see clearly veering and backing, and pretty well by how much. the scale is not optimum for this.

If interested, the details are below:

The next step will be to get hi-res CONUS NDFD data and load it into a program like Expedition which offers the option to build a meteogram at any point from the stored data. Quick checks shows it all works as intended, but the ultimate role of the meteograms is not clear.

For example, below is a 4-min video looking at these same WRF winds discussed above but in the conventional way using the graphic images.  We see a lot from the graphic presentation, so it could be the meteograms might best serve as simply a way to more precise or digital values.  We have a convenient link to this graphic WRF data from UW at www.starpath.com/local  in the model forecast section.  (To clarify a question that comes up in the video, it appears the 1.3km WRF model is run every 12h and generates 1h forecasts out to 72h.)

## Saturday, August 5, 2017

### How to Add a Draw Style to LuckGrib

LuckGrib is a Mac app for downloading and viewing grib files. It offers the most functionality of any similar product, as well as offering the largest selection of grib data for download.  All the files it can download can then be exported to use in navigation programs for optimum routing, provided they are compatible with latest grib formats. LuckGrib will download and display all of the various grib2 format options, but many nav programs do not yet display these formats or map projections. Grib1 data, on the other hand, are more or less universal amongst viewers and nav programs.

Among the many unique features of LuckGrib,  this note is about its ability to add custom instances of what it calls "draw styles" and "style sets," and why we might need this.  A draw style is the prescription of how you want the data to appear on the compute screen. Showing wind, for example, as barbs, feathers, contour lines, color or gradient background scaled to speed, or streamlines is one example of a set of draw style options for wind. Then each of these can in turn be set to specific colors, line widths, spacing, and even the gradients can be digitally defined over speed ranges.  (In another part of the program you can specify how dense you want interpolation between actual data points, or no interpolation at all.)

More specifically, a LuckGrib draw style applies to a specific parameter and level, or set of levels. In a display of surface wind and pressure for example, you can define a draw style for wind that includes, say, barbs (an arrows option) and background colors (an images option), and another draw style for pressure (say contours only).  This combination of two draw styles can then be named and saved as a draw style set, which you can recall or apply to other grib files.  When combining wind, current, and waves, for example, we can use this freedom in display to emphasize one parameter with one style set, and another using a different style set.

But that unmatched versatility is not the subject at hand.

LuckGrib not only can access almost any valid grib file, it will also import it and make the data available to the user.  In the GFS model, for example, we typically get wind and pressure, precip, and maybe gusts, and maybe winds and altitudes at the 500 mb level, but in fact there are some 300 GFS parameters available, and LuckGrib lets you ask for any of them. This makes the app a tremendous tool for inland weather analysis.

If we were to ask, for example, for the soil temperature 1 meter below the ground, we would indeed get that data for any location in the US, and if we loaded that grib file and put the cursor over a chosen location, we would read that temperature from the panel in the top right of the screen. But there would be no graphic display of this data because it was not anticipated in the marine oriented product. There is no predefined draw style for this. Without a draw style, say color vs temp with contours of equal temp, we cannot tell at a glance where the best place to plant our corn in Kansas might be... for example.

We come back to more realistic examples shortly, but here is the soil temp + wind + press selected over WA state. The cursor does not capture, but the top right shows read out at cursor location.

There is no draw style for this parameter, so we must add one.
(1) click the arrow on the (highlighted) active grib file, and we see which draw styles are missing

(2) We see TSOIL is the only missing one.  Note that the parameter name is TSOIL and the level of the data is @ 1-2DBLL (1 to 2m depth below land level). Click the arrow next to draw styles, then in the next popup, uncheck the box that says Show only draw files referenced by file.... which really means show only draw files referenced by file that have been so far activated. TSOIL will not show up at this point, we have to add it.

(3) For other parameters, you can scan the long list that then shows up to see if your parameter is there, but just not with the level you care about. But in this case there is no TSOIL, so we have to use + button and add it.

(4) When you press + you get the choices: Contour, Scalar image, Arrow,  or Streamline. For this parameter we would want to add contour and then scalar image, which is the one needed for a color gradient background.

Once you type in the official parameter abbreviation that we read from an earlier screen, it will know what this is and print the name as soon as you click the level field.  In this case, we can just use the default for all levels, since this is the typical draw style we would use for temperature.

You can sniff around the main grib file display with the cursor to see the range of temperatures you might like and enter them here, but this can always be changed easily once this style is saved.

Then do the same for an image style, and just drag one of the gradient patterns onto the template.  (I will need to add a video on this, which shows the process).

Then you are done and you can go back to the grib display and show these new styles for a clear picture of where to plant the corn.

We see several hot spots, the red peaks are 66º F and higher. The yellow is about 48 and the turquoise is just under 40.  Not sure what this means.... it is a random exercise (this is not even Kansas), but ends up sort of interesting. Portland and Tacoma are the two red areas on the left, but not sure at all what the other hot areas mean.  This is left as an exercise.  There is nothing in those red areas with any similarity to Tacoma and Portland that I can think of—other than, (it appears) having high soil temperatures 1 to 2 meters below the ground. Also, why Tacoma and not Seattle? ... all beyond our present scope.

I will add a video to outline the process, and discuss the real example that forces mariners into this operation.  It has to do with pressure contours referenced to ground level (not what we want) rather than to mean sea level, which is the convention used in some Norwegian grib files.

On the other hand, LuckGrib is a fantastic tool for making your own inland weather station to predict thunderstorms, rain, cloud cover, and air temperature.  This use of the program on land will call for several of these custom draw styles.  Keep in mind, too, as you play with this exercise, you can't hurt anything. There are numerous buttons that take all draw styles, or selected ones, back to default.

Video on just adding a level to an existing parameter ... the motivating operation for this exercise.

Here is a video showing the steps of the above article, which is the full process of adding a parameter and draw styles.

## Friday, August 4, 2017

### How to Combine Grib Files

It is not too often we have to do this. Some grib viewers and nav programs that show grib files will either let you select more than one at a time to show (ie OpenCPN and Expedition allows for this), or they might offer custom packages of say wind and current.

In Expedition, for example, you just load grib files from any source into their grib folder and put checkmarks next to the ones you want to combine.  In OpenCPN use the file open option then select multiple files with the cmd or ctrl key, and that will combine them as it loads them.... in most cases; there are exceptions.

The free navigation and routing program qtVlm (Mac or PC) has a neat grib combiner utility that combines grib files with option to rename and store the combination where you choose. It is a versatile program in its own right, but this utility within it lets you create files for use in any program.

Nobeltec and Maxsea TimeZero apps provide custom packages of grib files (wind, current, seas) intended for optimum routing, but if you want to optimize the data using other than their choice of data we have to combine the ones we want on our own, as outlined below. For typical routing calculations we need wind, current, and wave data that come from different sources.

Zygrib (and XyGrib) allows for simultaneous download of ww3 wave data along with GFS wind data.  For inland and coastal waters, however, GFS wind data will rarely be the best choice. Zygrib does not allow for multiple file selection in their load from file option, so this is one that needs external combination as well. Likewise to include current with any file requires manual addition.

Saildocs offers a compromise or sorts, by adding a "waves" parameter to their GFS downloads. But waves are not part of the GFS model; they have taken one component of the ww3 model and just added it onto the GFS grib files themselves, so users can get both at once and not have to combine them manually. Again, though, this might not be the waves and wind combination we want. Furthermore, the "waves" addition alone does not bring wave direction, just height.  You can however append to a saildocs request the specific ww3 parameters you want it to add.

One of our favorite grib viewers, LuckGrib, does not allow for opening multiple files, so to see combined data in that program, we have to add them externally.

(Beyond these more common calls for the need to externally combine grib files, we come to the high resolution NDFD wind data.  At least for the time being, I am only aware of two ways to access this data.  Either use LuckGrib (on a Mac or iPad) to download the wind and then export that (single) grib file to use in other programs, or get them directly from NOAA as ds.wdir.bin (wind direction) and ds.wspd.bin (wind speed) and then combine them as shown below—the .bin extension is a valid grb2 file for those nav programs that read grb2 data.  On the other hand, and the reason for the ( ) on this note is, this is a bit academic, in that, to my knowledge, Expedition and LuckGrib are the only two programs that can display these state of the art data files. And in Expedition, you can indeed just load the speed and direction files individually into their grib folder and it will combine them and show the data.)

And there are other subtitles we face when striving for the best data for specific locations. Meteo France, for example, offers a high quality waves and wind file (similar to the US WW3), but the wind part is coded like the NDFD wind data, meaning it is expressed as two values, wind speed and wind direction. OpenCPN and several other grib viewers will not read that type of wind data. They expect the more standard format of the two components being the E-W wind speed and the N-S wind speed and then they combine these for the vector winds they display. If you load one of these French .grib2 wind and waves files into OpenCPN you see only the waves.

In short, for optimum work we will likely have occasion to combine grib files manually, but with that said, it turns out to be an easy process, in either a Mac or a PC. The process is done in a command line statement, which may not be a familiar operation to many, so it is described here as if it had never been done before.

We use these files currents.grb, waves.grb, wind_pressure.grb from Norway Met Inst as an example. They have been renamed here. These files also illustrate other subtleties of grib file display, once we wander away from our comfortable US sources. We put these in the folder /Downloads/Norway.

Mac process
(1) in spotlight search, type Terminal, then click open the terminal app. It will look something like below, showing your computer name and home directory.

Then type: cd Downloads/Norway, and enter.... to get to the place where the files are located.

Then type: cat wind_pressure.grb waves.grb currents.grb >skaggerak080417.grb.  We make up the final file name ourselves. This one has the place and date. Can't put the time on this one, as these files do not cover the same time period, which is an issue we will have to deal with.

It won't say anything unless an error was made, but this new file should show up in Downloads\Norway and it should be about the size of the other three combined.

Now in principle we are ready to test our new combined file, which now includes wind, pressure, current, and waves. Current data typically has set, drift, and sea water temp; waves can have numerous parameters, which is more a topic for another post.

Above is combined file in OpenCPN. It will take some trials to figure best display choices with multiple parameters. This one is not optimized. For routing it does not matter what the picture looks like. Note that pressure does not show up, and this can be understood. I will cover that in the video or different article. Likewise, a video is easier to illustrate the timing issues, as these forecasts are not all for consistent times. A routing program, however, can interpolate these between forecasts as needed.

Below is the same file viewed in LuckGrib, using only arrows for display. Luckgrib has many display options for every parameter—best of any program—so we can do much better as needed.

Below we shut off all parameters but current for a better picture of what is taking place in this bay.

Note that as powerful as LuckGrib is, it will not display more than one grib file at a time, so this process is needed when we want to see, say, wind and current overlaid. OpenCPN, will indeed let us combine the three files we just did manually, so in this example our special process was not needed. We would get the same display by just selecting multiple files at the Open File dialog.

Now we proceed to the process of combining grib files in a PC.

PC process

This time we put the Norway folder on the PC desktop. It does not matter where these are, but my PC is a virtual machine in a Mac, and I share the Mac Downloads folder which confuses this example, so we use this new location. In general, it is best to put the folder you are working on close to the root, so it is easier to get into it.

(1) In the main windows search box, bottom left, type CMD, enter.  This will find an app called Command Prompt.  Click that to open. It will look like below.

This is the PC counterpart to the Mac Terminal, and we start in the user's home directory.

(2) Type CD Desktop\Norway and enter. (Note the slashes in Mac and PC are opposite.)

(3) Then type: type currents.grb wind_pressure.grb waves.grb > skaggerat080417.grb and press enter, and you will get this, which means it worked.

Then if you check the Norway folder you will see your new file is there.

For both the PC and the Mac there are various short cuts and other commands that help with this if you care to learn more about this.  For example, in Mac or PC instead of listing the files to add, you can name them in the base folder with some initial ID, ie add z1 in front of every file name. Then the command cat z1* >z1.grb  or type z1* >z1.grb will do the job. Thus you can organize the files ahead of time with chosen prefixes.

The mentioned issue with the pressure from these Norwegian data is the reference level. Most grib files meant for maritime application use pressure at MSL (pressure@0-MSL or PRMSL@0-MSL), which is what we see on weather maps. The Norwegian files use a pressure above ground level (Press@0-HTGW). LuckGrib and Expedition take this in stride and show it, though we must be careful to remember that the isobars on land are relative the ground, not MSL. On the water it does not really matter, but you will see kinks in these as the isobars climb up the hills on land and not agree with the weather maps on land.

OpenCPN just ignores these pressure data and opens the files normally otherwise. Just with no pressure to see. The same with qtVlm. Zygrib will not open the files at all if they cannot identify all the the parameters, so you cannot use the program with that type of data.  When studying the effects of terrain on wind, the ground referenced isobars can be interesting to look at. The UW WRF model uses this, so we see the actual station pressure a person living on a hill would see.  Still a bit confusing for maritime work with a weather map in hand.

Here is a short video on how to adjust LuckGrib to create a draw style of this new pressure relative to ground level, which is not what we normally want in marine applications.

When this won't work

There are some limitations to the process. The normal goal is to add parameters from different models to a given region and time frame. If we wanted to combine several adjacent regions covering the time same time and same parameters we would find that this will not work in most viewers. Most viewer software would be conflicted on various stages of the display if it had, for example, wind speed at the same time in two different locations in the same data file.

The only exception I know of is Expedition, that will allow for opening multiple adjacent regions covering the same time and parameters. Also it does not need external combining, it will do this itself.

In contrast, the program qtVlm, which does offer a way to combine GRIB files, will not allow for same parameters and time over adjacent regions.