When loading a boat the polar graph remains empty.

[dominig]

OpenCPN 4.8 on Linux-OpenSUSE

• Create and save a boat from a Polar. (the xml is loaded in the home directory where I would expect it) Exit the plugin.

• Reopen the plugin

• Load the boat (The Polar graph remains empty as if the boat was not loaded)

I use the elan340.csv (attached) for that test. I see that the file name for the .csv file is using "_" where I would expect "/". Don't know if that is OK or not. File is located in "/home/dominig/Téléchargements/Elan340.csv"

<?xml version="1.0" encoding="utf-8" ?>

Elan340.csv.zip

[seandepagnier]

I loaded the polar, saved the boat, restarted opencpn, and edited the boat, and the graph is there.

When the "graph remains empty" Is the polar selected? Is the polar in the list?

This polar has a lot of 0 values in it which is not recommended. You are specifying that the boat cannot go at these course/speeds. Maybe useful if you cannot sail at that course for whatever reason.

This will cause the routing to give erratic results.

[dominig]

I just tool that file as an example. Polar files are a mess. But if the plugin believe that the file is not valid, it should reject it, not hang in the middle of a route calculation. Having 0 between 0 and 30 TWA is not surprising, but I agree with you that otherwise, it should be rejected.

[seandepagnier]

Again, does it hang? This means the plugin locks up or crash?

Or does it fail to route? If this is the case, than that is what is expected.

The polar is technically valid. You may never want to sail at 130 degrees, but 150 and 110 are ok. Having zero before 30 TWA should be fine too.

I suppose it could give the user a warning if there are zeros between valid angles.

On 1/23/18, Dominig ar Foll notifications@github.com wrote:

I just tool that file as an example. Polar files are a mess. But if the plugin believe that the file is not valid, it should reject it, not hang in the middle of a route calculation. Having 0 between 0 and 30 TWA is not surprising, but I agree with you that otherwise, it should be rejected.

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/seandepagnier/weather_routing_pi/issues/126#issuecomment-359879491

[rgleason]

Sean, I have found consistently that the plugin does not like TWS columns with all zeros and it does not work well or complete. Therefore I have always removed those all zero columns to get things working.

What am I missunderstanding?

Dominig, the polar files are from many sources. Perhaps we should go through each one and "clean" it up.

[dominig]

I understand that Polar are from varies sources but I do NOT expect most users to know that they have to fix them until told to do so. My proposition would be that if there are lines expected to create issue, we should reject the polar at import. e.g.

• wind value must at least be up to 30kn.
• missing values at 180 degrees.

Having a set of zero value a 0 degrees as well as having no line for it, are both quite logical and should be supported.

When it come to wind max values, if the the one present in the Polar does not cover the predicted wind, then the route calculation should stop on a serious warning. "The selected Polar does not expect sailing in such strong wind conditions". As the error could come from the Polar or from planning a route with a boat on suitable for the predicted weather.

[rgleason]

wind value must at least be up to 30kn. I think one would cause many polars to fail.

[rgleason]

Create and save a boat from a Polar.
(the xml is loaded in the home directory where I would expect it)
Exit the plugin.
Reopen the plugin
Load the boat
(The Polar graph remains empty as if the boat was not loaded)

Dominig, please note. If you have previously installed the plugin, it is necessary to completely remove it and all vestiges using the uninstallweatherrouting.exe and then to check your opencpn.ini file and make sure the weather_routing sections are removed. Then check your user folder where files can be written to, in windows it is programdata/opencpn/plugins and remove the weather_routing folder.

Why do this? Because the plugin now senses if there is a previous installation and does not disrupt that, however we have included new configuration files and Stelian has arraanged to create the proper writeable files and directories in your user folder.

Please do this then, try to "compute" one of the default "Configuratons" provided you have installed climatology and enabled it. Any of those should "omplete." It is a good way of getting new users familiar with the plugin. Also see the pathnames below for working directories.

https://opencpn.org/wiki/dokuwiki/doku.php?id=opencpn:opencpn_user_manual:plugins:weather:weather_routing#weather_routing_setup

Files & Pathnames

It is important that you use this configuration for Windows (Linux use comparable User accessible directories):

Main Path for support files: C:\ProgramData\opencpn\plugins\weather_routing
WeatherRoutingConfiguration.xml: C:\ProgramData\opencpn\plugins\weather_routing
Polar Files (.pol,.txt,.csv): C:\ProgramData\opencpn\plugins\weather_routing\polars
Boat.Xml Files: C:\ProgramData\opencpn\plugins\weather_routing\boat

[dominig]

Rick,

the first line if this bug states "OpenCPN 4.8 on Linux-OpenSUSE" I only use Linux and as I am the packager for OpenSUSE, I have taken care of such issues. Update works out of the box (at least on OpenSUSE :-)

The plugin had, in the past, a bug where the system did try to create files in area where the user had no write privileges, but that is now corrected.

[Sokratte]

I also noticed that with lots of zeros the plugin does not find the optimal route sometimes. I have zeros at windspeed 0, 41, 60 and 120. We want to sail with less than 40 kts of wind. I also have zeros at angle 0 and 70, square-riggers can't do much more. I may even have to set it to 80, will see how high she can go on the next trip from the canaries to germany. https://alex-2.de/

[rgleason]

Sokratte -Martin is this you? Alexander von Humbolt - A square rigger, cool. I think there may some improvements needed to the whole set of polar files. And I am going to have to check each one.

I think Dominiq's suggestions here are good ones. The only concern I have is that many of these polars do not go up to 30 knts. Is there some alternative that would work without having to extend the file? Maybe use the values of the highest TWS wind to extend it up to 30 knots and also (very important) have a Message that the file does not go to 30 knots...

I understand that Polar are from varies sources but I do NOT expect most users to know that they have to fix them until told to do so. My proposition would be that if there are lines expected to create issue, we should reject the polar at import. e.g.

wind value must at least be up to 30kn.
missing values at 180 degrees.

Having a set of zero value a 0 degrees as well as having no line for it, are both quite logical and should be supported.

When it come to wind max values, if the the one present in the Polar does not cover the predicted wind, then the route calculation should stop on a serious warning. "The selected Polar does not expect sailing in such strong wind conditions". As the error could come from the Polar or from planning a route with a boat on suitable for the predicted weather.

[seandepagnier]

If you have a zero in a polar, it is saying that the boat cannot go at that angle. This is maybe useful. I don't understand why people put zero in their polar and expect to sail at a higher speed.

Now maybe, we should allow values that are undefined, and existing entrees can be interpolated.

[Sokratte]

Here is my polar file for the Alex2 based on previous experience, mixed with some pure guesswork:

https://www.dropbox.com/s/gl0480sswwebfz0/Alex2_sail.pol.txt?dl=0

They make sense to me, but do they make sense to the plugin?

I tried many different weather_route experiments with these and similar values. Seems to do the job - more or less. Can I use 0.01 instead of 0 in some fields? This will give better routes. Imagine you wait at a location without sails for the wind to change. If I put 0 the plugin seems to throw some routes away. I grant you there's no fun-factor drifting around with no sails for a few hours, but my intuition is that in some cases it would be beneficial...

I noticed it because sometimes a later departure gives you an earlier arrival, which seems kind of odd :-)

Should I adjust them?

Sokratte = Martin

P.S.:

If you have a zero in a polar, it is saying that the boat cannot go at that angle.

This clarifies things :-)

I just added a second file with motor-characteristics. It changes polars quite frequently around 10 kts of wind at 90 deg angle, sometimes it doesn't make sense to me. Taking down 24 sails takes a few hours :-)

https://www.dropbox.com/s/i5js30k4w8xsi87/Alex2_motor.pol.txt?dl=0

[dominig]

Commercial routing softwares (such as Sailsgrib VR for Android) refuse to route when polar does not cover the forecast wind. Extrapolation is for me not applicable, a good error message is what I would expect. For missing speed a given angle the situation is different and interpolation is logical.

But if for any reason the polar does not respect the expected minimum requirement then an errror message should be issued. Having the route calculation to fail is not acceptable.

Most user, just get the polar from the internet and have no clue of what OpenCPN routing expects as minimum requirements. So if we accept the polar that should mean that we can work with it.

Strong wind being the exception as this is dynamic.

For example, Sailsgrib VR, ask to configure the max wind and will search for a route that respect that constrain (if possible).

[Sokratte]

I think OpenCPN is not to be compared with commercial software. It is far superior and it's free :-) Fixing bugs, reducing hardware requirements (faster algos) and implementing cool stuff is way more important than user experience.

:-)

[rgleason]

Sokratte using 0.1 is a clever idea. The polar looks ok to me. I defer to Sean and Dominig on this.

1. WxRte Polar Editor is very good and makes it very accessible to all.
2. Refuse to route (or stop the route with message) when polar does not cover the forecast wind for that area.
3. No extrapolation, just a good error message about the polar and wind speed.
4. If the polar does not respect the minimum requirements then issue an error message about the polar.
5. Generally the polar should only fail due to strong wind.

I believe that weather_routing searchs for a route that will go around stronger wind than is in the polar. Is this true Sean? Also under "Constraints" there is a setting for "Max True Wind" and "Max Apparent Wind" those should be set at the maximum's desired.

Under "Advanced" there is "Wind vs Current" with integer settings. What does this value represent? I am going to try to consolidate this and get some of it into the documentation. I'll also add an FAQ for Why is the Polar graph empty?

[seandepagnier]

Here is my polar file for the Alex2 based on previous experience, mixed with some pure guesswork:

https://www.dropbox.com/s/gl0480sswwebfz0/Alex2_sail.pol.txt?dl=0

They make sense to me, but do they make sense to the plugin?

It should work

I tried many different weather_route experiments with these and similar values. Seems to do the job - more or less. Can I use 0.01 instead of 0 in some fields? This will give better routes. Imagine you wait at a

If there is a clear difference from 0.01 to 0 then it's likely a bug. Use 0.01 for now, I will look into it.

The polars should support zero speed as well as negative (drifting backwards) when in high winds, it may be impossible to not go a certain direction, but this is not well tested, I will play with it.

location without sails for the wind to change. If I put 0 the plugin seems to throw some routes away. I grant you there's no fun-factor drifting around with no sails for a few hours, but my intuition is that in some cases it would be beneficial...

I noticed it because sometimes a later departure gives you an earlier arrival, which seems kind of odd :-)

Should I adjust them?

This is not normally possible unless there is an adverse current. Is this the case? If not, please post the details (boat polar, grib file, WeatherRoutingConfiguration.xml)

Sokratte = Martin

P.S.:

If you have a zero in a polar, it is saying that the boat cannot go at that angle. This clarifies things :-)

This is the idea anyway, but maybe we find new bugs.

I just added a second file with motor-characteristics. It changes polars quite frequently around 10 kts of wind at 90 deg angle, sometimes it doesn't make sense to me. Taking down 24 sails takes a few hours :-)

https://www.dropbox.com/s/i5js30k4w8xsi87/Alex2_motor.pol.txt?dl=0

If you want to avoid changing sails frequently, you should define an overlap percentage. The polars themselves must define overlapping conditions. So inthis case it won't switch to the other polar until it is 30% speed difference. With 0% it will frequently change sails to get the fastest one.

Commercial routing softwares (such as Sailsgrib VR for Android) refuse to route when polar does not cover the forecast wind. Extrapolation is for me not applicable, a good error message is what I would expect.

So if you load a grib file for a large area which has a storm of 60 knot winds, but your route is on a different side of the ocean where the 30 knot polar will due, it should refuse?

For missing speed a given angle the situation is different and interpolation is logical.

I agree. It should be made to interpolate, but how? Should it interpolate between the next slowest and next fastest wind for that angle? Should it interpolate between the next and previous wind angle for that wind speed? Or both?

In very sparse polars, neither option is possible, but it could do a multi-dimensional fit to use the 3 closest datapoints.

In all cases, the interpolation is typically non-linear to match sailing characteristics. There are some clever functions I can try to use to fit a typical sailboat, but it's not always the best choice. Finally, it could must several datapoints to perform a higher order fit of the data to find missing points.

But if for any reason the polar does not respect the expected minimum requirement then an errror message should be issued. Having the route calculation to fail is not acceptable.

As I mentioned before, I don't know what the minimum requirement should be.

Maybe the best option is the fastest wind in the grib, with an optional "continue" button so the user is well aware that their polar may be the cause of failure?

Most user, just get the polar from the internet and have no clue of what OpenCPN routing expects as minimum requirements. So if we accept the polar that should mean that we can work with it.

Strong wind being the exception as this is dynamic.

For example, Sailsgrib VR, ask to configure the max wind and will search for a route that respect that constrain (if possible).

This option also exists for both true and apparent wind, and avoids editing the polar for this case, but it is basic.

Constraining the boat via the polar, allows you to set the max wind for each wind angle, which is much more interesting, as I do not want to sail against 40 knots, but I can run with it +-120 degrees.

[dominig]

I would certainly not trust a solution that takes negative values. For me when non standard condition are foreseen (e.g. average wind over 40kn), what the boat can do, will more depend of the waves shape than the wind. In that case I's rather would see the routing stopping and giving me a warning message. Some time automation is good for nothing and sea awareness is more advisable.

I do not expect the routing to tell when to use my sea anchor :-)

[seandepagnier]

It is intended that you can make a "sea anchor" polar which defines boat speeds downwind, at possibly only a few angles very near 180 degrees... So I do expect the routing to handle this case if desired.

You are right about waves. This is a difficult subject. Some other software uses wave polars, but this is really just a simple hack that doesn't really handle the situation. Waves have several dimenions (height, period, direction, breaking%, secondary...) so it cannot be represented in a simple polar diagram unless you ignore all but a few variables. For now, wave dynamics are assumed built into the polar which is not really a long term solution.

I think negative values would be a mistake, instead it should not be able to travel upwind, and not be defined for those speeds.

Now there is a new problem I realize.

Currently, I am treating "0" to hold in place, which makes sense logically. Some other programs treat 0 as "undefined" and they interpolate the value. This is technically incorrect and confuses users. I maybe need to detect this, and display a warning.

There are two other cases besides holding in place:

1) Impossible. Boat cannot use this twa/tws. The polars have to be defined in a grid, so far, it's not possible to have undefined speeds in the corners, or even holes. Now this might be really useful in high winds, when the upwind angles are no longer good to use, but the polar covers a wide range of wind speeds and angles. Also in cases where sails shade other sails making certain courses not favorable.

2) No data. The polar doesn't have data for this twa/tws, but it is allowed to sail on it. The value needs to be interpolated from surrounding values if possible.

So I suggest using a negative value such as -1 for "Impossible" and blank like 3;3;;4 to specify "No Data" meaning it should interpolate, leaving 0 as it is. for holding position. What do you think?

[rgleason]

Why not? If the polar fails due to high wind, what is the choice? Maybe the calc keeps going with the boat in one place (with a sea anchor icon left or a high wind icon left) until the winds abate (provided the grib is long enough) and then the routing continues as long as the grib or climatology is available?

Maybe this is impossible if it is seeking a route constrained by wind. I don't know.

[Sokratte]

I noticed it because sometimes a later departure gives you an earlier arrival, which seems kind of odd :-)

Should I adjust them?

This is not normally possible unless there is an adverse current. Is this the case? If not, please post the details (boat polar, grib file, WeatherRoutingConfiguration.xml)

https://www.dropbox.com/s/saee6ne4p2ctdpe/Faster-if-later.zip?dl=0

Is it a bug? No! It's a feature :-)

[lanceberc]

This has been a reported problem for several years. Around here it's common to have forecast winds well above most polars - I sailed down the coast recently with eight hours over 40kts and gusts over 50kts. We certainly don't have good polars for a 1947 wooden schooner that reach that high. On the other hand I didn't expect accurate weather routing through that part of the passage; prudent seamanship was more important than looking at the computer. On the other other hand we didn't put out a sea anchor, we just reefed down and blasted away through the night.

In any case OCPN shouldn't crash, fail silently, or give some obscure error message that can't be looked up when offshore - Weather Routing should be aware that most available polars are limited and occasionally conditions will be outside their predictive envelope. WR's exact result doesn't really matter - most people aren't going to be able to sail to any polar in those conditions. Blaming the polar and crapping out is not a friendly solution - many OCPN users are not rocket scientist enough to adjust the polar matrix at sea (and many can't do it in port).

My fix was to clamp the polar to the speed at the highest wind in the polar but Sean didn't like that (no offense meant or taken). It appears from this discussion that there isn't agreement on a reasonable behavior that will work for most users. Maybe more developers need to get out in high winds more often - it drives home that sometimes this isn't a theory class.

[dominig]

Being a programmer and a sailor, I feel the challenge. The issue is to make the difference between an explicit Naught (0) and an undefined value.

• for undefined value (not entered), for given angle/wind, interpolation from adjacent angles/wind should be used. A common issue as Polar come from various sources and the angle and wind stepping is not standardised.
• "-1" for expressing a not desired angle/wind configuration to force the routing to avoid that angle (if possible) or fail with an error, does not look a good idea to me. I do not like such solution because
  • it's not common practice in Polar file
  • an explicit Naught (0) value would lead the routing to use and other sail angle anyhow (e.g. for boat that cannot sail at real 180°). The trick is to differentiate explicit Naught and non provided values during initial polar parsing. I would show the explicit Naught in red in the table.

Then my my vision is that it would not be stupid to assume

• for wind higher than the max in polar BUT bellow Max wind in routing configuration Reuse Polar max wind value with a user warning message ("Wind condition will be greater than polar maximum")
  • for wind higher than the configure max wind, error message.

[seandepagnier]

Being a programmer and a sailor, I feel the challenge. The issue is to make the difference between an explicit Naught (0) and an undefined value.

for undefined value (not entered), for given angle/wind, interpolation from adjacent angles/wind should be used. A common issue as Polar come from various sources and the angle and wind stepping is not standardised.

So this example of 3;3;;5 has missing data between the ;; and should be interpolated. How exactly to perform the interpolation is not obvious but at least we can agree that it should be done here.

"-1" for expressing a not desired angle/wind configuration to force the routing to avoid that angle (if possible) or fail with an error, does not look a good idea to me. I do not like such solution because it's not common practice in Polar file an explicit Naught (0) value would lead the routing to use and other sail angle anyhow (e.g. for boat that cannot sail at real 180°).

It is not the same. If you use a 0, it means you can hold that position which might be impossible.

Consider a polar which defines only a few speeds downwind in high winds. It is in this case impossible to go upwind, or even to hold position, so you cannot just fill the table with 0, and you cannot leave it blank as we determined this would give an interpolated value.

The trick is to differentiate explicit Naught and non provided values during initial polar parsing. I would show the explicit Naught in red in the table. Then my my vision is that it would not be stupid to assume

for wind higher than the max in polar BUT bellow Max wind in routing configuration Reuse Polar max wind value with a user warning message ("Wind condition will be greater than polar maximum")

We discussed before, and this is not realistic. Boats do not get the same performance at any wind above 20 knots as they do at 20 knots. What would be the point of computing a routing in this case? I think it makes more sense to warn the user, if none of their polars can be used, and this is what "polar failed!" means.

for wind higher than the configure max wind, error message.

It is not an error. The idea of the max wind constraint is to route around these areas if possible. If not possible, then the routing fails.

The routing can fail for many combined reasons. Changing just one of several values in the configuration can in each case allow the route to succeed. For this reason, giving an error message of "wind too high" could be misleading, as changing the timestep, or search angle could be a better clue.

Other than this, I would need specific cases to come up with better suggestions. You might have one example where an error message is nice, but I can find a counter example where the same message is misleading.

[seandepagnier]

https://www.dropbox.com/s/saee6ne4p2ctdpe/Faster-if-later.zip?dl=0

Is it a bug? No! It's a feature :-)

I do not get the same results as you. Not sure why, maybe you used a different polar?

In any case, I think you will find that because the boat has such poor upwind ability (75 degrees) the routing is correct after all. If you leave earlier, the extra tack maybe wastes time. If you decrease the timestep so it can tack more often at some point leaving later should not arrive sooner, unless there are negative currents.

[skipperearly]

sorry to chop in, but just found this thread and read it with great interest. On the Zero value discussion and the high winds, as a user I would expect the highest wind data provided in the polar to get used (without further interpolations!) also in higher wind predictions and have a warning with the results that this was done

And for the ZERO's its a 0 and not a blank, I always find the TWA/TWS 0;0 useless and theoretical. Unless we are racing (in which case we enhance the polars anyhow in great detail) under a certain speed we anyhow use the engine. So I suggest to ignore any Zero's

[seandepagnier]

On 3/15/18, skipperearly notifications@github.com wrote:

sorry to chop in, but just found this thread and read it with great interest. On the Zero value discussion and the high winds, as a user I would expect the highest wind data provided in the polar to get used (without further interpolations!) also in higher wind predictions and have a warning with the results that this was done

Why would you expect this? How would it be useful considering it is not realistic?

And for the ZERO's its a 0 and not a blank, I always find the TWA/TWS 0;0

I am suggesting 0 means not to sail in that direction at that wind speed, and blank means to interpolate from other data but still use that direction.

useless and theoretical. Unless we are racing (in which case we enhance the polars anyhow in great detail) under a certain speed we anyhow use the engine. So I suggest to ignore any Zero's

You may use the engine, but it doesn't mean everyone does. Motor gives different speeds depending on conditions, you need to model that in the polar anyway.

What would ignoring zero achieve? Compatibility with other broken weather routing programs?

Where do these polars with zeros in them come from? Who is making them?

[rgleason]

1. WxRte has an excellent Polar Edit function. Users should get familiar with it. Very easy.
2. User's should know , understand, edit and create polars that they find they need. This is not a case of set it and forget it.
3. Sean writes:

I am suggesting 0 means not to sail in that direction at that wind speed, and blank means to interpolate from other data but still use that direction.

-- I like that idea blank means to interpolate, but still use that direction. -hope it will work.

What would ignoring zero achieve? Compatibility with other broken weather routing programs? Where do these polars with zeros in them come from? Who is making them?

--I believe the zeros are coming from many of the polars that I collected that are in the polar directory. It is my intent to make each one fully compatible with wxRte and in the standard file format. For Opencpn WxRte is that with "pol" or "csv" or "txt" or does it matter? --It's your choice Sean.

--I am going to follow your instructions:

If the value should be something greater than 0, and it is for lack of data, then yes, remove it. If it is 0, because the wind is too high, leave it for now.

Most likely I will change the logic so that 0 will mean not to propagate in that direction. If you really mean to hold position then a very small value of .01 can be used.

On 3/14/18, Rick Gleason wrote:

Sean, regarding checking all the existing polars in the polar folder. Should I remove all columns that have all 0 entries?

OK?

[skipperearly]

You may use the engine, but it doesn't mean everyone does. Motor gives different speeds depending on conditions, you need to model that in the polar anyway. I was purely suggesting to remain pragmatic and therefore offer the user a tool which is of practical use. Theoretically you are of course right. It boils down to what the WR should be used for. From the first look, with the integration to climatology (which I find a great idea btw) I would see long/medium distance sailors as the prime target users, not regatta freaks. This group will most definitely use the iron Genoa when too slow. It's o.t.t. to ask for engine-polar, next also a waves-polar, a crosswaves- polar .... All polars with their inherent (gu)estimations.

One more remark ref the Zero's: where they come from is not relevant, often they are a result of format conversions between different platforms. To give them significance for 'not propagate in this direction' is not logical, as irrational as the 'course relative to true wind ' in the advanced config tab. If the polar give values for e.g. 30dg but 'from' is set to e.g. 45dg what does this mean? Users will expect to always use the polar values to find the optimal route - unless the SOG is too slow.

Where most WR programms fail is not in the precision of the model and their calculation but in the usability (intuitive use!) and their tolerance to incomplete data. I believe this provides the biggest opportunity for the WR-pi. Sorry Sean, but that's my experience/opinion.

[rgleason]

..To give them significance for 'not propagate in this direction' is not logical,

Skipper early, please explain this statement further, we need to know what you are assuming and what you think will happen., a screenshot of the example polar with your explanation might help.

....as irrational as the 'course relative to true wind ' in the advanced config tab.

You should try to understand what this setting is for before you make such statements! This is for calculations only, see the Information Tab

"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."

Now please explain your first statement. I believe there is a misunderstanding.

[skipperearly]

_> ..To give them significance for 'not propagate in this direction' is not logical,

Skipper early, please explain this statement further, we need to know what you are assuming and what you think will happen., a screenshot of the example polar with your explanation might help._

Let me try to explain: Best probably to distinguish where Zero values could be in the polar

• somewhere in between the other values : I trust e.g. TWA60dg/TWS8kt = 0 will not want to suggest never to go there with the model! - this is obviously rubbish and should be ignored.
• row with low TWA: they could be interpreted as 0,0001 values as per earlier posts, they are maybe no go areas but it is already transparent to the algorithm
• column with low TWS: for the algorithm they could again be seen like 0.001 but to give them "significance for not propagation" is just wrong. The result is either very slow or as I suggest: use engine.
• row with very high e.g. 180dg TWA : these values, if provided, are anyhow much lower and will not provide optimal routing. - but agree, this could be the only case where e.g. TWA 180 should not be propagated, however 0.0001 would give the same result.
• column with very high TWS: what should a zero column mean here? avoid areas of too high wind? - but this is not a polar issue its a grib restriction for the algorithm. So to conclude: a Zero in the polar hardly ever makes sense and could safely be ignored. If the user for some theoretical or other miraculous reason wishes to give significance to the Zero then he should enter 0,0001 and enjoy the results.

[seandepagnier]

If it does different things for different cases of 0, it becomes very confusing. I think it should always treat 0 the same way, or issue warnings if there really are special cases.

rubbish and should be ignored.

Why is there rubbish in the polar? rubbish in = rubbish out This is true for all weather routing programs. Don't expect good results from broken polars.

What does ignore mean? Interpolate from other values?

Some polars have a wind direction of 0 row. It may be filled with 0. Sometimes the next upwind angle (say 45) has valid speeds. Due to interpolation between wind angles, this makes it possible to sail at 20 degrees off the wind. In this case, the 0 should not be used the way it would be for other columns (ignored) but should block. By block, it means you cannot use any angle between it either (all interpolations are blocked)

I can agree that .0001 can be used to basically stop. But this is different from not propagating. This will again try to propagate at the next time step. This could mean a very different result if you are trying to avoid only beating closer than 60 degrees above 30 knots. Maybe also you want to avoid beam seas above 40 knots as well, but angles of 50-60 or 120-160 are ok.

Using a value of .0001 won't work, as technically you cannot "hold" position any more easily than just sailing on a useful course. The algorithm will start sailing again when the wind drops.

Using a value of 0 to indicate that you cannot sail on this condition could have the same effect as hitting a boundary or land, and stop propagation. This could be very useful, and the routing will try to find other ways to reach the destination.

It makes most sense to me, to use 0 to indicate "impossible" but if not, how else can we implement it? Could the value of "-1" be used instead? Would this be more compatible to other routing programs? Why do people frequently make broken polars full of 0? Why not simply leave fields empty if data isn't available

I suggest: use engine. The effects of the engine must be incorporated into the polar or polars used. Otherwise the weather routing cannot correctly predict the route.

I never used an engine and sail all over the globe. Saying to "use engine" is in my opinion the wrong answer and I consider it cheating. It has nothing to do with the issue of 0 in polars.

On 3/17/18, skipperearly notifications@github.com wrote:

_> ..To give them significance for 'not propagate in this direction' is not logical,

Skipper early, please explain this statement further, we need to know what you are assuming and what you think will happen., a screenshot of the example polar with your explanation might help._

Let me try to explain: Best probably to distinguish where Zero values could be in the polar

• somewhere in between the other values : I trust e.g. TWA60dg/TWS8kt = 0 will not want to suggest never to go there with the model! - this is obviously rubbish and should be ignored.
• row with low TWA: they could be interpreted as 0,0001 values as per earlier posts, they are maybe no go areas but it is already transparent to the algorithm
• column with low TWS: for the algorithm they could again be seen like 0.001 but to give them "significance for not propagation" is just wrong. The result is either very slow or as I suggest: use engine.
• row with very high e.g. 180dg TWA : these values, if provided, are anyhow much lower and will not provide optimal routing. - but agree, this could be the only case where e.g. TWA 180 should not be propagated, however 0.0001 would give the same result.
• column with very high TWS: what should a zero column mean here? avoid areas of too high wind? - but this is not a polar issue its a grib restriction for the algorithm. So to conclude: a Zero in the polar hardly ever makes sense and could safely be ignored. If the user for some theoretical or other miraculous reason wishes to give significance to the Zero then he should enter 0,0001 and enjoy the results.

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/seandepagnier/weather_routing_pi/issues/126#issuecomment-373897425

[rgleason]

I have quickly checked about 2 dozen polars and they all look fine to me. Training, for manual.

POLARS are IMPORTANT You must learn to control and understand them. Here are some example screenshots of BlockIsland40.pol and BlockIsland40-BAD.pol Can you determine how to fix BlockIsland40-BAD.pol with the Polar Editor using the Grid Tab and Dimensions Tab?

This polar is designed and formatted correctly. There are several different styles that are acceptable.

This BlockIsland40-BAD.pol polar has several things wrong that can be corrected easily in the Grid Tab. There are a number of values that are incorrect and causing polar lines to cross. This is indeterminate and impossible to compute and will cause bad results. Use the Polar Editor Grid Tab to correct these entries. Refer to the Polar Diagram to assist you visually. When you have finished all the polars lines should not cross and should be gradual curves. You will find that the easiest way to fix TWS22 colmn is to make TWA75 into a zero. Now there is a column of Zeros at TWS22. To remove this use the Dim Tab.

This same polar can also be fixed using the Dim Tab to correct issues with Columns or rows of 0's or the grid can be expanded.
Remove the TWS22 Column. See what happens to the polar diagram. Remove the TWS0 Column. See what happens to the polar diagram. Remove the TWA0 Row. See what happens to the polar diagram.

The two polars are zipped and attached below. (Note to Sean, I tried to insert an incorrect TWS value of 11 and it crashed Opencpn.)

BlockIsland40.zip BlockIsland40-BAD.zip

[rgleason]

Sean, I still have work to do on the polars, checking them, but I now have about 60 other polars to add to the polars file.