Post by iconPost by zezo | 2012-01-17 | 23:19:06

I've tweaked some parameters so the optimizer will work better in the current conditions - it can now see the route around India and Sri Lanka.

But there had to be a sacrifice in order to keep the complexity down. Now it will cowardly refuse to sail at all if the given destination too far behind the corner. Or it may start doing stupid things like sailing at twa 155 instead of 135.

The old way was somehow more foolproof. The new one is more accurate, but may need a bit more human input, and fails in a less obvious ways.

commenticon 8 Comments
Post by iconPost by pgfiore | 2012-01-17 | 23:25:03
I did not want to see it... :( Just hope it's wrong!!!! xD
Post by iconPost by zezo | 2012-01-17 | 23:32:06
If you have a problem it's at the corner, not behind it, so you've already seen it. Unfortunately it's not only the optimizer change - the forecast got worse around 8N 76E. It looked much better 24 hours ago.
Post by iconPost by pgfiore | 2012-01-17 | 23:50:13
duly noted! but... I'm headstrong and stay on the CG. leg 2 dimostrates how are forecast reliable!!!

nice sentence however; the corner is the unknown... turning it and it becames, bad or fair, just something to manage!
Post by iconPost by PatH | 2012-01-18 | 00:05:39
I'm curious as to why the numerical process couldn't see around the corner... but don't waste too much time on it as I would likely miss the nuance difference that allows it to work better/worse through the holes and around the corner. (I did note the weather setback at the corner as well) I've been leaning south myself anyway and slightly split my two boats as a hedge to the risks the holes at the tip of India and Sri Lanka represent. We'll see how things work out. I hate low winds. Bring on the southern ocean!
Post by iconPost by zezo | 2012-01-18 | 00:50:36
Not sure If I can explain it in less than two pages and few pictures, but will try to give you some idea.

The problem is that I use radial approach for filtering some points out. As a result the isochrones can spread more or less only in direction opposite to the starting point. Around the corner in our case means that the spreading direction does not match the direction towards the destination anymore. Prevailing winds were making the matters worse - with NE winds you can't sail directly NE, and pure N, which was possible, was discarded. It would work better with N or NE wind.
Post by iconPost by PatH | 2012-01-18 | 01:25:07
Thanks Cvetan, I think that does it. So the "more arduous" process that would crash the server probably has fewer optimizers and looks along a broader path filtering fewer points?
Post by iconPost by zezo | 2012-01-18 | 08:11:11
The trade-off is a space covered vs. spatial resolution

In this case narrow path with higher resolution works better.

The basic idea is that in general it does not make sense to sail in direction which is opposite of the destination, so you discard some headings.

In open sea and stable conditions you could check only 90 degree sector around the destination point. This would be enough to allow going upwind and tacking in the worst possible case.

Things change when there is an obstacle in the way in the form of land mass or weather system.

Example: If you wanted to sail from W to E coast of India right now starting at 20N the initial direction is downwind with heading of about 190 or 200. If you are sailing towards 20N at the other side this is at least a 100-degree angle between destination and initial heading with effectively negative VMG. To cover that case you have to consider 200-degree sector. But a 200-degree sector covers 4 time more area than 100-degree, and is therefore about 4 times slower.

It's not exactly 4 times - could be 2 or 8, because one of the optimizations is that directions with TWA below 40 or above 160 are simply discarded as inefficient. So if you get the narrow 90-degree sector case combined with direct upwind path it's effectively decreased to 10-degree sector and will be very fast. Yesterday I decreased the sector from 240 to 180 degrees, which combined with wind direction is like effective decrease from 160 to 100.

All of this would not matter in a standalone application - you would get the result in 2 or 5 seconds instead of 1, but with this multiuser environment even increasing the time from a to 1.5 seconds can be a disaster at peak times.

Let's suppose 60 people try to access the site in one minute. The 1-second case will almost work. It will work perfectly if the requests come at 1/second, and fail badly if all requests come within few seconds. In the worst case (60 requests in 1 second) you can do two things - 1. spool them and run them one by one. This guarantees up to 60-second response time with fastest response at 1 second. 2. run 60 parallel requests - this gives 60-second response time for everyone. Here is where you get avalanche effect - running requests in parallel has some overhead so it gets slower with increased demand. After some waiting period users start reloading which increases the demand further. The queue and waiting times gets longer and sometimes everything grinds to a halt (btw this is what happens with the game servers too around wind update times when you can't save changes)
Post by iconPost by PatH | 2012-01-19 | 00:04:30
Hey Cvetan,

Thanks for the great explanation. I really appreciate it. While I'm not a computer programmer, I do quite a lot of numerical simulation so I can appreciate your issues and descriptions. Thanks for taking the time. Cheers,
border
Topics list
Posts
border
5
border
border
Copyright 2009 by ZEZO.ORG. All Rights Reserved.