February 8, 2018 at 10:44 pm #278
[From User Zembu]
I like your program a lot. I am playing with it on SailOnline.org. One thing I find difficult to decide on is the best options for various lengths of route, and/or boat speeds. You have some advice in your manual about the various options, but I feel you could improve the manual by giving examples of ideal settings for a selection of circumstances. As things are, I experiment with settings, but sometimes it appears the computer has given up – but I don’t know which setting it is that has caused the problem. Also I see you say that smaller Maximum Range makes the computation faster but less accurate. Is this correct? I would have thought the opposite; and what about when negotiating close to land? In that case would smaller MaxRange be better?
- This topic was modified 2 years, 11 months ago by jeff.
February 8, 2018 at 10:45 pm #279
Thanks for the positive feedback!
Reducing Distance and Time Resolution will improve accuracy but run slower.
For mid-latitude regions (60N to 60S) there’s little point in reducing Distance Resolution less than 60 NM.
I see people like to go for small time resolutions but I’m pretty happy with a 2 hour value. On the open ocean, winds don’t vary much within that time frame. Near geographic features, or during frontal passages, winds do change rapidly, but GriB forecasts are also less accurate for micro or meso scale phenomena. A useful strategy is to have a look at how the winds are varying over your race. If they are varying a lot, then go for a smaller time resolution.
Reducing Grid Size is the best way to improve accuracy but the time penalty is the square of the inverse of the reduction, which is to say: if you reduce the grid size by a
factor of 2, the running time will increase by a factor of 4. I usually start out with a 60nm grid size and then reduce it if I want to fine tune my route, down to the smallest value I can stand waiting for.
What I say about Max Range is correct. Reducing max range artificially limits the search space, which makes things go faster, but eliminates the (theoretical) possibility of finding the fastest route.
I don’t worry too much about these parameters, because they don’t seem to make much difference in the optimal route. If you find that not to be true, I would be interested to see examples.
- This reply was modified 2 years, 11 months ago by jeff.
February 8, 2018 at 10:48 pm #283
Thanks Jeff for your answer. BWR is working well for me (In Sailonline).
I’d like to ask another question – reverse isochrones – it appears that the only reason for setting to use these is so that we can get the sensitivity – is that correct? Is there any other benefit in using them? If we don’t use them I expect the optimisation will be faster, would you agree?
February 8, 2018 at 10:49 pm #284
You’re right, Reverse Isochrones are required for the sensitivity data. Some navigators like to use reverse isochrones to help understand how flexible the solution is, but I think the sensitivity is more directly helpful.
Computing the reverse isochrones requires a second run of the algorithm, so it doubles the total time of the optimization run. So absolutely turning them off will save time.
- You must be logged in to reply to this topic.