Accuracy of the predictor line and boat tracks when on TWA

During my over an year as a technical admin in SOL, there have been perhaps couple of dozen times when this issue has been brought to me:

• The boat has approached the mark using TWA
• The rounding has not happened according to the server
• The track of the boat shows that the boats has rounded the mark on the correct side
• Usually also the sailor says that the TWA predictor line showed that the mark should be rounded correctly

There are actually two problems (or perhaps better term would be features) affecting the issue.

1. The boat tracks in the client are not really accurate when the boat has been on TWA

I haven't been in SOL that long but I have been told that originally there was no TWA command, only CC. The tracks were then straight lines between the points where new commands were issued. 

Later the TWA command was introduced which brought up the problem that the track between the points where course was altered by commands was not straight any more. To handle this issue the server sets up track points to the boats when they have altered course enough from the course they had when the previous track point was set. 

It would be impractical to have too many track points for the boats because they would take too much space in the DB and more importantly, dataset of the boat tracks would also grow pretty big and would be difficult to load to clients having slow internet connection.

So, while reality the boat has traveled a curved line according to the wind direction changes, the track seen on the client is series of straight lines between the places where the server has decided to add a track point for the boat. This means that you can't really accurately determine from a track has a boat rounded a mark or not if the rounding has been very tight.  

2. The predictor line in the client is not 100% accurately the path the boat will sail

The TWA predictor that you see is calculated in your client (that is, in your browser) according to the weather information received from the server, your current heading and time. Although it has proven to be pretty accurate, it's still not doing the calculation with the same precision as the server does. This can lead into small differences, which can be meaningful if trying to set the course really accurately using TWA predictor.

Summary

I personally have been caught by trying to make a really tight mark rounding using TWA and ending up missing the mark. I believe most of us who have been in SOL for a longer time have. Nowadays I always try to leave some margin (how much, it's up to you and how much you want to risk) if I use TWA or then switch to CC just before the rounding. 

In my mind, this issue is bit similar to the fact that in real sailing, you always leave some room to the mark to allow waves moving it a bit. If you don't do it you might still make a clear rounding with luck but you are not guaranteed to do so. 

How is your predictor line

So far my sollog utility has been about recording statistics about the boats. First it was storing the history every hour, i.e. the latest data available was the last full hour. Recently I added the almost real time statistics which are updated every minute. (For anyone interested in IT, the latest numbers are only stored in memcached where the web page gets the information.)

Now it's time to look into future. As we now know every boat's location and course, it is pretty easy to calculate where that boat would be if it would continue with the same course (or same TWA). As we also have the weather forecast we can use this information to calculate the wind speed, direction and also boat speed on the predicted point.

This is basically what the predictor line in the game client is, an estimate where your boat will be if you continue without any changes. So far I have calculated the predicted wind speed by changing the weather slider to the desired time and then pointed the mouse on that spot on the predictor line so you will get the wind speed and direction. With this information you can then estimate your boat speed from the polar.

In my view SOL is not about who can calculate best but rather who can make the best decisions (or luckiest guesses) based on the calculated numbers I decided to make this tool for easier calculation. Because sollog updates it's information from the server once per minute there might be few percent tolerance in the calculated numbers so don't rely on them when navigating in really narrow places.

To access the predictor, select the desired race from the races list, then enter the boat name and press the button "Predicted data". The default view is 6 hours continuing the same course (COG) as your boat is sailing at the moment. You can change that to TWA by pressing the TWA-button. If you want to see values for other courses (COG or TWA) set the desired course to the degrees-field and press the TWA or COG button.

Unfortunately for now there is no way to tell which weather forecast the predictor is using. Currently sollog fetches the weather file only every full hour, so after a new forecast you must wait for the next full hour for it to be in use. Before it didn't really make much difference in the way sollog was using the weather data but I will probably fix that soon as definitely has effect on the predicted data.

Aaron's Sailonline tools

Yesterday I have finally updated the client that we have used to know as "beta" to be the default version. Aaron (or AGage as we used to know him in SOL) was the key person in the SOL development group and his unfortunate passing away of in June set us badly back but hopefully we are again catching some speed.

The client version we now use was last updated by Aaron just 4 days before his death and he had also just started development of the tools that he planned for helping people sail their boats better.

It is really fortunate that he had asked me in May if I could host these tools on my SOL site so that we have them in our use. He also gave me access to their sources so perhaps the development of them will continue some day. However they are written in Flash which I unfortunately am not at all experienced with.

Most people are probably aware of them by now but I have written a short introduction anyway. And if you are not aware of who Aaron was and what he has done to help SOL I would suggest that you should read this thread about people remembering him and his accomplishments.

Aaron was also the person helped me in developing my sollog site and who then asked me to join the SOL admins. We had an enjoyable 5 months of collaborating which was abruptly cut short.

WxInspector

The WxInspector (wx is short for weather forecast) can be used to analyze the weather and it has actually many tools for this:

• Horizontal Profile - display the wind speed and direction along a line on the map. The display changes according to the weather slider in the bottom of the page.
• Ruler Path Profile - same as Horizontal Profile but the line is a ruler path so it doesn't have to be just a straight line.
• Meteogram - display the wind speed and direction on the marked map point over time. This is mainly useful for spotting when a wind shift is forecasted to happen.
• COG Isochrones - display how far your boat would sail if it sailed a direct line from it's current position to different directions according to the current forecast. You can change the display interval and limit from the advanced options.
• TWA Isochrones - display where your boat would sail if it sailed continously to different TWA's from it's current position.
• Clear Isochrones - clear the isochrone lines from map.
• Optimal Angles - this is the same as the optimum angles tool described below.
• Wind Log - the historical data of the wind your boat has experienced during the race (the history goes as far as this WxInspector window has been open).
• Boat Log - the historical performance data of your boat: speed, course and TWA.

Optimum Angles

The Optimum Angles is for easy calculation of VMG (both upwind and downwind), maximum boatspeed and especially VMC (Velocity Made Course) from the boat's polar. I will not go into detail what these terms actually mean but to be a good virtual sailor understanding them is a must. A good place to start learning is 76Trombone's blog.

Other boats speed and weather data in sollog

Other boats course in SOL can quite easily be roughly estimated from the client. It's also possible to get the current wind speed and angle on the location of a boat by setting the cursor on top of it. With this information together with the polar information you can roughly estimate the other boat's speed.

My understanding is that the more technically advanced solers might even have some automatic ways to get other boats speed and other information but for newcomers and not so technical people getting them can be time consuming and difficult.

Brainaid's sol toolbox has also the NMEA proxy which brings similar data from other boats as simulated AIS data to your computer. If you have the right navigation software installed you can see this data.

I have now added the other boats almost real time speed, course and wind data easily available to anyone interested in sollog. It can be educational to see how the top players sail and of course it's handy if you want to cover an opponent.

I was a bit uncertain first should I add this feature or not. It certainly reveals quite of a lot of information from the other boats. But when people in the race chat told me that similar information is already available I decided that it's probably more fair to have the data easily available for everyone.

Instructions how to see other boats data

The current data is showed only for boat lists, so you have to first define the names of the boats you are interested in seeing data from. For example for the Global Challenge Leg 3 which is currently running you can do that here (if you are reading this after that race has ended, you can't see any current data there as the boats are no longer sailing).

Type in the box name of the boat and click add. You can repeat this for all the boats you want and when ready click the "Latest data" (you can always come back to this page to add more boats later).

As an example you can look what the data looks like for the boats which were in top-5 when I was writing this.

You can then see the speed, heading, TWA, wind direction and speed of each listed boat. The data should be automatically updated every minute and it should be quite near the actual numbers the server is using. The data is calculated in the same way as you would do manually if you first estimated boats location & course from the client. Then do the same for the wind and estimate the speed from the polar information. The only difference is that the computer can do that same faster and with more detail.

DTF calculation problems near the polar area

As I shortly mentioned in my previous post, the DTF calculation can be weird if there are mark roundings near the polar area. I'll try here to explain how the calculation happens and why it fails near the poles.

For this explanation I must admit I have not tested it manually with the server code so I am not sure that everything is 100% correct. This is more like explanation of the way what I believe happens. There are other experienced SOL'ers who have also tried to explain this in the race chats and you are welcome to correct me in any detail I might have got wrong.

DTF calculation when rounding marks

As I explained in my previous post, SOL considers a mark rounded when you cross the line which represents half of the outer angle the mark makes to the route. If we again use the same example of approaching the mark from west and turning north the line would be SE of the mark (135 degrees).

How DTF calculation is affected by this theoretical "rounding line" then. Sometimes in sailing the best route around the mark doesn't go the near it which is the shortest path but boats can choose to round them "wide". SOL tries to anticipate this by calculating what is the boats shortest path to round the mark (cross the rounding detection line) and the shortest path from the rounding point to the next mark.

If the example we have is not near polar area or the distances are short, the boat's DTF is calculated via the mark until the bearing from the boat to the mark is 45 degrees (90 degrees to the rounding line). Only if the boat continues more southeast than that, then the anticipated rounding point comes into play and is used in the calculation. Usually this means that the weather pattern near the mark is such that wide rounding is better or the boat is wide for some reason and the route boat is going to sail can be pretty near the path used for DTF calculation. 

How this changes near the polar area

If we now think of the rounding line in Cape Horn, the rounding line starts from the mark and continues roughly in the direction 145 degrees SE ending to the South Pole. If you wonder how it ends to the Pole think of a vessel which starts from Cape Horn and continues to the compass course 145. If we ignore the problem of it running into ice or Antarctica it will end up as south as possible which is the South Pole. 

So, when the boats are at southern Pacific the DTF calculation tries to find the place where each one is nearest to the rounding line. One end of the line is at Cape Horn and the other is at South Pole. So, when the boats are still really far away from Cape Horn there can easily be a situation where a boat is nearer the pole than the next mark. So the path the DTF calculation uses is first from the boat's position to pole and then from there to the mark after Cape Horn (which is finish in case of Global Challenge leg 3). 

As the boat's distance to the South Pole depends how far south it is, in effect this means that before the boats are near Cape Horn (and here near means more than 1000 miles) their DTF is calculated via South Pole and the DTF's the game displays have no real meaning. Partly because of this I have added the distance to next mark as one of the parameters my sollog site displays. 

In reality SOL race engine tries to anticipate this problem a bit and the rounding line is limited not to go as far as the poles. The actual point SOL uses in the case of GC Leg 5 is at 83 degrees south and 34 west.

Possibility to fix the problems

The method SOL uses has it's obvious problems in the polar area as described above. Also other situation where it doesn't work very well is when the angle of the turn to the next mark is not very big, especially if the two marks are very near each others.

However, the method also has it's benefits. By anticipating the rounding point there very rarely are abrupt changes in the boat's DTF when rounding a mark. The algorithm is also relatively simple for the computer to calculate. 

The DTF calculation with it's problems is one of continuing subjects in SOL. Many different improvements have been suggested and some of them can perhaps be taken into use in the future. 

However, one essential thing has to be remembered when thinking this calculation. The server runs the DTF calculation after each "hop" (as described in last post) of the boat. This means that this code is run every 15 seconds for each boat racing so too complicated DTF calculation has the danger of slowing the server down.

Scoring problem on races crossing IDL and rounding Cape Horn

As SOL is now sailing again in Southern Pacific the curvature of earth and the international dateline (IDL) is playing some tricks on SOL. This is my understanding what happens there.

Rounding detection

First of all, a short explanation on how DTF (Distance To Finish) and mark roundings are handled in SOL. Each mark causes a turn in the route, i.e. if we approach the mark from west and the next mark is north, the turn is 90 degrees. SOL considers the mark rounded when the boat crosses the line representing half of the turn needed. So assuming we come to mark in 90 degrees and turn to 0 degrees, the mark is rounded when the boat crosses the line SE (135 degrees) from the mark.

Now, the SOL sailing engine sails the boats in "hops", i.e. it moves the boats every X seconds to the direction they are pointing and the amount of the movement depends on the wind on the boat's location, the boat polar and how many seconds there has been since the last movement of the boat. Usually on normal server load the hops are about 15 seconds.

After each hop, the engine checks if a mark rounding happened, that is did you happen to to cross the half-angle of the next mark rounding. Unfortunately this calculation doesn't understand crossing the IDL so when you cross, it thinks that you traveled all the way around the world on that hop.

If you cross the IDL more south than Cape Horn (S 55.98) the server actually thinks that you have rounded the mark. This is because the server thinks your hop went all the way around the world other way (below Australia and Africa etc.) crosses the line which server considers the limit for mark rounding, so it marks the boat as rounded. If you cross north of Cape Horn, your hop (or what the server think it is) goes north of Cape Horn as well and thus no rounding is marked.

How this affects the DTF

For boats that have not rounded Cape Horn the DTF is calculated so, that the GC (Great Circle) distance to the mark rounding is added to the distance from that rounding to the next mark (in the case of Global Challenge Leg 3 the finish).

But if the server thinks that the boat has already rounded Cape Horn, it will calculate DTF simply as the GC distance to the next mark. This is why some boats have suddenly gained 600 miles when they have crossed the IDL.

Fixing the problem

For the current race, the fix is that the boats with incorrect roundings are corrected in the server to not have rounded Cape Horn yet. No boat has gained any advantage by this problem because it's just the DTF calculation which has been wrong.

The admins probably could have been faster reacting to this problem but it occurred first time 24 hours ago and I spent yesterday getting into the root of it by re-running manually the server code calculating the DTF and mark rounding before I fully understood what it was about.

From previous races run in this area the admins knew that there has been something wrong with the IDL and we tested this race beforehand by sailing over the IDL in practice mode when the race was not yet public. Unfortunately we didn't understand that the problem happened only when the crossing happens more south than Cape Horn and didn't detect the problem then.

In the long run of course the server mark rounding code in the server has to be fixed to prevent this situation happening in the future races.

DTF calculation near the polar area

Year ago when we run in this same area in the SWR Leg 5 the same problem happened but that time the boats with incorrect roundings had their DTF actually increasing by 2700 miles. This is because SOL tries to anticipate where the boats rounding will happen by calculating the shortest distance the boat has to sail to round the next mark. 

In the polar area if the boat is nearer the pole than the next mark the shortest distance to the rounding is actually at the pole. The problem with this is that the distance from the pole to the next mark is then much longer so in these situations the DTF's may feel weird. When the boats get nearer the next mark this problem will correct itself.

Timed races in sollog

Now, as the Holiday Star timed race has just opened in SOL it probably is a good time to talk about one shortcoming sollog has. It doesn't support timed races at all so unfortunately you can't view your timed races there at all.

The basic reason for not supporting them is that the current data model I use doesn't like having multiple boats with the same name in the same race. And that's what happens when someone does more than one attempt.

At the time this came apparent last spring I shortly consulted the most active solers and the consensus seemed to be that sollog is not so important for timed races so I just decided not to do them at all. After all, the hourly rankings don't make much sense when boats have not started at the same time.

Thinking of it now, timed races probably would need a different approach, it would be nice to compare two timed runs head to head so that you could see the speed/wind/location of the boats compared to their start time. However that would mean that I'd have to start polling the boat positions more often than just once per hour but that might be manageable.

I'd like to hear if many people are missing the timed races in sollog and also any ideas what kind of information should be shown for them?