Wednesday, March 17, 2021

Timing and Time Structure in Model Forecast Gribs

Analysis and forecast timing is crucial for good weather work. This is not just a challenge with model forecasts in grib format (the subject at hand), we also face this when using regular graphic weather maps and text forecasts. We cover this in Modern Marine Weather, under the heading "weather map sequencing" near Table 7.2-1. 

The timing involved for the GFS and other global models is very roughly outlined below. (Regional and rapid refresh models have a totally different timing pattern.)

(1) At precisely the synoptic times (HH = 00z, 06z, 12z, and 18z), observers and instruments around the world collect observations and report them via a global network to all the labs around the world running numerical weather prediction models. (A time label "z" means zulu time, which is a nickname for UTC, which was once called GMT.)

(2) The models collect the data and analyze it for quality and then assimilate it into their model programs and start a new global computation. We are now at HH + 2 hr or so

(3) The model completes the global surface analysis and passes it on to other labs. This is now roughly HH + 2.5 hr. Now, or a bit earlier, the model starts computing the various forecasts based on this analysis.

(4) The OPC receives this latest model analysis, which they combine with their own analysis and create the official OPC surface analysis graphic maps and text reports. This is now roughly HH +3.5 hr

(5) The model completes its full extent of forecasts and posts these online for third party access. This is now about HH + 5 hr 10 min. 

(6) Third party providers (Saildocs, Expedition, LuckGrib, XyGrib, etc) complete their download of the analysis and forecasts to their own servers and process it as needed so they can distribute this to their users. This takes us to about HH + 5 to 6 hr depending on several factors, discussed below.

Data are available to us following steps (4) and (6), with actual times depending on the format, product, and source we use, and we have to, of course, keep in mind both local times and dates, as well as the UTC times and dates of the products.  

In the following we first look at the time structure of what we get, and then address the question of when we can actually get it.


What Forecasts Are Available?

When we ask for a set of model forecasts, it is generally assumed that you want the most recent data. Some data sources let us choose between forecasts based on the latest, or forecasts based on a specific synoptic time over the past 24 hr, which may not be the latest. This latter option would only be used in special circumstances, such as comparing with past ASCAT wind data, or for filling in something we missed in the past 24 hr. Those offering this past data generally only go back 24 hr. (If we want even older grib data we have to look into archived or reanalyzed data, which is a topic of its own.)

When we ask for model forecasts such as GFS, we specify the Lat-Lon region, the extent of the forecasts, i.e., out 1 day, 2 day... on up to 16 day for GFS, and we specify the forecast interval, every hour, 3 hr, 6 hr, 12 hr etc. If we are asking for data from Saildocs by email, we must know ahead of time the extent and interval sizes that are available. When using data sources from within a grib viewer, they usually have the intervals and extents listed and we choose from what is available.

What is often not so clear, even when using a grib viewer with selection options is the available intervals typically change with the extent of the forecast, and the options we have depend on the source we are using. If we use the GFS model as an example,  NOAA creates these forecasts every hr for 120 hr (5 days), and then every 3 hr out to 16 days (384 hr), but outside of direct request from NOAA, there is no third-party source for data  over this full frequency range. Each third party provider makes a choice of what they believe best meets their user's needs. Samples are shown in Figure 1.

Figure 1. Sample availability of GFS forecasts.

LuckGrib and Expedition (via its direct NOAA link) are the only sources outside of NOAA direct that offer the 1hr data. XyGrib and those who use it only go out 10 days, but they offer 3 hr steps over that full range. Ten days is certainly more than adequate, except maybe for an initial long look ahead for planning. Generally GFS forecasts are good out 4 days, but then fall off. For longer term forecasts, the Oceanic National Blend of Models is likely best.

When planning a departure time, data every 12 hr could be adequate; when doing an optimum routing, you might want data as frequently as available within your airtime budget—but there are other factors to keep in perspective when making that choice.

The question of when we can actually download or request these various forecasts is another topic, covered below.


Time Format in Grib Forecasts

When we ask our grib viewer or other source for the latest forecast extending out, say, 48 hr with forecasts, say, every 6 hr, for wind, pressure, and rain, we can expect that each of the forecasts we get back will include the same parameters, except for the rain. A generic "rain" request is likely to be given in terms of accumulation, and there will not be any rain data in the first forecast, as none has accumulated at that point. (GRIB is a WMO weather based computer format, and rain is a deceptively complex parameter in that system. See notes in Modern Marine Weather.)

This 48 hr forecast in 6 hr steps will show up as one file containing 9 weather maps. The first is a GFS surface analysis, valid at the synoptic time of the model run, followed (in this example) by 8 GFS forecasts, one for every 6 hr past the synoptic time of the run, out to 48 hr. If the synoptic time of the run was 12z on Mar 13th, the last of the maps would be for 12z on Mar 15th.

These files might be identified in your grib viewer or nav program two ways. All programs will list them by their valid times, such as 18z Mar 14 or 00z Mar 15, but you may also see them identified by the extent of the forecast. In that presentation, the surface analysis is called h0, the 6-hr forecast is called h6, the 12-hr forecast h12, and so on. 

Figure 2. Time structure in a set of grib model forecasts.

In this example, based on a 12z run on Mar 13th, the 18z forecast on Mar 14 would be h30; 00z Mar 15 would be h36. In practice we really need to know both identities, when it is valid and how old is the forecast. Some programs (i.e., Expedition) use h6, h12, etc; others (i.e., LuckGrib) use 6h, 12h, etc for this notation.

Each grib or nav app will have its own unique way to step through these forecasts. There will be a way to go from one forecast to the next, or go to any specific specific forecast. Also, since these are digital data, the programs can interpolate the times. You may only have forecasts for 12z and 18z but you can ask for an interpolated map at say 14z, or even 1437z, which you might want, for example, to compare with the wind measurements from an ASCAT satellite that went by at that time. Or you could want to compare with data in your logbook, or data from a buoy given at some specific time. The programs do not specifically warn you that these intermediate times are interpolated, but they are, just as the wind data itself is interpolated at points between the actual grid points for the forecast resolution.


When Can We Get the Latest Model Forecasts?

This timing is important for a couple reasons. First we want to be sure we are comparing the right forecast with the right observations, and second, we do not want to download a new file and spend the satphone airtime just to get back the same forecasts we got a couple hours ago. Also when racing, you might want to make a decision as soon as possible, which means getting the newest forecast as soon as possible.

The fundamental fact we must live with is, the earliest possible weather analysis we can get is going to be some hours old, so to compare our observations with that analysis means we have to rely on our logbook records that go back to that time... or use saved tables or histograms of our instrument readings. The analysis will always apply to a synoptic time, so it is fundamental to record, one way or another, all weather data at each of the synoptic times. Wind speed, wind direction, and the barometer (and the trends of each) are the main data, but estimated sea state, measured ocean current, state of the rain, and sea surface temp are other parameters that can matter, as well as cloud cover. Air temp might be useful in the midlatitudes to investigate frontal passage.

To compare what we are seeing on the water at the moment, we have to look at an interpolated forecast that applies to the present time, as noted above.

If we assume we are not relying on HF rfax weather map transmissions, which are only available at specific times of day (a huge drawback!), then we are considering now the earliest times we can request the data (with the understanding that we could get it any time after that).

When OPC issues their analysis (Step 4 above), we know that they have the model data in hand and have had time to put all the data together. We can learn exact values of how long it takes them to issue the latest graphic analysis maps from the annotated rfax schedule at OPC, a sample of which is below.

Figure 3. Sample of an rfax schedule showing broadcast (left) and available times (right).

Part 2 (West North Atlantic along the US coast) was broadcast at 2138z on rfax (left-most time), but it was actually available to download direct from NWS via FTPmail or Saildocs at 2112z (right-most time) a bit earlier. Thus this graphic map analysis is 2112 - 1800 = 3 hr 12 min delayed, leading to the typical 3.5 hr delay for these graphic products—it will take about 15 min to request it and get it back if all goes well.

These 18z analysis and forecasts from the GFS model in grib format, however, will not be available on the boat or at home for another couple hours. These 18z GFS forecasts from LuckGrib were available at 2320z and available from XyGrib a bit earlier at 2317z. These were about 5h and 20m delayed, which is typical for global forecasts. You can see the most recent delay times for any model via LuckGrib at luckgrib.com/status. XyGrib delay times for the models they provide are available from a menu link within the program. LuckGrib will warn you if you attempt to download data that are not yet updated, providing the second request is identical to the first one.

A working estimate for data delays of OPC graphic analysis is about 3 to 3.5 hr after the synoptic time, and we get the first grib versions of global models such as GFS in about 5 to 6 hr after the synoptic times.

There are, however, a couple nuances to this latter delay that you might run into if you dive further into the process. If we look into the actual computation times of the various models, which we can see at this NCEP link, we note two things. First the GFS analysis computations are typically done at about HH+3h 22m, but the full range of forecasts out 16 days (384 hr) finishes at about HH + 5h 10m. The  intermediate forecasts are completed at intermediate times.

Thus our grib providers could actually provide the GFS analysis (h0) at about HH + 3.5 hr, but the full range of associated forecast would not be ready for another 3 hr or so. If you ask for a 6-day forecast at, say, HH+4 you would get the latest analysis and maybe a couple of the latest forecasts, but the later forecasts you got would be from the previous model run from HH-6, because they had not been completed by HH+4. 

To avoid that potential confusion LuckGrib, and likely other data providers, do not take the data as it completes, but wait the full 5h 10m to start their downloads and processing. This way users get all the latest forecasts referenced to the same model run at the cost of not getting any at the very earliest time possible. In the case of LuckGrib, the global model delays are about 5 to 6 hr.

Another way to learn the actual times the files are available is to look directly at the NOMADS link where they come from. The times listed are the times these files were posted. These selected forecasts, for example, were based on the 12z synoptic run (.t12z) with 0.25º resolution (0p25):

gfs.t12z.pgrb2.0p25.f000                  16-Mar-2021 15:27  289M  
gfs.t12z.pgrb2.0p25.f120                  16-Mar-2021 16:03  331M  
gfs.t12z.pgrb2.0p25.f240                  16-Mar-2021 16:33  330M  
gfs.t12z.pgrb2.0p25.f384                  16-Mar-2021 17:09  325M  

The 12z analysis (f000) was posted at 1527z; the 5-day (f120) was posted at 1603z; the 10-day (f240) was posted at 1633z, and the longest forecast at 16 days (f384) was done and posted at 1709z. This represents the average of 5h 10m for the full set. We anticipate a new GFS v16 in the near future, which might expand this delay another 10 minutes or so.

Grib Data Distribution is Not Guaranteed

NOAA uses two broad categories to describe the development and distribution of data: Operational and Experimental. The model forecasts we are using are all Operational; indeed a primary source of the data is the NOMADS site, which stands for NOAA Operational Model Archive and Distribution System. So the data are certainly operational, but the distribution (dissemination) of the data is still not guaranteed, as we read in this note at the NOMADS site. We see similar disclaimers at almost all NWS sites. The only "official NWS dissemination systems" are NOAA Weather Radio and data obtained directly from the local forecast offices. In short, the main data we care about is not guaranteed to be available to us, and that does not even account for the third-party processing that we also rely on. 

This means we have to be aware that the model forecasts in grib format and other grib products from  around the world may in rare cases not be complete or may be missing. Speaking with experts who know the details, I learned that NOMADS has been remarkably dependable over the years. A recent, rare snag in the system was addressed promptly and users were kept appraised of the situation at all times.

To me, a way more disconcerting example is the recent, unannounced loss of the ASCAT data in grib format. This has still not been announced, nor a remedy proposed.

Another fringe example is the grib version of the NDFD, which are the official NWS forecasts converted to digital format. These latest data include inputs from numerous local offices and as a result the format and timing in some user selected regions (that might span two offices) are occasionally inconsistent. This is not a global product, so we will cover it when we discuss regional grib files.

The main message is, although the data always look very official and consistent, we might periodically see glitches in the products, such as missing parameters, or fewer forecasts than anticipated. This is all based on computer technology, which is very good, but none is 100% dependable... if we want 100% we should go to NOAA Weather Radio, but we better use a radio that is 100% guaranteed to work right.

Friday, February 26, 2021

Say Goodbye to the First Paper Chart

Two years ago (Nov 14, 2019) we were told that NOAA was planning to do away with all paper charts and all electronic charts based on them (RNC), to be completed by end of 2024—46 months from now.  This was the famous Sunsetting article, complete, indeed, with a picture of the sunset. All charts after that date will be ENC or custom paper charts based on the ENC format.

Today NOAA announced the first printed chart that has been converted to ENC only, Lake Tahoe, chart 18665. From now on, this is ENC only—or design a paper chart of all, or any part of it in ENC format, and print it in color or have it printed for you. This is the new NCC (NOAA Custom Chart) program, which you can experiment with right now for any NOAA chart to see how it works. Here is the online NOAA NCC tool for this, along with a video on the process. I hope to supplement what they have with some instructions of our own in the  near future.



Goodbye Chart 18665.

I believe the NCC printed products will eventually be even better than the present paper charts, but this will take a while. Mariners have to get used to using ENC, which our book on Electronic Chart Navigation will help, and also the NCC tool will improve. Right now the main and maybe only drawback to ENC is their coverage of land. We don't sail there, but we do in fact look at it, and rely on it for navigation. Some nations do a better job on ENC land coverage than the US does, but overall the US has exceptionally good ENC.



A detailed reference on the use of ENC

But this is all digital business these days, GIS (geographic information systems) in particular, and NOAA has access to every possible set of GIS data for land information. Every building, every road, every elevation contour, and eventually this info will be incorporated into the new NCC.

So as of today we have fair warning. The camel's nose is under the tent. It is time to start thinking about ENC... with that in mind, we have a new online course we are about to announce on Electronic Chart Navigation. Maybe about a month out.

______________

Friday, February 19, 2021

GRIB School

This document is an index to the several articles and videos Starpath has available on the subject of GRIB files and their use in marine weather analysis and routing.  You can skim through this to go directly to individual topics. Practice exercises are given at the end.


What is a GRIB File?

Use of numerical weather model forecasts by individual mariners is an ubiquitous component of modern marine weather. Using almost any navigation program these days connected to a wireless source on land or at sea, you can press a button to generate the latest wind, waves, and currents forecast across the chart with forecasts extending out a week or more.

The forecasts come to us in a digitized format called GRIB, standing for gridded binary. It is a vector product, meaning it is all numbers and symbols, but when rendered in an appropriate software program ("GRIB viewer app") it can appear as a graphic map of the isobars, wind vectors, rain distribution, and other parameters, laid out on a Lat-Lon grid. 

The GRIB standard was developed by the World Meteorological Organization (WMO) specifically as a way to transfer weather data in an efficient, standardized manner amongst meteorologists and mariners. The grid is a Lat-Lon lattice of points, with digital values (binary data) presented only at those specific points. The distance between points on the grid is the resolution of the file. This can vary from as large as 1º (60 nmi)  intervals to as small as 1.3 km (0.7 nmi), which is about the finest step size available outside of the laboratory.

A GRIB weather map at 0.5º resolution over a 10º x 10º area including surface wind and pressure every 6 hr for 3 days (a tremendous amount of information) will be about 30 kb in size. File size increases very roughly proportional to the number of parameters, but increases as the square of the resolution and area covered.

Several apps let the viewer request the latest grib forecast from a specific model from within the app, and these generally estimate the file size as you define what you wish to request.

Terminology: We often hear or say something like, "Have you downloaded the Grib?," or "What does the Grib tell us," and so on. Usually this is not ambiguous, but we should keep in mind that "Grib" is not a thing; it is a format.  It is like saying "What does the PDF tell us? The term Grib alone does not tell us at all what we are looking at. This could be a wind forecast from the GFS model or a wave forecast from the WW3 model. Use of the word Grib in such discussions requires clear understanding of the context. Likewise, the reference to "a" Grib file, generally refers a single file, but one that includes multiple forecasts over several hours or several days.

The following links contain information related to use of GRIB files


Background on GRIB files: Numerical weather models and computed parameters


Includes topics below plus a comparison with other forms of marine weather data. 

Traditional Weather Products

Numerical Weather Prediction

Values of GRIB Formatted Forecasts

Grib2 Weather Parameters

Categories of Digital Forecasts in GRIB Format

Basic Properties of Selected Models

Sources of Model Data in GRIB Format


Timing and Time Structure in Model Forecast Gribs

Details of this basic aspect of working with gribs

What Forecasts are Available?

Time Format in Grib Forecasts 

When Can We Get the Latest Forecasts?

Grib Data Distribution is Not Guaranteed 

 

Applications of Weather Data in GRIB Format 

Each topic has a short discussion along with video illustrations.

1. Global model weather forecasts for ocean navigation

2. Global ocean model forecasts of wind waves and swells

3. Ocean model for currents and water temperature

4. Regional model forecasts for inland and coastal sailing

5. Overlay model forecast winds on weather map and cloud photo images

6. Probabilistic forecasts from ensemble forecasts and model blends

7. View sea ice coverage from RTOFS in LuckGrib

8. Compute optimal sailing route 

9. View ASCAT scatterometer near-live satellite wind measurements

 

Introduction to using GRIB files with XyGrib

A few basic tips with a video example.


Introduction to using GRIB files with qtVlm (videos only)

Loading Grib Files in qtVm

Displaying Grib Files in qtVlm


Optimum Weather Routing with qtVlm

A short discussion with video example


Optimum Weather Routing with OpenCPN

A short discussion with video example



Playlists of Related Videos on Use of GRIB Data


   OpenCPN

   qtVlm

   XyGrib

   Expedition

   LuckGrib  (Identifying frontal systems in GRIB files)

   Panoply


Homework (with answers)

Practice with Grib Files 01

Practice with Grib Files 02 







    










Tuesday, February 16, 2021

Optimum Weather Routing with qtVlm

This note on qtVlm routing is part of our sequence of articles on the Applications of Weather Data in Grib Format. We have similar demos of routing with other applications.

[ We also have now a new more basic discussion of this process 

qtVlm is a free, donation-supported navigation and weather software program for both Mac and PC computers, as well as mobile devices.  It is an internationally popular product with versions in multiple languages. It is the leading program worldwide for virtual tracking and taking part in ocean races presented online.  It is a versatile navigation program as well as weather resource. See also notes in the Starpath Glossary.

We cover charting aspects elsewhere; we have a video playlist on several topics, as well as a cheat sheet on specific functions; here we just take a brief look at the app for routing computations, which is of course tied to its display of grib formatted numerical weather and ocean predictions.  The program includes extensive functionality, which means there are numerous nested menus, some of which are interrelated. In short, there is a learning curve, as is with any such versatile program. So we start by just focusing on what we need to create a basic route, and then we will come back to the numerous ways it offers to fine tune and optimize the results further.

We will list the steps here and then add a video demo of the process.

Step 1. When you download and install the app, be sure to load the "maps," which in this case will be the high-res base maps. 

Step 2. The default display shows a daylight terminator which is very handy when underway or when planning a voyage, but for training and practice if you find it distracting it can be toggled off at menu View/Show-Hide/Night Zones.  

Step 3. Load a Grib forecast (review earlier notes on gribs) that will cover the range of the route you want to compute, and long enough to let the vessel finish with its known polar data.  In this example, we want to do summertime ocean routing using archived wind data from July, 201o that we have stored on the computer. Thus the steps are: menu Grib/Grib Slot 1/open and navigate to the file to load it into slot 1.

Doing these historic runs, you will get a warning that the grib data is old, and consequently it will not show on the screen. Click the clock icon in the middle of the menu bar and set the grib time to match the first forecast loaded. Using live data this will not likely arise, as the newest live data is some 4 or 5 hr old at best.

The second from the right magnifier icon (with a square inside) will center the view on the active grib data.

If you do not see the grib data, but you do see elevation and rivers on the land, then you have an overlay turned on that could be hiding the wind data. Click the menu chart icon "O" (online charts)  to toggle this on and off.

Step 4. Load the polar diagram you wish to use. It can accept files in the .pol format or the .csv format, with the separators being semicolons. See related polar format discussion.  To load the polar use menu Boat/Boat Settings.  Note we are not using menu Boat/Polars. That will be used to study the polar once it is loaded.  Once in Boat/Boat Settings, add a name and or model of your boat then open the Polars tab below it.  Navigate to your polar and import it. We can leave the other settings in default choices.

Step 5. Check the polar. Menu Boat/Polars/Wind polar analysis. Check all TWS (true wind speeds) to see if it looks as expected. Then go back to just one wind, and notice that you can click on the curve to read the data. We are not getting into this now, but if you want to change anything in the polar you can do it in Menu Boat/Polars/Wind polar editor

Step 6. Set start and end points. At the desired start point, right click within the grib area and make a mark. Give it a name and click OK. We can leave all defaults as is.  Do the same with the destination point.

Step 7.  Right click anywhere on the chart and chose Create a routing.

Give the route a name 
 
Turn off Routing from boat
 
Confirm that start and finish are the points you want—from drop downs; top is start, bottom finish.  If the points are not there, cancel, add the marks (POI), and come back. 

Turn on Keep Starting Date and type in the initial time of the grib forecast installed (default is month, day, year). Later we can use other start times. Select the month, type it in, and just keep typing. 

Leave on Isochrone color based on....  Turn on Automatic parameters, and move slider ball to far right (Best accuracy).

Leave on Convert to Route using...  at the bottom should be left on; letter "R" is fine for now. 

Then Press OK to create the routing 

(If anything is not right then when done,  just say OK, then Cancel, and from menu Routings select delete routing, and do it again.)

Step 8. Convert to Route. When done, it presents the ETA, duration, and computation time. Click OK. Then we get the opportunity to convert this routing to a route.  The former is the result of an optimization using isochrones (just completed); it is a sequence of isochrone points. Unless we need to study the displayed isochrone solution in more depth (discussed later),  then the logical next step is convert it to a route, which means converting the isochrone points along the fastest path to a series of POI.

To do this, we first we Simplify the route (series of POI), and we have two ways to do that (Maximum and Optimum).  This process removes excess POI along the route, such as intermediate ones along a straight line. Maximum simplification is the quickest solution, and removes the most waypoints, but it might not leave us with the fastest route to the finish. Optimum simplification takes a more careful look at each point. It takes a bit longer; removes less points; but never loses ETA, and usually improves it. The computation time difference is rarely large, so it is usually best to do an Optimum Simplification. 

Once the route has been simplified in the optimum way, we can still Optimize this route even more. This is an important final step to get the most efficient route using the criteria we selected.  This process goes back over each point with a more sophisticated look at the best way forward. It is an improvement over a pure isochrone solution.

Thus the sequence is: 

1. Create the Routing

2. Convert to a Route

3. Simplify optimum

4. Optimize

Once this is done, the routing will be moved from the routings list (menu Routings) to the routes list (menu Routes) and we can then look at details.

Step 9. In menu Routes/Edit Route  select your route. Logbook shows the conditions at steps along the route. You choose for these to be every so many minutes or after a specified course change. Use the gear icon to select what you want to see—click it, select ones to see, then click the gear again to set them. Histogram is an interesting way to look at plots of various parameters along the route. Statistics summarizes a few parameters of the whole route.   To export the route as a GPX file, use menu Routes/Export route.

Below is a video sample of an optimum route computation.


Routing example with no special conditions [17m:33s].


qtVlm has many options and restrictions that can be placed on the computation. Like most other apps, you can define boundaries to block the route from certain areas or passes, plus qtVlm can route around a course of marks, or through specific gateways, which adds a layer of versatility to the solution.  This is accomplished by optimizing along a pathway.  In qtVlm, a pathway is a series of waypoints, what might be called a route in other programs. Routings, routes, and pathways have distinctions in qtVlm. 

Other routing adjustments you can make include:

• With gust data in the grib, you can reduce the polar efficiency if the gusts are a certain percentage above the wind speed. 

• You can avoid areas with wind greater than some value

• With wave data in the grib (now part of the GFS forecasts) you have several options

    — Avoid areas with wave height greater than a specified value

   — Use a wave polar that reduces or enhances wind polar values depending on the true wind speed, height of waves, and angle of the waves relative boat heading

    — Engage a cross seas correction to the wind polar based upon height of the swell and the angle between the wind waves and the swell.

• You can limit the TWA to keep the routing from heading closer to the wind than you want or more downwind than you want, thus overriding the polar diagram.

• You can adjust the minimum time between successive tacks or jibes as well as specifying a time penalty for each.

• When cruising, you can set the minimum sailing speed before the engine comes on, and then what boat speed should be used when under power.

• You can also chose a reduced polar efficiency when sailing at night.

• Without changing the polar itself, you can temporarily enhance or diminish polar performance by a percentage factor for upwind or downwind sailing.

• If the present observed wind is not matching the forecast winds in the grib being used, you can scale the grib winds to match them.  This factor can be set to gradually fade into the pure grib wind over a fixed period as you anticipate the forecast improving.

_____________

References:  

Users Manual: http://download.meltemus.com/qtvlm/qtVlm_documentation_en.pdf

Forum details: https://wiki.v-l-m.org/index.php/QtVlm_Virtual_Race_Mode

Many videos in YouTube in French.