[jeff]

Interpolation is linear along the three dimensions of lon, lat, and time. The wind is calculated by interpolation for lon/line/time at each routepoint, and along the leg between routepoints every t hours, where t is the time resolution.

[jeff]

Thanks for your answer.
I am a particular user because I don’t sail.
I want to use your tool with students.
The GRIB files I have are 0.5 ° by 0.5 °, a geographical interpolation is preferable, but for ease of understanding, I would have liked no temporal interpolation between the three hours data that I have in a GRIB files.

What kind of geographically interpolation do you use ? Linear or spline ?
If I understand correctly, between two routepoints, there is no temporal interpolation (and geographically ?) and the wind is recalculated for each routepoint with a interpolation between the time and time+3 hours. Is that correct ?

Thank you, I’ll try to think about how to use it knowing these facts.

Stephane

[jeff]

Glad you find the tool useful.

The wind is always recalculated (through interpolation) at routepoints, whether they are user-created marks or generated by the optimizer. There is no way to disable this. The time resolution parameter applies when the vessel is traveling along long legs between routepoints.

I’m curious – would you prefer not to have interpolation happen at routepoints? I can understand that.

Jeff

[jeff]

[From User msanderson]

Thank you for this. I’m using Bluewater Racing as I cruise my boat throughout latin america. I am now using this tcl script to help me pick a departure time. It seems to be working great. I’ve edited my polars to assume that for winds less than 4 kts, I’m motoring. Thanks again!
Cheers,
Mike
s/v Wanuskewin
Catalina 42 (in full cruising mode, jerry jugs, davits, dive compressor on deck, the works!

[jeff]

See the question “Optimizer makes upwind routes” in the FAQ

[jeff]

There is no direct support for the win8 GPS interface, however you can check out Centrafuse Localizer for an app that will create a virtual COM port providing data (in NMEA0183 format) from the tablet GPS. Then you should be able to access that data via the instrument manager in Bluewater by opening that virtual COM port.

[jeff]

Hi Terry

As you can see been away long time. However may have a solution for your problem.
Try downloading following GPS gate client .
You wil be able to distribute your GPS signal to various “virtual” com ports.
http://gpsgate.com/support/getting_star … ate_client

Rgds Tempest

[jeff]

Hi Tempest,
Yes I have used VportA in NavMon and in the monitor window data can be seen flowing.
The setup in the instrument manager in BWR is very simple and I have tried all the ports listed in NavMon without success!
I’m at a complete loss now as to what to try next?

Thanks
Terry

[jeff]

Terry oN

Just to check , have you used virtual port A in Navmon PC as this should work with BWR.
Otherwise have a look here how to hook up on AGage site.

How to get your GPS data into Bluewater

it is not a BWR problem as i can hook up nicely.

Rgds
Tempest

[jeff]

You’re right, Reverse Isochrones are required for the sensitivity data. Some navigators like to use reverse isochrones to help understand how flexible the solution is, but I think the sensitivity is more directly helpful.

Computing the reverse isochrones requires a second run of the algorithm, so it doubles the total time of the optimization run. So absolutely turning them off will save time.

[jeff]

[User Zembu]

Thanks Jeff for your answer. BWR is working well for me (In Sailonline).

I’d like to ask another question – reverse isochrones – it appears that the only reason for setting to use these is so that we can get the sensitivity – is that correct? Is there any other benefit in using them? If we don’t use them I expect the optimisation will be faster, would you agree?

[jeff]

Thanks for the positive feedback!

Reducing Distance and Time Resolution will improve accuracy but run slower.

For mid-latitude regions (60N to 60S) there’s little point in reducing Distance Resolution less than 60 NM.

I see people like to go for small time resolutions but I’m pretty happy with a 2 hour value. On the open ocean, winds don’t vary much within that time frame. Near geographic features, or during frontal passages, winds do change rapidly, but GriB forecasts are also less accurate for micro or meso scale phenomena. A useful strategy is to have a look at how the winds are varying over your race. If they are varying a lot, then go for a smaller time resolution.

Reducing Grid Size is the best way to improve accuracy but the time penalty is the square of the inverse of the reduction, which is to say: if you reduce the grid size by a
factor of 2, the running time will increase by a factor of 4. I usually start out with a 60nm grid size and then reduce it if I want to fine tune my route, down to the smallest value I can stand waiting for.

What I say about Max Range is correct. Reducing max range artificially limits the search space, which makes things go faster, but eliminates the (theoretical) possibility of finding the fastest route.

I don’t worry too much about these parameters, because they don’t seem to make much difference in the optimal route. If you find that not to be true, I would be interested to see examples.

• This reply was modified 3 years, 8 months ago by jeff.

[jeff]

Sure: BCH is an abbreviation for “binary chart”. BCH files are constructed from the GSHHS chart data, which contains shoreline points in five increasingly detailed files, the most detailed of which is about 90Mb in size. Each BCH file contains the data from the corresponding GSHHS chart, recursively partitioned into a 2-dimensional tree to facilitate fast queries for the shoreline points contained in an arbitrary rectangular query area. The little window on the bottom of the display shows you which GSHHS file was used and how many points were retrieved for display in your current window.

The levels of detail, each in a separate file, are “crude”, “low”, “intermediate”, “high” and “full”. This is determined by the GSHHS consortium, not Bluewater Racing.

Bluewater Racing automatically chooses the most detailed BCH chart it can for display, subject to the constraint that not too many points are drawn in the current window. Right now, the constraining number of points is hardwired into the program. This is purely a time consideration, so that the program doesn’t spend too much time drawing points. You can override automatic selection by opening the preferences window and changing the chart setting from automatic to one of the five levels of detail files. This will force the program to only display shoreline data from that level of detail. Warning: if you force the program to use the full data set, and then zoom out so that the entire globe is displayed, you will wait a very very long time for the chart to get drawn, because there are some 10 million points.

[Author]

Posts