Weather Routing

[seandepagnier]

Originally Posted by kubek

Hi,

I downloaded new version of plugins and tested it.

1. I tried to use climatology. It is nice that the new plugin installed all needed staff. Wind , Current and Cyclones works perfect. But if I tried to use air temp or sea temp opencpn is crashed.

I suspect it is because of the way it is using the graphics hardware to interpolate the overlay map between months. Does it crash for any overlay map (wind current, sea depth, lightning etc?) or only air and sea temp?

2. I also tried to use weather routing plugin and version "Most Likely" works nice. Both Cumulative-Map and Cumulative-Calm use a lot of CPU but after 1 hour of computing still nothing is visible. And finally "Avarage" have broken logic and shows like compute in opposite direction that I chose.

See attachments.

Kubek

Ok, I believe you must upgrade the climatology plugin. Most likely is a much better than average anyway. If you could try to backtrace to find why the cumulative ones don't work it would be interesting but I'm still heavily developing the plugin at the moment.

[kubek]

Originally Posted by boat_alexandra

I suspect it is because of the way it is using the graphics hardware to interpolate the overlay map between months. Does it crash for any overlay map (wind current, sea depth, lightning etc?) or only air and sea temp?

Ok, I believe you must upgrade the climatology plugin. Most likely is a much better than average anyway. If you could try to backtrace to find why the cumulative ones don't work it would be interesting but I'm still heavily developing the plugin at the moment.

If I tried to use any of that with "overlay map" it crashed.

I have already downloaded latest version of climatology plugin.

Kubek

[seandepagnier]

Originally Posted by kubek

If I tried to use any of that with "overlay map" it crashed.

I have already downloaded latest version of climatology plugin.

Kubek

Can you give a backtrace so I can determine where it crashed?

Maybe you can sync back to ec1898f1740dfe2af2d9971e0addb46243d067ef and see if it still crashes? If not, maybe try each later commit?

[ChuckSK]

Originally Posted by boat_alexandra

Can you give a backtrace so I can determine where it crashed?

Maybe you can sync back to ec1898f1740dfe2af2d9971e0addb46243d067ef and see if it still crashes? If not, maybe try each later commit?

Here is a patch that fixed the crash for me.

diff --git a/src/ClimatologyOverlayFactory.cpp b/src/ClimatologyOverlayFactory.cpp
index b131aae..7afc329 100644
--- a/src/ClimatologyOverlayFactory.cpp
+++ b/src/ClimatologyOverlayFactory.cpp
@@ -70,8 +70,8 @@
 #endif /* GL_ARB_texture_env_combine */
 
 static int multitexturing = 0;
-static void (*s_glActiveTextureARB)( GLenum texture ) = 0;
-static void (*s_glMultiTexCoord2dARB)( GLenum target, GLdouble s, GLdouble t ) = 0;
+static void ( __stdcall*s_glActiveTextureARB)( GLenum texture ) = 0;
+static void ( __stdcall*s_glMultiTexCoord2dARB)( GLenum target, GLdouble s, GLdouble t ) = 0;
 
 static GLboolean QueryExtension( const char *extName )
 {
@@ -142,9 +142,9 @@ ClimatologyOverlayFactory::ClimatologyOverlayFactory( ClimatologyDialog &dlg )
 {
     // assume we have GL_ARB_multitexture if this passes
     if(QueryExtension( "GL_ARB_texture_env_combine" )) {
-        s_glActiveTextureARB = (void (*)( GLenum ))
+        s_glActiveTextureARB = (void (__stdcall*)( GLenum ))
             systemGetProcAddress("glActiveTextureARB");
-        s_glMultiTexCoord2dARB = (void (*)( GLenum, GLdouble, GLdouble ))
+        s_glMultiTexCoord2dARB = (void (__stdcall*)( GLenum, GLdouble, GLdouble ))
             systemGetProcAddress("glMultiTexCoord2dARB");
         multitexturing = s_glActiveTextureARB && s_glMultiTexCoord2dARB;

Chuck

[seandepagnier]

Originally Posted by ChuckSK

Here is a patch that fixed the crash for me.

diff --git a/src/ClimatologyOverlayFactory.cpp b/src/ClimatologyOverlayFactory.cpp
index b131aae..7afc329 100644
--- a/src/ClimatologyOverlayFactory.cpp
+++ b/src/ClimatologyOverlayFactory.cpp
@@ -70,8 +70,8 @@
 #endif /* GL_ARB_texture_env_combine */
 
 static int multitexturing = 0;
-static void (*s_glActiveTextureARB)( GLenum texture ) = 0;
-static void (*s_glMultiTexCoord2dARB)( GLenum target, GLdouble s, GLdouble t ) = 0;
+static void ( __stdcall*s_glActiveTextureARB)( GLenum texture ) = 0;
+static void ( __stdcall*s_glMultiTexCoord2dARB)( GLenum target, GLdouble s, GLdouble t ) = 0;
 
 static GLboolean QueryExtension( const char *extName )
 {
@@ -142,9 +142,9 @@ ClimatologyOverlayFactory::ClimatologyOverlayFactory( ClimatologyDialog &dlg )
 {
     // assume we have GL_ARB_multitexture if this passes
     if(QueryExtension( "GL_ARB_texture_env_combine" )) {
-        s_glActiveTextureARB = (void (*)( GLenum ))
+        s_glActiveTextureARB = (void (__stdcall*)( GLenum ))
             systemGetProcAddress("glActiveTextureARB");
-        s_glMultiTexCoord2dARB = (void (*)( GLenum, GLdouble, GLdouble ))
+        s_glMultiTexCoord2dARB = (void (__stdcall*)( GLenum, GLdouble, GLdouble ))
             systemGetProcAddress("glMultiTexCoord2dARB");
         multitexturing = s_glActiveTextureARB && s_glMultiTexCoord2dARB;

Chuck

Ahh.. this is a visual studio specific problem. I have found a more elegant solution (I think)

[seandepagnier]

I finally optimized the biggest bottleneck, the coastline detection. In protected waters it was so slow some routings would take a long time. Now here is an example of routing through straits of magellan (in both directions) and taking well under a minute (compiled without optimizations for debugging, when enabled the time would be under 30 seconds) Over 1 million positions on the final graph (the actual number it computes is much higher than this, but most get eliminated)

Notice the difference in the two directions.. the return passage is less than half the time.. and no tacks (compared to 107 tacks going east to west)

[rgleason]

Awesome, can compile and clack for windows in 2 days. Can't wait to try it.

Sent from my SCH-I545 using Cruisers Sailing Forum mobile app

[seandepagnier]

It took me 10 hours to write 10 lines of code. Finally fixed the obscure backtracking problems.

The algorithm not very maintainable, but seems to be working better all the time. I'm finding all sorts of ways I can improve it, but I don't know when or if I ever will.

Maybe someday I can write an improved weather routing that uses the graphics card to perform the calculations (OpenCV)

The biggest improvement in the near future would be localized current data. This would be very interesting in areas with strong currents, but I cannot seem to find this data online, only a few images with vector arrows, but no raw data.

[rgleason]

Weather_routing_pi
I just git pulled again and compiled and the cpack, but first I tried copying the opencpn.lib from 3.3.1824 from yesterday..thinking that might be the problem.
Using the install exe for wxrte I installed it under yesterdays downloaded exe v3.3.1824.

With Climatology and Grib up I click on Weather_routing_pi and the program seems to hang, (Not responding) and cpu use goes up. I wonder if I need to do this in a MSVC++ debug setup with a debug version of the plugin?

Maybe it is missing external files that it needs? Just guessing at this point.

[rgleason]

I looked for WeatherRoutingConfiguration.xml under
C:\o-plugin\weather_routing_pi\build\_CPack_Packages\wi n32\NSIS\weather_routing_pi-0.12-win32\plugins\weather_routing_pi

and it is not in there, but perhaps it is created automatically when the plugin is opened, if it does not exist?

I wonder what else could be hanging this up using CPU usage. It still has not crashed, but I cant do anything except close Opencpn with out finishing, not responding.

[rgleason]

Tried running debug versions of climatology and weather_routing in MSVC++. no dice WxRte just hangs up MSVC

[rgleason]

With Opencpn 3.3.1824 trying Weather_Routing_pi-0.11 Version 0.11 opencpn just freezes and is unresponsive. Have to shut the program down.

With Opencpn 3.3.1824 using Weather_Routing_pi-0.10 Version 0.10 for Opencpn 3.3.1731 you must pick Climatology "Average" and using the 3.3.1824 grib version, the routing seems to be way off, taking a much longer southern route of 4700nm from Newport to Poole England going below the Azores. All other previous routings are shorter 3200nm with a very shallow S and above the Azores. See attached pic.

Has some thing changed in Climatology and Grib to reverse something? This result is not at all intuitive.

[rgleason]

Another thing, the recent one that freezes Opencpn, seems to show up as weather_routing_pi-0.12-win32.exe but is actually version 0.11 in Opencpn 3.3.1824, don't know why. Have installed it.

--Sorry, please disregard this....I was looking at Weather_fax.

weather_routing_pi-0.12-win32.exe freezes Opencpn 3.3.1824

[rgleason]

Compiles and CPACK exe install files of the most recent plugins have been uploaded to Opencpn Beta File Thingies File Thingie 2.5.7 3.3.1824-Plugins directory.
rguser, rgpass

[rgleason]

This is a try at debugging weather_routing_pi.
1. MSVC++ debugging works because I finally copied the necessary files after a fresh git clone and compile, as Pavel pointed out.
2. Copied the debug dll version of weather_routing_pi to my ../opencpn-git/build/plugins directory along with the weather_routing_pi/data files.
3. Ran MSVC++ "Build" and then "Debug > Start Debug"
4. The chart screen came up. I could use it normally. I turned off Opengl and smooth scroll. Opened Grib. Tried opening Weather_routing_pi...nothing happened except eventually "High CPU". There was no Break file for a long time. Evenutally one came up after I started looking for signs of failure in other views/windows.
5. I did this about three times, and the last time I started saving files and one screenshot. Included is call stack, log, settings, etc.