Weather Routing

[rgleason]

Inverted Regions from the Help file

Inverted Regions This is relatively rare, but in some cases it may be possible to reach a location from two different routes (imagine either side of an island) which is further away from the destination before the destination can be reached. At this point, the algorithm must invert and work inwards on this inverted region (rather than outwards) to possibly reach the destination. This case can occur when routing around islands, or occasionally when routing near a high pressure system. Normally this should be disabled, and extra computations are avoided. NOTE: this mode has bugs

Other Configuration and Settings Straight from Sean's list:

• Max Diverted Course Maximum course error to continue toward destination. Not all possible courses will be considered and therefore the most optimal route may not be found. This usually (but not in all cases) is obvious when the optimal route is sometimes near the edge of the graph. Using a reasonable value can greatly speeds the rate of computation.
• Max Course Angle Like Max Diverted Course, except the search range is based from the starting position to the destination. Normally should be set to 180.
• Max Search Angle This specifies how much the boat course can change between propagations. A value of 180 gives the maximum flexibility of boat movement, but increases the computation time. A minimum of 90 is usually needed for tacking, a value of 120 is recommended with strong currents. Smaller values (60 or less) can give very fast results, but should be used with care, as if the other settings are not appropriate, an inaccurate graph will result. For example, if tacking is needed at any time, then in this case, all courses (0-360) must be specified as degree steps and the boat polar optimized for tacking (see below: VMG tab of boat dialog)
• Max True Wind Knots Do not navigate in areas with more true wind than this value.
• Max Apparent Wind Knots Do not navigate in areas with more apparent wind than this value. This should be set to a high value (ie: 100) if not used to avoid extra calculations.
• Max Swell Meters Do not attempt to navigate in areas with more wave average height than this value.
• Max Latitude Do not navigate above (or below in the southern hemisphere) this latitude.
• Max # of Tacks Does not attempt to tack more than this number of times. Currently it tacks as much as it likes initially, then stops tacking at the limit, therefore if a very low number or an even/odd mis-match is given, a very sub-optimal track may be produced. For this reason a value of -1 (unlimited tacks) is recomended
• Tacking Time Penalty for course change from one tack to the other in seconds. This is normally irrelevant for ocean passages, but could be useful for routes in tight quarters Setting to 0 avoids extra calculations.
• Wind VS Current When wind opposes current rough seas can be produced. This constraint takes the dot product of the current and wind vectors, and if the result exceeds this value, navigation in this area is avoided. For example, a value of 60 would avoid 30 knots of wind opposing a 2 knot current as well as 20 knots of wind opposing a 3 knot current. Higher values allow for rougher conditions; the special value 0 (default) allows any conditions.
• Avoid Cyclone Tracks Uses climatology cyclone tracks to avoid routings which cross historic cyclones. The settings in the climatology configuration for windspeed, pressure elnino etc are used, so only visible tracks are considered.
• Courses (relative to true wind) A list of courses to attempt sailing. Excluding certain values can force the route to explicity show tacks/jibes. Another option is to remove all upwind values to find a course which is always running off the wind (even if it is much longer.) Good results typically have a course every 3-5 degrees; more steps takes longer computation time.

Crossover tab

Shows the relationship of the polars and which one is used for each condition.

Boy would it be great to have a rollover popup for each of these in the program. Great help for users starting out.

[rgleason]

Boy do I like this one Sean! Thanks.

[rgleason]

Gille it is still in the program.
I does not save the User's boat particulars and there is no calc button to Generate Polars anymore, but the code /intent must be in there.

Go to Edit Boat > Edit Polar > Generate TAB

[rgleason]

Ok, Ill try your exe. Maybe we can figure the diff. I'll make a new branch and try diff.

[stelian]

Originally Posted by rgleason

Ok, Ill try your exe. Maybe we can figure the diff. I'll make a new branch and try diff.

I cloned your github, branch "Fix-tws-polars+20-60", compiled and it works (no crash) !

The problem is not in the code but in the compilation environment...

[rgleason]

Originally Posted by stelian

I cloned your github, branch "Fix-tws-polars+20-60", compiled and it works (no crash) !

The problem is not in the code but in the compilation environment...

Have
Reinstalled Opencpn v4.8.0
Deleted opencpn.ini and started it over.
Reinstalled a recompile of my beta PI version
Does not fix the problem.

Installed your earlier PI - it works.
So yes it must be the environment.

What do you have in the Buildwin directory? Just NSIS?
What version of Opencpn.lib ? v4.8.0 from the release which is 135kb?
We don't need ocpn_plugins.h do we?

I checked my permissions (right-click properties) in ProgramData and found it is "Read only (Only applies to files)" And it is the same for subdir. I went to the TAB Security and there are these users

ProgramData Dir
Creator Owner - has special permsisions only
System - has all but special pemissions (some greyed)
Administrators - same as System
Users - have Read & Execute, List folder contects & Read & Special Permissons

OpenCPN Dir
Creator Owner - has special permsisions only
System - has all but special pemissions (some greyed)
Administrators - same as System
Users - have Read & Execute, List folder contects & Read & Special - Also users have Modify (not grey) and Special permissions (not grey) everything else is a grey check.


Plugins Dir
Creator Owner - has special permsisions only
System - has all but special pemissions (all greyed)
Administrators - same as System
Users - same as System

Weather_routing Dir
Creator Owner - has special permsisions only
System - has all but special pemissions (all greyed)
Administrators - same as System
Users - same as System

Polars Dir
Same as Weather_routing.

Boats Dir
Same as Weather_routing.

The files themselves are not checked read only and the security is generally all checked but grey.

I think it is the environment but wonder what it could be.

[rgleason]

I turned off Norton Security & Virus, disconnectiing from the internet, didnt help.

Have been checking Norton Security, and it certainly has been busy submitting the compiled files to Norton Community, but I don't see anything that is preventing things from running, from scanning the Norton history. I should check Norton Settings perhaps.

I suppose Norton could have removed an essential MSVC++ file without advising (its done that before) but I don't see any indication of that in the history and the quarantine has a couple of email spam files from Nov and Oct.

This is pretty picky stuff.

[rgleason]

If it is my compile environment, it isn't the main serup. I've complied and run opencpn with no problem.

So it could be a missing a file in buildwin, or build. -What files do you have there that you added?

[stelian]

Originally Posted by rgleason

If it is my compile environment, it isn't the main serup. I've complied and run opencpn with no problem.

So it could be a missing a file in buildwin, or build. -What files do you have there that you added?

In buildwin I have just NSIS.template.in (the file from the git, unmodified)

In build I've copied opencpn.lib 137692 bytes, sha1sum:

f87c334c7c70e213807fe11e7508917e4c820b10 *opencpn.lib

You can get my version from: http://popies.net/tmp/opencpn.zip

I have compiled the plugin by doing:

mkdir build
cd build
cmake -Wno-dev -G "Visual Studio 12 2013" -T "v120_xp" -D CMAKE_CXX_FLAGS=/MP -D CMAKE_C_FLAGS=/MP ..
cmake --build . --config release
cpack

[rgleason]

Stelian, Thank you!
This morning I tried removing my local repository and cloning again.
Setting up remotes to stelian42 and seandepagnier and upstream to sean.
Then git fetch to each and reset hard and compile. I did that 3 times for each repos and they all compiled and installed and would route, but would not Edit Polar Edit Dim TAB.

Then I saw your post downloaded the opencpn.lib and the SHA1 checked out. That did not seem to make a difference either. (my local build and buildwin are same as yours). So then I tried your cmake line:

cmake -Wno-dev -G "Visual Studio 12 2013" -T "v120_xp" -D CMAKE_CXX_FLAGS=/MP -D CMAKE_C_FLAGS=/MP ..

and that did the trick using your source code!
Normally I use

cmake -T v120_xp ..

Obviously there is more to learn. What does your cmake do that mine does not do?

-- I am going to try yours using my "master" branch now.

Thanks so much. This had me totally stymied! I was thinking I'd have to rebuild my entire github folder

[stelian]

Originally Posted by rgleason

What does your cmake do that mine does not do?

Frankly I do not know. This comes from Transmitterdan's BatchUTILS, config.bat I believe.

Glad you have a working configuration now !

[rgleason]

Made a PR from
stelian --> rgleason git repos of the po & pot branch --. automatic merge.
hakan --> rgleason git repos of his po & pot branch --- Won't auto merge conflicts

https://github.com/rgleason/weather_routing_pi/pull/2
Conflicting files

po/fr.po
po/weather_routing_pi.pot

Here is a comparison of my repos master to hakan's new branch..

https://github.com/rgleason/weather_...ansv:po_update

[rgleason]

I'm just learning some of this. It looks like my repos now has your
po updates.

https://github.com/rgleason/weather_...french-updates

[Gilletarom]

Hello Sean, hello All,

I realized yet another test with the latest version of WR uploaded by Stelian. I specify that, unless error on my part, the bug that I report here also exists with the previous version.

WR actually uses a virtual boat to work. And, if the calculations end well, the result is a virtual track. We can export this virtual track and we get a real track in the OpenCPN track manager.

I created a virtual track by loading a new grib file and using the same boat configuration as in my last test, so, especially with the figaro2 boat. This boat has the advantage of having very complete polar, which excludes polar anomalies.

See the first screenshot.

Then, I export the virtual track. So I got a real track in the Routes and Tracks manager. In the track manager, I select this real track, and I transform it into a route (So into a real route).

The following screenshots show:
- The coordinates of the start-point and that of the End-point, as they appear in WR.
- The coordinates of the start-point of the route and the coordinates of the end-point of the route.

The start-point in WR and the start-point in the route of the route manager are identical (small difference due to rounding in the route manager, this is not a problem)
BUT
The end-point in WR and the end-point in the route manager are different. This is not the same point.

Explanation:
When exporting the virtual track, the real track that appears in the track manager does not end at the end-point entered in WR. It ends at the last waypoint just before WR's End-point. In other words, the end of the virtual track miraculously disappears .....

This seems to me to be a BUG.

Gilletarom

[rgleason]

Ok now my git master has merged all PR except Hakan's
I can now use it locally and compile.