Forum Replies Created

Viewing 13 posts - 1 through 13 (of 13 total)
  • Author
    Posts
  • in reply to: Wind interpolation #303
    jeff
    Keymaster

    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.

    in reply to: Wind interpolation #302
    jeff
    Keymaster

    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

    in reply to: Wind interpolation #301
    jeff
    Keymaster

    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

    in reply to: TCL Script for use with 'timed' races #299
    jeff
    Keymaster

    [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!

    in reply to: Optimizer Produces Routes That seem to go upwind? #297
    jeff
    Keymaster

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

    in reply to: Win8 Tablet Support #292
    jeff
    Keymaster

    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.

    in reply to: Getting NavMon data into BWR #289
    jeff
    Keymaster

    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

    in reply to: Getting NavMon data into BWR #288
    jeff
    Keymaster

    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

    in reply to: Getting NavMon data into BWR #287
    jeff
    Keymaster

    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

    in reply to: Settings in BWR #284
    jeff
    Keymaster

    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.

    in reply to: Settings in BWR #283
    jeff
    Keymaster

    [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?

    in reply to: Settings in BWR #279
    jeff
    Keymaster

    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.
    in reply to: Structure information about bch file #277
    jeff
    Keymaster

    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.

Viewing 13 posts - 1 through 13 (of 13 total)