Does not work with GRIB_pi & O fails. v4.2.1706

[rgleason]

Just built Pavel's repos with #38
and tried routing with a Saildocs + Current. The files had different start and end times, but I set the grib time to the first frame when both gribs had data, and set the Route start time to that, and it fails still.

Then just tried a single regular non-grib2 GFS saildocs file and O fails.
The plugin seems to be broken, won't route a simple routing with a GFS Saildocs file.
Tried a number of times and different ways.
Sorry.

Win10
v4.2.1706
Weather_routing_pi from Pavel's repos - (just saw) Sean has merged this 21 hours ago.
will try that.

[nkiesel]

It seems that the recently added support for gribV2 breaks this because this changed the physical layout of GribRecord. Therefore, what the grib_pi stuffs into the data is not what weather_routing_pi expects.

Seems pretty fragile to rely on these 2 projects to keep their data structures in sync. Should we not minimally add a version number to the data so that weather_routing_pi simply complaints instead of crashing O?

[nkiesel]

I tried to fix this (by copying some files from O to this plugin and adding a dummy virtual function and now it no longer crashes. However, it always reports "Failed" as state. How can I debug that further?

[nohal]

Isn't this fixed by #39 ?

[rgleason]

Pavel, have you made these changes in #39 to the plugin? If so what version of Wx-routing, and where to download? Also what version of Opencpn should we be testing with?
Then I will try it.

[nohal]

This is not my project, I am not merging changes from other devs into my clone unless absolutely necessary.

[rgleason]

OK, fine. What should I test? Where the devil is Sean?

[nohal]

The plugin built with #39 applied. There is no binary for it, you have to build yourself.

[rgleason]

Ok, I guess I can do that, can you tell me which version of OpenCPN to test with? & should I build that too?

[nohal]

No you don't need to build OpenCPN, you should test against 4.2.1724 released today.

[rgleason]

Ok will test tonight. Thanks.

[seandepagnier]

I am still making big changes to the plugin which has slowed me down, and haven't had the time or internet to do much. Hopefully today I can.

[nkiesel]

I saw that the data sent by grib_pi had a vtable for GribRecord, but the same was missing for GribRecord in weather_routing_pi, which messed up all the data (resulting in SEGV). I "fixed" that by adding a dummy virtual function into GribRecord from weather_routing_pi. Perhaps was caused by compiling one with optimization and the other w/o?

Another problem were SEGV caused by accessing non-null but uninitialized BMSbits. I saw that there is also a hasBMS flag now, so I added tests for that next to the != NULL checks and that did the trick. Perhaps grib_pi should anyway set this to NULL when not used?

I would of course be happy to share all of this but while it no longer crashes, I still always get "Failed" when computing a route.

BTW: I use the master branch from this repo, not crossover. Is that correct?

[nkiesel]

Success!!!

With pull request #39 merged I can again compute routes w/o any local patches. My earlier problems were caused by stupidly copying the files into the wrong directory. Thanks so much. Now on to get a nice route for the Spinnaker Cup this weekend!

[rgleason]

Sean, before this I git fetched 7 days ago and built and it worked with pr#39 and v4.2.1724.

Now I git fetched your repos and built and I get errors.... sorry.

Build FAILED.

"C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi\build\ALL_BUILD.vcxproj" (default tar
get) (1) ->
"C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi\build\weather_routing_pi.vcxproj" (de
fault target) (4) ->
(ClCompile target) ->
C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi\src\BoatDialog.cpp(72): warning C480
0: 'long' : forcing value to bool 'true' or 'false' (performance warning) [C:\Users\Rick\Documents
GitHub\o-plugin\s-weather_routing_pi\build\weather_routing_pi.vcxproj]
C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi\src\BoatDialog.cpp(73): warning C480
0: 'long' : forcing value to bool 'true' or 'false' (performance warning) [C:\Users\Rick\Documents
GitHub\o-plugin\s-weather_routing_pi\build\weather_routing_pi.vcxproj]
C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi\src\BoatDialog.cpp(774): warning C48
05: '!=' : unsafe mix of type 'int' and type 'bool' in operation [C:\Users\Rick\Documents\GitHub\o-
plugin\s-weather_routing_pi\build\weather_routing_pi.vcxproj]
C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi\src\BoatDialog.cpp(1018): warning C4
800: 'unsigned int' : forcing value to bool 'true' or 'false' (performance warning) [C:\Users\Rick
Documents\GitHub\o-plugin\s-weather_routing_pi\build\weather_routing_pi.vcxproj]
C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi\src\PolygonRegion.cpp(392): warning
C4800: 'int' : forcing value to bool 'true' or 'false' (performance warning) [C:\Users\Rick\Documen
ts\GitHub\o-plugin\s-weather_routing_pi\build\weather_routing_pi.vcxproj]
C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi\src\PolygonRegion.cpp(394): warning
C4800: 'int' : forcing value to bool 'true' or 'false' (performance warning) [C:\Users\Rick\Documen
ts\GitHub\o-plugin\s-weather_routing_pi\build\weather_routing_pi.vcxproj]

"C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi\build\ALL_BUILD.vcxproj" (default tar
get) (1) ->
"C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi\build\weather_routing_pi.vcxproj" (de
fault target) (4) ->
(ClCompile target) ->
C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi\src\BoatDialog.cpp(478): error C2668
: 'fabs' : ambiguous call to overloaded function [C:\Users\Rick\Documents\GitHub\o-plugin\s-weather
_routing_pi\build\weather_routing_pi.vcxproj]
C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi\src\PolygonRegion.cpp(238): error C3
861: 'snprintf': identifier not found [C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi
\build\weather_routing_pi.vcxproj]

6 Warning(s)
2 Error(s)

I think I am missing a file in your repos?

[seandepagnier]

Thank you rick, I have attempted corrections.

Sean

On 6/1/16, Rick Gleason notifications@github.com wrote:

Sean, before this I git fetched 7 days ago and built and it worked with
pr#39 and v4.2.1724.

Now I git fetched your repos and built and I get errors.... sorry.

Build FAILED.

"C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi\build\ALL_BUILD.vcxproj"
(default tar
get) (1) ->
"C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi\build\weather_routing_pi.vcxproj"
(de
fault target) (4) ->
(ClCompile target) ->

C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi\src\BoatDialog.cpp(72):
warning C480
0: 'long' : forcing value to bool 'true' or 'false' (performance warning)
[C:\Users\Rick\Documents
GitHub\o-plugin\s-weather_routing_pi\build\weather_routing_pi.vcxproj]

C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi\src\BoatDialog.cpp(73):
warning C480
0: 'long' : forcing value to bool 'true' or 'false' (performance warning)
[C:\Users\Rick\Documents
GitHub\o-plugin\s-weather_routing_pi\build\weather_routing_pi.vcxproj]

C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi\src\BoatDialog.cpp(774):
warning C48
05: '!=' : unsafe mix of type 'int' and type 'bool' in operation
[C:\Users\Rick\Documents\GitHub\o-
plugin\s-weather_routing_pi\build\weather_routing_pi.vcxproj]

C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi\src\BoatDialog.cpp(1018):
warning C4
800: 'unsigned int' : forcing value to bool 'true' or 'false' (performance
warning) [C:\Users\Rick
Documents\GitHub\o-plugin\s-weather_routing_pi\build\weather_routing_pi.vcxproj]

C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi\src\PolygonRegion.cpp(392):
warning
C4800: 'int' : forcing value to bool 'true' or 'false' (performance warning)
[C:\Users\Rick\Documen
ts\GitHub\o-plugin\s-weather_routing_pi\build\weather_routing_pi.vcxproj]

C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi\src\PolygonRegion.cpp(394):
warning
C4800: 'int' : forcing value to bool 'true' or 'false' (performance warning)
[C:\Users\Rick\Documen
ts\GitHub\o-plugin\s-weather_routing_pi\build\weather_routing_pi.vcxproj]

"C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi\build\ALL_BUILD.vcxproj"
(default tar
get) (1) ->
"C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi\build\weather_routing_pi.vcxproj"
(de
fault target) (4) ->
(ClCompile target) ->

C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi\src\BoatDialog.cpp(478):
error C2668
: 'fabs' : ambiguous call to overloaded function
[C:\Users\Rick\Documents\GitHub\o-plugin\s-weather
_routing_pi\build\weather_routing_pi.vcxproj]

C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi\src\PolygonRegion.cpp(238):
error C3
861: 'snprintf': identifier not found
[C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi
\build\weather_routing_pi.vcxproj]

6 Warning(s)
2 Error(s)

---

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#40 (comment)

[rgleason]

That did the trick. Will advise about running it. Some warnings FYI.. Thank you!

Build succeeded.

"C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi\build\ALL_BUILD.vcxproj" (default tar
get) (1) ->
"C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi\build\weather_routing_pi.vcxproj" (de
fault target) (4) ->
(ClCompile target) ->
C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi\src\SettingsDialog.cpp(104): warning
C4800: 'long' : forcing value to bool 'true' or 'false' (performance warning) [C:\Users\Rick\Docum
ents\GitHub\o-plugin\s-weather_routing_pi\build\weather_routing_pi.vcxproj]
C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi\src\BoatDialog.cpp(773): warning C48
00: 'int' : forcing value to bool 'true' or 'false' (performance warning) [C:\Users\Rick\Documents
GitHub\o-plugin\s-weather_routing_pi\build\weather_routing_pi.vcxproj]
C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi\src\BoatDialog.cpp(1019): warning C4
800: 'int' : forcing value to bool 'true' or 'false' (performance warning) [C:\Users\Rick\Documents
\GitHub\o-plugin\s-weather_routing_pi\build\weather_routing_pi.vcxproj]
C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi\src\libtess2\sweep.c(1126): warning
C4244: '=' : conversion from 'double' to 'TESSreal', possible loss of data [C:\Users\Rick\Documents
\GitHub\o-plugin\s-weather_routing_pi\build\weather_routing_pi.vcxproj]
C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi\src\libtess2\sweep.c(1127): warning
C4244: '=' : conversion from 'double' to 'TESSreal', possible loss of data [C:\Users\Rick\Documents
\GitHub\o-plugin\s-weather_routing_pi\build\weather_routing_pi.vcxproj]
C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi\src\libtess2\sweep.c(1128): warning
C4244: '=' : conversion from 'double' to 'TESSreal', possible loss of data [C:\Users\Rick\Documents
\GitHub\o-plugin\s-weather_routing_pi\build\weather_routing_pi.vcxproj]
C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi\src\libtess2\sweep.c(1129): warning
C4244: '=' : conversion from 'double' to 'TESSreal', possible loss of data [C:\Users\Rick\Documents
\GitHub\o-plugin\s-weather_routing_pi\build\weather_routing_pi.vcxproj]

7 Warning(s)
0 Error(s)

[rgleason]

Sean, these menus for the Boat are looking much better to me!!!
In trying to get a route to plot, I have added several polars, and then highlighted one.
I have then saved boat and gone to button to set Grib time to the beginnning of the GFS grib, and tried compute. It seems to fail. Tried a number of things.

I guess we are going to be able to use different polars and establish when to change to a different polar.
I like the way you have it setup now. I guess we are simplifying and not trying to do quite as much? Will work with it further and advise... as I learn more.

Thank you for your improvements.

I built for v4.2.1724 using opencpn.lib 4.2.1724 is that correct?

[rgleason]

I just tried another GFS and a routing that worked before, set the grib time etc, tried to check that the boat polar was selected, think I selected it and tried compute. ..Failed.

I think we must have a separate slot showing the actual boat polar file being used, somewhere after you close the selection of the boat polar in the Configuration file under "Boat" have "Polar File" This would be confirmation to the user that they have a polar selected that is accepted as valid.

... I think it is failing because I have not selected the polar file properly or something.... and I cannot see the full path under "Boat" anyway.

PS: I can scroll to see the full path,... and now I seee that "Boat" has
C:\ProgramData\opencpn\plugins\weather_routing\boattest.XML
I saved boattest.xml from the new menus after picking polars and loading them in and then highlighting one of them. Then I think I Saved Boat and typed "boattest" and xml was added.

You used to have boat parameters which we could enter and polars would be calculated. These parameters were saved in the xml files. The problem was that you would enter the parameters in for your boat, the polar would be generated, (or you could load a polar file *.pol, csv, etc) and you could save the boat file as Yourboat.xml. The the next time you opened up the plugin, it would all be reset back to the startup boat.xml file and you would have to enter your boat's parameters back in again to get a generated polar from the boats parameters.

The polar files (.pol, .csv etc) in the correct format could also be used before (and now) but that was a separate method.

In the current plugin how do the boat parameters work? perhaps I am not getting this.
This is why I think we a slot to show the polar file being used to calculate the route.

Maybe we even need checkboxes to direct the program whether to use

1. a generated polar from the boat parameters file or
2. a polar (or multiple polars) as setup under Boat Edit

I think if I add multiple polars to the "Polars List"
There is calculation going on about which polar is best to use for given conditions because I see these purple and yellow lines when I go to the polar tab.

I am uncertain what I should do with "Crossover" but I think this is sort of like setting up sail changes or change in sea conditions or something like we had before. This seems to stay blank no matter what I do...?

Anyway that's what I get from poking around a bit.

Thanks nkiesel and lance that's helpful to know others have similar problem.
Sean I will try to upload screenshots that we can speak to so we can understand what your intent is, because right now we are a bunch of monkeys pushing buttons in a black box!

It certainly is going to be nice to have the interface working as you intend, and we stand ready to help in whatever way possible. I am delighted with the direction you are taking, but need to understand more.

[nkiesel]

I tried O from git master branch (b9397b3) together with weather_routing_pi from master branch (0724ae2) on 64bit Debian Sid. Everything compiles and installs. I use the same grib files and configurations I used a week ago. However, now all I get is "Failed". Is there any log I can look at or debug I can enable to find out what happens? I would also be happy to run using gdb if you tell me what to look for.

One difference is that last week I was using both compiled without optimization. I could try to do this again and see if this changes things.

[lanceberc]

It would be nice if weather_routing reported reasons instead of just
failure (feature request?) - last year it took some time in the debugger to
find it couldn't handle wind strength above the polar model.

On Wed, Jun 1, 2016 at 8:24 AM, Norbert Kiesel notifications@github.com
wrote:

I tried O from git master branch (b9397b3) together with
weather_routing_pi from master branch (0724ae2
0724ae2)
on 64bit Debian Sid. Everything compiles and installs. I use the same grib
files and configurations I used a week ago. However, now all I get is
"Failed". Is there any log I can look at or debug I can enable to find out
what happens? I would also be happy to run using gdb if you tell me what to
look for.

One difference is that last week I was using both compiled without
optimization. I could try to do this again and see if this changes things.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#40 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ADezs6bzveA-L-s4QOJ-JFfLa7avG9K6ks5qHaQggaJpZM4IbAiA
.

[nkiesel]

I just compiled both O and WR with debug (using cmake -DCMAKE_BUILD_TYPE=Debug ..) and while that works (kind of; see below) I still get "Failed" when trying to compute a route.

Next step could be a git bisect to try finding a working combination again. However, it might be that I inadvertently changed something else (e.g. polars) and that even that code base might not work anymore. I just need a pointer to where to start looking why it fails.

O does not compile in debug mode for me: it gives errors for src/tri.c. I fixed that by making int_max, int_min, and int_is_left_of static functions. Once I convinced myself that this is correct, I will send a pull request to O.

[rgleason]

Norbert i'd like to know how to do a bisect.
I dont think it is your polar, Sean has checking to correct bad formations ( pretty good) .

Maybe we could scan the commits?

I think youd do a pull request to seans repos for wxroting

[seandepagnier]

tri.c will die very soon anyway.

As for weather routing failing... did you configure the boat properly? Did you load a polar? Do you have valid weather data? Does the polar give boat speeds for the wind speeds from the actualy weather situation?

You can post the configuration xml, the boat xml, and any polar files used, as well as grib files, and the issue should be easily reproducible.

[nkiesel]

Attached the files, let me know if you need anything else.

nkiesel.zip

[nkiesel]

git bisect is pretty simple if you have a "good" and a "bad" version and an easy way to test a given version. Let's say you know that the version from 2 weeks ago was working, and now it's broken. Find the commit id for the working version (when in doubt; err on the side of caution and use an older commit that you are sure worked). Then run git bisect start; git bisect good <commit-id>; git bisect bad HEAD. This will pick and change to a commit roughly in the middle between good and bad. Then build as usual and test. If the tested version works, run git bisect good, else run git bisect bad, and repeat the test. At the end you should end with the first commit that failed your test (which will be shown by git). To end the whole bisect, run git bisect reset.

Note that you should do that starting with a clean workspace (i.e. no uncommitted changes).

[seandepagnier]

I don't have the X_362.pol or the grib you used, but the problem is probably that the polar isn't defined for low enough wind speeds for what the current grib is showing. You could try adding a column of 0 for 0 wind speed or something. This is changed from previous versions... maybe I can add an option to allow extrapolation, but I consider this a feature.

[nkiesel]

The polar file already has a row of 0.

I added both the polar and the grib in the attached zip file above. I also attached the polar (renamed to X_362.pol.txt) once more.

Thanks for looking into this!

X_362.pol.txt

[seandepagnier]

I tried it out and the routing works fine. Do you have the latest git?

Sean

On 6/1/16, Norbert Kiesel notifications@github.com wrote:

The polar file already has a row of 0.

I added both the polar and the grib in the attached zip file above. I also
attached the polar (renamed to X_362.pol.txt) once more.

Thanks for looking into this!

X_362.pol.txt

---

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#40 (comment)

[nkiesel]

I use b9397b3 from O master branch, plus my little patch to add 3 extern inline declarations.
I use 0724ae2 from WR master branch.

So yes, latest git. And this worked a week ago (with a slightly older version). Am willing to debug or try patches if that helps.

[rgleason]

Wow, you guys have blown past my skills.

[rgleason]

I'll try some of these again but since I have wxrouting running in debug mode msvc++ why can't I set some break points to determine where it fails?
I need to know where to put them.

Is this a picky msvc++ causing the problem?
True causes failure, instead of true for example.
The grib and polar files are clearly ok and I believe the weatherrouting.xml is probably ok to. I think it is a msvc++ format problem that does not throw an error but fails instead?

Where can I put a break in the main calculation loop (isobars) to be certain the loop is working.

[rgleason]

Maybe it would be quicker to do a git bisect and test? Never done that, but I should learn how. What do you think Sean?

[seandepagnier]

On 6/16/16, mbouyer notifications@github.com wrote:

On Wed, Jun 15, 2016 at 04:10:04PM -0700, seandepagnier wrote:

I tried with C_C34.pol and got perfect routings.

What grib file did you use? Can you post it?

sure
ftp://ftp-asim.lip6.fr/outgoing/bouyer/TLsucMnOnoSYmtRzKDl0e75I4HAjqDApvbb.grb
46.17672
I'm trying to route between -1.45833 and 46.68945 -2.30848
starting at the start of the grib data

I tried with your grib and it works, but not with the wrong config.

If the timestep is above 30 minutes, then the max diverted course
needs to be higher up to 180, or else turn off land detection.

The best thing in this case is to reduce the timestep to 10 minutes.

I cannot print a simple message explaining this to the user because it
depends on all of the settings used, and often the user requests
impossible combinations.

Sean

Manuel Bouyer bouyer@antioche.eu.org

NetBSD: 26 ans d'experience feront toujours la difference

---

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#40 (comment)

[mbouyer]

On Thu, Jun 16, 2016 at 05:37:50AM -0700, seandepagnier wrote:

I tried with your grib and it works, but not with the wrong config.

If the timestep is above 30 minutes, then the max diverted course
needs to be higher up to 180, or else turn off land detection.

The best thing in this case is to reduce the timestep to 10 minutes.

I cannot print a simple message explaining this to the user because it
depends on all of the settings used, and often the user requests
impossible combinations.

I tried changing these parameters but it still doesn't work. I'll try to debug
more what happens in CrossOverRegion.Contains().

Manuel Bouyer bouyer@antioche.eu.org

NetBSD: 26 ans d'experience feront toujours la difference

[seandepagnier]

You could post your weather routing configuration.xml Boat.xml etc to be sure.

Did it really not work when land detection is off?

Is the polar file you are using in a writeable location? It needs to
create the file C_C34.pol.contours so perhaps this is the issue.

On 6/16/16, mbouyer notifications@github.com wrote:

On Thu, Jun 16, 2016 at 05:37:50AM -0700, seandepagnier wrote:

I tried with your grib and it works, but not with the wrong config.

If the timestep is above 30 minutes, then the max diverted course
needs to be higher up to 180, or else turn off land detection.

The best thing in this case is to reduce the timestep to 10 minutes.

I cannot print a simple message explaining this to the user because it
depends on all of the settings used, and often the user requests
impossible combinations.

I tried changing these parameters but it still doesn't work. I'll try to
debug
more what happens in CrossOverRegion.Contains().

Manuel Bouyer bouyer@antioche.eu.org

NetBSD: 26 ans d'experience feront toujours la difference

---

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#40 (comment)

[mbouyer]

On Thu, Jun 16, 2016 at 06:16:27AM -0700, seandepagnier wrote:

You could post your weather routing configuration.xml Boat.xml etc to be sure.

Did it really not work when land detection is off?

Is the polar file you are using in a writeable location? It needs to
create the file C_C34.pol.contours so perhaps this is the issue.

Yes, this is the issue. I'm using a polar installed with the
plugin, so it's in /usr/pkg/share/opencpn/plugins/weather_routing_pi,
which is not writable by regular users.
Copying the file to ~/.opencpn and using this one makes things works.

I guess there's room for an error dialog here :)

Also, I used to see isochrones on the map while the route was being computed
(this is back to the opencpn 4.0.0 days). Now I can't see any isochrones
being displayed, either while computing or once the route has
been computed. The computed route is only displayed when I click "export".

Manuel Bouyer bouyer@antioche.eu.org

NetBSD: 26 ans d'experience feront toujours la difference

[mbouyer]

On Thu, Jun 16, 2016 at 03:48:28PM +0200, Manuel Bouyer wrote:

On Thu, Jun 16, 2016 at 06:16:27AM -0700, seandepagnier wrote:

You could post your weather routing configuration.xml Boat.xml etc to be sure.

Did it really not work when land detection is off?

Is the polar file you are using in a writeable location? It needs to
create the file C_C34.pol.contours so perhaps this is the issue.

Yes, this is the issue. I'm using a polar installed with the
plugin, so it's in /usr/pkg/share/opencpn/plugins/weather_routing_pi,
which is not writable by regular users.
Copying the file to ~/.opencpn and using this one makes things works.

I guess there's room for an error dialog here :)

Also, I used to see isochrones on the map while the route was being computed
(this is back to the opencpn 4.0.0 days). Now I can't see any isochrones
being displayed, either while computing or once the route has
been computed. The computed route is only displayed when I click "export".

BTW you'll find WeatherRoutingConfiguration.xml and Boat.xml in
ftp://ftp-asim.lip6.fr/outgoing/bouyer/

Manuel Bouyer bouyer@antioche.eu.org

NetBSD: 26 ans d'experience feront toujours la difference

[seandepagnier]

l.contours so perhaps this is the issue.

Yes, this is the issue. I'm using a polar installed with the
plugin, so it's in /usr/pkg/share/opencpn/plugins/weather_routing_pi,
which is not writable by regular users.
Copying the file to ~/.opencpn and using this one makes things works.

I guess there's room for an error dialog here :)

Sorry about that, and thanks for testing and reporting it... I will
work on it. Maybe it can just save the contours files in a writeable
location always.

Also, I used to see isochrones on the map while the route was being
computed
(this is back to the opencpn 4.0.0 days). Now I can't see any isochrones
being displayed, either while computing or once the route has
been computed. The computed route is only displayed when I click "export".

Under View->Settings make sure the thickness is greater than 0. The
configuration must be selected (or the eye enabled by clicking the
first column)

[mbouyer]

On Thu, Jun 16, 2016 at 07:01:01AM -0700, seandepagnier wrote:

Sorry about that, and thanks for testing and reporting it... I will
work on it. Maybe it can just save the contours files in a writeable
location always.

Yes, that would the best choise I guess

Also, I used to see isochrones on the map while the route was being
computed
(this is back to the opencpn 4.0.0 days). Now I can't see any isochrones
being displayed, either while computing or once the route has
been computed. The computed route is only displayed when I click "export".

Under View->Settings make sure the thickness is greater than 0.

it is. I also tested different thickness values.

The
configuration must be selected (or the eye enabled by clicking the
first column)

This doesn't change anything. Note that I see the wind barbs corresponding
to the route (and they dissapear/reappear if I uncheck/check in
View->Settings).
Note that I'm not using opengl (I start with -no_opengl), if it
makes a difference.

Manuel Bouyer bouyer@antioche.eu.org

NetBSD: 26 ans d'experience feront toujours la difference

[rgleason]

Have tried the mbouyer files:
Nell.XML.txt
WeatherRoutingConfiguration.xml.txt

TLsucMnOnoSYmtRzKDl0e75I4HAjqDApvbb.grb.txt

Again, Failure. This is futile.

[rgleason]

Sean, Am I building this plugin correctly? When compiling with MSVC++
I have recently git cloned from scratch and am using:
opencpn.lib from v4.2.0
copied opencpnbuildwin.7z files to buildwin directory.
copied cairo.dll, expat.dll, fontconfg.dll, iconv.dll, libpng16.dll, libxml2.dll & pixman-1.dll to the "build" directory.

Build without error, 6 warnings in attached txt.
wxrouting-6-warnings.txt

C:\Users\Rick\Documents\GitHub\o-plugin\s-weather_routing_pi\build>git branch -va
* crossover                39e448c [ahead 31] improve gui slightly
master                   264605a [behind 2] correct cursor calculation for far side of world
remotes/origin/HEAD      -> origin/master
remotes/origin/crossover 23c07cc ui updates and other changes
remotes/origin/master    39e448c improve gui slightly

Computing - never finishes or does it ever start?

[rgleason]

In windows, I would think that C:\ProgramData\opencpn\plugins\weather_routing\data\polars should be writable by the program!!

I since isochrones are set att 1 hour, I changed max diverted course to 180
then ran it. Mark A to Mark B.

Immediately "Grib version not supported" hit OK
Sits there "Computing..."

Set the time period to 20 minutes. there is no messate about grib file.
Sits there "computing..."

[rgleason]

Copied all C:\Program Files (x86)\OpenCPN\plugins\weather_routing_pi\data\polars
polar files to
C:\ProgramData\opencpn\plugins\weather_routing\data\polars
Then made sure the active polar file referenced this directory.

--Does not seem to make a difference. Stilll sits there "Computing..."

[rgleason]

Have git cloned Sean's wx_route branch:master and built.
Downloaded a new grib of the same area.
Using the same weather_routing.xml file.
Have copied all weather_routing_pi/data/polar/ over to
C:\ProgramData\opencpn\plugins\weather_routing\data\polars
and have deleted the boat polar data and then added polars, repointing to
C:\ProgramData\opencpn\plugins\weather_routing\data\polars

The plugin should:

1. Install all boat.xml and polar files to (and load from)

C:\ProgramData\opencpn\plugins\weather_routing\data\  ---> boat.xml files
C:\ProgramData\opencpn\plugins\weather_routing\data\polars  ---> polar files

1. When "Add"ing a polar automatically use

C:\ProgramData\opencpn\plugins\weather_routing\data\polars ---> polar files

1. When Editing/Selecting a boat.xml file from the Config menu, automatically use

C:\ProgramData\opencpn\plugins\weather_routing\data\ ---> boat.xml files

[rgleason]

When working with the polar files, I notice that there is some progress bar down below, and I can double click or something and it re-calculates something. When I look at the polar files there are now Yellow and Red lines showing some kind of cutoff upper limit or lower limit.

When I "Save Boat" and click on "Compute" it says "Computing..." and a window pops up saying "Grib not supported".

[rgleason]

I hit "ok" , "Computing..." continues. Screen goes black. Opencpn stops responding. Have to close abnormally or it just sits there.

Ocpn log file attached.
Ocpn_log_file_last_crash.txt

[rgleason]

Don't seem to be getting anywhere on this, so I quit now.

[rgleason]

Weird.
Opencpn v 4.4.0
Weather_routing_pi Branch: Master
weather_routing_pi-.-39e448-improv-gui-sean-master-win32.exe

All this time, nobody said anything about what version. PissER.

[rgleason]

The GRIB INCOMPATIBLE MESSAGES ARE NOT DETAILED ENOUGH.
EG: "Using wx_routing vxxxx, not compatible with grib_pi vxx.xx"
OR "Using wx_routing vx.x, not compatible with Opencpn v4.2.0" !!!!!

Second Thought: After the message, Perhaps the Plugin should state what it is compatible with???
That would be clear.

Note: I wasted several days of intermittent work, on this problem. I think it is totally worthwhile being explicit.

Also the message does not seem to be very persistant. It comes up at the beginning and if you say OK nothing really happens. YOu can reload the grib or continue I think..

---

Changed to 1 hour time segment route completed!

[rgleason]

Also, I am not understanding the point or reason for making this weather_routing INCOMPATIBLE with OpenCPN 4.2 ? What's new? We changed grib files all ready!

[rgleason]

Sean, you can close this when you wish, other than noting the message just above.
I will create separate items now, since the plugin is now working.
Don't know if norbert or mbouyer have outstanding in this thread.

[seandepagnier]

I didn't make it incompatible on purpose... I can try to work on the messages.

On 6/16/16, Rick Gleason notifications@github.com wrote:

Sean, you can close this when you wish, other than noting the message just
above.
I will create separate items now, since the plugin is now working.
Don't know if norbert or mbouyer have outstanding in this thread.

---

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#40 (comment)

[nkiesel]

tl;dr: thanks for all your work, and please tell us how we can help.

Hi Sean,

first of all, I'm sure I speak for everyone here when thanking you from the bottom of my heart for all the wonderful work you do for this community. Please don't take our criticism and complaints as anything but an attempt to help.

I think part of the problem is that this weather routing is very complex, and many of us do not understand the dependencies between all the parameters and options. This I think can be addressed in two ways: better logging / error messages, and/or smarter selection of defaults.

One concrete example for the latter: I ended up always using the most extreme values for them in the hope that this will make things "better":

• 0 to 180 degrees for Courses
• 180 degrees for Max Diverted Course
• 200 knots for true/apparent wind speed
• 50 meters for swell

I'm not even sure that these values make things better or not. My guess is they are used for clipping the search tree and given I'm running on a powerful laptop (and all my route calculations finish within 2 minutes) I went overboard (I obviously do not plan to sail in 200 knots of wind!). But perhaps this is all wrong and I should instead use other values? But which ones? So what would be really helpful would be for the plugin to advise (e.g. "you are trying to plan a route of 5000 nm, so using 10 minute time steps will take forever!"). Of course even better would be if it would automatically pick the "right" values based on the scenario. Or even dynamically (e.g. "5 minutes" close to obstacles and "5 hours" in the middle of the ocean within steady trade winds), but that seems much more complicated.

So better logging might be the easier answer. Or perhaps a "guided tour" on how you debug such problems. What do you look for in config variables, where do you set break points, what data is a "red flag" (e.g.: "whenever configuration.polar_failed is true, you are in big trouble"). I would be willing to contribute to a FAQ document for this, but right now I'm more likely to spread misinformation than providing real help.

[rgleason]

Sorry Sean,
I don't always know what is going on, or how to get things working, so I get a little verbal sometimes. I'm a monkey with a black box and just a vague idea of what should happen.

I didn't make it incompatible on purpose... I can try to work on the messages.

Yes, understood. No problem I think. Maybe we just call it compatible with v4.4.

I echo norbert's thanks wholeheartedly.
Best
Rick

PS have used new version a number of times now and it seems to be pretty reliable.

[rgleason]

PS: Sean, if you could get a few more messages to help us all, it would be great.

1. Grib - not compatible, not grb, grb2, etc..
2. Grib_pi - not compatible, Use grib_pi X.X with this version of wx_routing.
3. No grib and no climatology - can't do anything.
4. Polar file is not selected.
5. Polar [name] - is screwed up and does not work, remove it.
6. Configuration Settings are screwed up.
7. Boat settings are screwed up.

Sort of like that.
Then maybe a "Reset to original setup" so newbies can learn.

[seandepagnier]

first of all, I'm sure I speak for everyone here when thanking you from the bottom of my heart for all the wonderful work you do for this community. Please don't take our criticism and complaints as anything but an attempt to help.

I already know this.

I think part of the problem is that this weather routing is very complex, and many of us do not understand the dependencies between all the parameters and options. This I think can be addressed in two ways: better logging / error messages, and/or smarter selection of defaults.

Sometimes I get confused as well. I think the biggest issue is when the calculation "fails" but the exact reason isn't clear to the user.

One concrete example for the latter: I ended up always using the most extreme values for them in the hope that this will make things "better":

0 to 180 degrees for Courses
180 degrees for Max Diverted Course
200 knots for true/apparent wind speed
50 meters for swell

This isn't wrong, and as you say will just prevent the tree from getting clipped by these parameters.

I'm not even sure that these values make things better or not. My guess is they are used for clipping the search tree and given I'm running on a powerful laptop (and all my route calculations finish within 2 minutes) I went overboard (I obviously do not plan to sail in 200 knots of wind!). But perhaps this is all wrong and I should instead use other values? But which ones? So what would be really helpful would be for the plugin to advise (e.g. "you are trying to plan a route of 5000 nm, so using 10 minute time steps will take forever!"). Of course even better would be if it would automatically pick the "right" values based on the scenario. Or even dynamically (e.g. "5 minutes" close to obstacles and "5 hours" in the middle of the ocean within steady trade winds), but that seems much more complicated.

How can it know the correct time step? If I really want a 5 minute timestep for a route that takes 5 hours, it is going to be annoying to have the program smarter than it should be try to "help" me. Maybe an "auto" button for timestep, or the timestep starts out at 0 by default (which is invalid) and gets set to a reasonable value once both start and end positions are known. If the start or end changes... it probably shouldn't change the time step though.

So better logging might be the easier answer. Or perhaps a "guided tour" on how you debug such problems. What do you look for in config variables, where do you set break points, what data is a "red flag" (e.g.: "whenever configuration.polar_failed is true, you are in big trouble"). I would be willing to contribute to a FAQ document for this, but right now I'm more likely to spread misinformation than providing real help.

Yes, well it is difficult to make error messages unless they are somewhat cryptic. A route could fail when the north half is bounded by lack of grib data, and the south half cannot be explored because none of the polars define a boat speed for that amount of wind.

As you can see, the route fails when there is no where to explore, and each point in the route can get stopped for various reasons, so there is no clear error message to write other than "Failed" Now maybe you want me to count all the last positions and say something like "300 points failed to propagate due to edge of grib area, 200 failed because out of grib time, 150 failed from constraints (too much wind or...) and 50 because no suitable polar etc.."

Also... I could maybe list the reason for propagation failure for each specific position in the cursor position dialog.

Even then with such a message there are many details missing. So maybe we can step back and try to rethink this?

As for guided tour, I think when people post videos on youtube it can work for this?

[seandepagnier]

Rick,

PS: Sean, if you could get a few more messages to help us all, it would be great.

1. Grib - not compatible, not grb, grb2, etc..

How exactly do I trigger this case.

1. Grib_pi - not compatible, Use grib_pi X.X with this version of wx_routing.

Done

1. No grib and no climatology - can't do anything.

Ok...

1. Polar file is not selected.

Maybe you are confused here

1. Polar [name] - is screwed up and does not work, remove it.

How does the program determine the polar is screwed up? It could do this when you initially add the polar if I knew how.

1. Configuration Settings are screwed up.
2. Boat settings are screwed up.

Again, how does the program know this? Are there particular values that are incompatible with each other that I am not aware of?

Sort of like that.
Then maybe a "Reset to original setup" so newbies can learn.

you can just remove all the polars and choose only one, then delete all configurations and points.

[rgleason]

Sean, Thanks. Very interesting points I did not know.
It's much harder to make good error messages than I thought!
I don't think we want to slow it down by logging all kinds of information....

Ok. to "Reset to original configuration"

1. Remove all polars and choose only one.
2. Delete all configurations and points.
3. Then describe how to set up and get a polar & routing working.
   I think I could handle this in the User Manual ok.

I'm going to close this now. OK?