Confessions from the Canaries

None of us have 20:20 vision when it comes to reading gridded wind gribs. Some of us are better than others at trying to see through the myopic maze on SOL as we pull the time bar steadily from left to right, but honestly everybody does better when they get themselves a pair of glasses.
There are many different brands of glasses aka routers available. Some, like Expedition and MaxSea will set you back a fair few shillings; the Porsche’s and RayBan’s of the routing world. Others, like QtVlm, are approved by the NHS and MediCard and are entirely free. Surprisingly, all of them – irrespective of cost – used to have the focal qualities of the 10 bucks readers you might pick up in your local supermarket. They were a help, but the letters on your SOL page were never entirely sharp.
The cause of this paucity of focus (in particular in twisty, light wind) is the unusual, but elegant and logical, approach to interpolation that obtains in SOL. My understanding of what that difference is was seeded by a conversation I had with kroppyer at TU Eindhoven now more than three years ago. I have written about it from time to time.
Let me recap. SOL interpolates on a “vector” basis; Qt and (all?) other routers interpolate on a “scalar” basis. You see, the data in a grib at its grid points consists of two values and they are not TWS and TWD. They are U (the component of TWS in the N/S direction) and V (the component of TWS in the E/W) direction.
Most routers estimate TWS in the void between grid points by vector adding U and V to determine TWS at the grid points and then interpolating in between those TWS values. However, SOL interpolates U and V separately first and then vector adds those interpolated results at a given latitude & longitude in between the grid points to find TWS: hence “U/V” vector interpolation.
Think of interpolation as weighted averaging. Say, down a meridian, you have TWS 9.5kn at 41.5O latitude and TWS 10kn at 42O. In the middle in between, the weighted average will be the same as the simple average, i.e. 9.75kn. And so it is according to most routers. But according to SOL, using “U/V” interpolation, so only if TWD at both positions is the same, else the result will be less than 9.75kn!
Perhaps the diagram below explains.


It is one thing knowing something, but quite another matter doing something about it. End 2015, a solution still eluded me. Perhaps one or two fellow competitors had (done something about it), but the guys I chatted to regularly from the three corners of the Earth (psail, Dingo, javakeda) had not. There were ideas, but where to go from there.
But then, as 2015 drew to a close, I (virtually) met Kipper1258. Kipper is a mining engineer and I a lapsed engineer. I asked Kip did he know anybody who could write a bit of code. I am handy with Excel and can do a bit of VBA, but my programming skills in other languages died with my post grad project back in 1980. Kip thought he might have access to somebody who might lend a hand at work. Turned out, that somebody was himself!
I explained to Kipper what I thought was going on, and how we might get round it without trying to adapt the open source code of Qt, which seemed too daunting a project by far. We included psail in our team; psail had been the first to mention “de-gribbing” as an idea, and that was going to very much be part of the solution. Kipper felt “de-gribbing” was doable. Almost at the same time, I discovered that a superseded version of the simple ViewFax grib viewer in fact already had a “de-grib” button. Unfortunately, the text files that it produced appeared to be rounding the two components of wind , to one significant figure after the decimal point, expressed in m/sec. Surely, what was in the actual binary source file was more precise than that.
So, Andrew set to coding, and I set to testing in Excel how we thought SOL interpolated, using ViewFax extracted files. It soon became clear we were on the right track, and also that the “U” and “V” values in the grib binary files had loads of sig figs after the decimal point. It was time for Step 2, which we called “densification”, in other words, adding lots of additional data points in between the given data points, but interpolated “correctly” using the SOL approach, and then “re-gribbing” that data.
My testing with the ViewFax files of necessity was of course already producing “densified” files, and my initial thought was we could “densify” a subset of an extracted grib in Excel and then “re-grib” it. Kipper said: no, let’s code it; the “densified” Excel files will get much too big. And so he did, and soon enough we had a java script that was generating a “dense” grib, and psail and I set to further testing. After a while, Kipper went over to numbering his updates.
The iterations ended at GribReformat_1_20 and it worked and still works well. Genius, Kipper! We can specify the level of “densification” and reduce the racing area to be “densified” to whatever we think is of interest. This latter feature is important, because even the binary gribs can get very large when we “densify” them. Luckily (and that could have been an issue), Qt has no problem swallowing these files that can be up to 1 Gigabyte in size.
So, here is the belated confession. I was not in touch with God, or very brave, when, after a long and nervous dog fight with rumskib, on rounding Lobos in the 2016 Santa Monica Tour of The Canaries, I opted to sail off close-hauled to the North of the rhumb line for La Palma, abandoning my 0.2nm lead on him and 0.4nm lead on Lou. My router, fed with a grib densified to 0.05x 0.05 degree points at 1 hour intervals, told me too. It also told me, fed with the issued 0.5 x 0.5 x 3 hour grib, that everybody else would more than likely more or less track the rhumb line, but, re-fed with the 0.05 x 0.05 x 1 hour grib, that if they sailed this perfectly, they would lose about a half an hour on me. But, of course, there was no way that – sailing perfectly – was likely to happen, because their routers would not be giving them the right solutions. They’d have to SOP through the goo.
I further confess, that Kipper and psail and I would have enjoyed testing our proto-type a little longer, but serendipitously for the rest of the fleet, Bimmer raised some questions with the SOL team about what was going on in “blue goo”, which kroppyer and I answered. Turned out Bimmer is on best speaking terms with maitai of QtVlm, and within a matter of weeks, maitai, fed with our solution and Kipper’s coding had QT equipped with a SOL interpolation button. Thank you, Bimmer!
Really, Qt now needs to be everyone’s router of choice for “blue goo” navigation on SOL. But the modification surely also adds to the Qt router’s IRL prowess, since IMO there can be little doubt that when crossing centres of weather systems, SOL “U/V” interpolation will give you a better steer on where NOT to go, than standard “scalar” interpolation.
Having salved my conscience, it rests me to remind one and all that this is always a race not to be missed, and assuming it will be on the calendar again in 2017 there is likely to be a bottle of best Ron Miel rum up for grabs and an important charity to contribute to:!

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>