Friday, June 18, 2021

Sharing Routes Between OpenCPN and qtVlm

OpenCPN and qtVlm are the two most popular navigation programs in the world, with thousands of international users. They are free programs, both with options to make donations to help cover expenses and support the developers. They each have both PC and Mac versions, along with other options, including mobile versions.

Each has its own unique and powerful features, many of which we do not find elsewhere, or maybe only on expensive commercial products. Because they are both sound, working tools with unique strengths, we use both in our online navigation and weather training courses at Starpath. 

Common to both, of course, is the option for user-created routes made up of a sequence of waypoints. Essentially any navigation program, not just these two, include this operation in some form, which is indeed a requirement of the International Maritime Organization (IMO) for an approved navigation program. And essentially all navigation programs offer a way to export the final route in the form of a GPX file, which can in turn be imported into other navigation programs.

But OpenCPN and qtVlm have jointly gone a step beyond this in that each includes the functionality to just copy a route from the chart screen and paste it onto the chart screen of the other program. The reason this is so valuable is tied to the way each program creates the routes. Each has specific strengths you may want to take advantage of for the route creation, even though you choose to navigate that route in the other program. 

qtVlm, for example, is oriented toward sailboat navigation under sail. It offers several fast, easy ways to create a sailing route based on the vessel's polar diagram and a loaded grib file of forecasted wind—tools that do not require running a full isochronal routing computation. But those tools are not a bonus when you know you must be under power for most of the voyage.

OpenCPN, on the other hand, offers more convenient waypoint placements and adjustments, with quick chart display changes, so it offers a faster way to make a fine tuned route through a complex waterway that will be traversed under power.

Thus we may want to use one or the other programs for setting up our route, depending on the conditions, and then having the route in hand, we want to paste it into the other program.  In very broad terms, OpenCPN is likely best choice for complex routing under power and qtVlm is the best choice for figuring a route that must be followed mostly under sail.

In the common case of wanting to sail as much as possible, but knowing we have to go under power along parts of a complex route, maybe many days long, then we might want to create and fine tune the route in OpenCPN then paste it into qtVlm to see how much of it we might actually sail when we learn the actual wind forecasts when we are there.

Also, there are different protocols for following an activated route in the two programs, as well different simulation options, and different interactions with AIS targets. So even if we are set on actually using one over the other once underway, it could be we learn a lot about navigation of the route by simulating the following of the route in each of the programs.

Another example of cross program navigation, without even considering the distinctions between power and sail,  could be the choice to use OpenCPN for routine chart navigation to take advantage of its convenient interface of controls and chart display, while running qtVlm simultaneously to monitor and evaluate the weather along the route since it has so many powerful and unique weather related features. This type of operation greatly benefits from the ability to copy and paste a route from one to the other program.

So we are lucky that these two programs have collaborated to let us just right click a route, copy it, and then paste it into the other program, as if we had made it there.

And, while here, may I take the opportunity to thank the developers of both programs for the fine products they have made available to the public. This is a huge benefit to mariners worldwide. 

Later, individual mariners may choose one of the long-tested commercial products such as Expedition, Coastal Explorer, LuckGrib, and TimeZero. These products have earned their top of the line ranking. We use all of these ourselves in various applications, as do top navigators worldwide. But we cannot overlook the valuable role of the two free programs we discuss here for the introduction and training they provide mariners on the power of echart navigation.

Below is a video demonstration of the process.

[ video to be added shortly ]


Thursday, June 3, 2021

HRRR 48-hr forecasts and sub-hourly forecasts

For some time now, the HRRR model forecast has had options to its base offering  of updates every hour, with forecasts extending out to 18hr. One extension is a longer term forecast updated every 6 hrs, extending out to 48hr, but not many popular sources had the extended data available.  Now we have several sources, so this detail might benefit from a highlight, not to mention that in some cases the presentation might be confusing.

LuckGrib

LuckGrib for (Mac or iOS) pioneered the access to this data, and still has the clearest interface to the options, plus LuckGrib also offers access to the unique HRRR sub-hourly wind forecasts (every 15 minutes for 18 hr), which are not available elsewhere to my knowledge—other than a direct download from NOAA, which takes special procedures. The LuckGrib solution is to offer three separate model choices:

(1) HRRR hourly forecasts, out to 18h, updated hourly, delayed 1h 30m.

(2) HRRR 15 min forecasts, out to 18h, updated hourly, delayed 1h 28m (wind and gust only)

(3) HRRR hourly forecasts, out to 48h, updated every 6 hr at the synoptic times, delayed 2h 01m.

These are the most timely forecasts we have, but there is still a latency to account for the model run time plus the 10 or 15 min it takes LuckGrib or other third parties to process the data once ready.  

This means that if you request (1) at 1500, the first forecast you get would be valid at 13z and the last would be 18h later at 07z the next day. Noting the delays to the minute allows you to get new data about half an hour earlier, but you would still be comparing present observations to a forecast that is 1.5 hr old.

The same is true with the sub-hour forecasts (2), but at the earliest you will always get at least 6 forecasts that cover past times. Your logbook records of these winds and then a good check on the actual forecasts going forward in time.

For inland routing or planning a day sail or a race, option (3) is enticing, but the timing might be more crucial if you want the freshest forecast.  Requesting (3) at 1410, would bring 48 hourly forecasts starting at 12z today and ending at 12z in two days. You would have only lost 2 hr of currency, which is unavoidable.  On the other hand, if you requested (3) at 1330 or even 1400 exactly, the first synoptic time earlier than the 2h 01m latency would be 0600, so you would be working with a forecast that is 8 hr old. 

In short, when using the extended forecast HRRR data we must be aware of the latency. Note that the fact that this runs at only the synoptic times means it will make an interesting (timely) comparison with the  3-km NAM forecasts as well as the NBM CONUS data.

Saildocs

Saildocs does this a different way. They have only one HRRR model request, but it can be used for the 18h data or the 48h data.  The result you get back depends on the extent of the forecasts you ask for.  If you ask for less than 18h of data,  ie every hour (or every 3h) out to 18h then this is interpreted as the 18h run computed every hour with a latency of 1.5h.  If you ask for any forecast beyond 18h, then that will trigger the 48-hr forecast  run only at the synoptic times, now with a latency of 2.0 hr. 

In short, it is about the same as LuckGrib on the extended forecast, but Saildocs does not have the sub-hourly forecasts.

Expedition

Expedition uses Saildocs for access to the HRRR, and to accommodate the 48h option, it shows extended hours for choosing the number of forecasts, and hence the trigger to the type of data. It works as explained above, but users need to know the conventions and latencies.

Other Viewers and Apps

XyGrib does not access HRRR. OpenCPN, qtVlm, and others that use Saildocs show the HRRR interface but are not updated yet, and still assume the maximum hours for HRRR is 18. These programs often generate an email for the user, that we then send to query@saildocs.com to get the file, which we then import as an external grib file.  To use this same email for the 48h forecast, just change the end forecast date from 18 to 48 or 30, etc.  Keep in mind this is high res data, so the files can get huge fast. We have to make judicious choices of region and parameters or hit server limits on file size.

Some mobile apps allow the choice of HRRR, but default to the 48hr data for all selections, so users must be aware that there is maybe newer data from that model.

***

Numerical weather models including regional models for inland sailing are discussed in our textbook Modern Marine Weather.