Weather Routing

[kantafig]

Regarding weather, this is interesting....


https://www.thedubrovniktimes.com/ne...t-in-dubrovnik

[rgleason]

Dear Sherry,
I will try to respond. Some of your questions require more research & testing.

Originally Posted by SoggyPaws

[Edited down]

I am running 2 systems on Windows 10... my old 4.6.8 with WR 1.12.1 and "standalone (USB Stick-based)" 5.0.x with 1.13.1.

I have 2 issues:

1. Neither version seems to recognize an OSCAR current GRIB. (older versions did recognize the OSCAR current files).

2. The 5.0 version running "standalone" off a USB stick using the same weather files, weather routes and polars, ends up routing over land. The 4.8.6 version, with the same weather, polars, and route does not...

..I now have the hi res files in 3 or 4 places, yet the Weather Routing is still routing over land. It may be because my O5 is still running off a USB stick (I don't trust it for my main version yet).

Where does Weather Routing expect the high res coastal outline files to be? exactly (what INI file parameter, for example)
Why doesn't Weather Routing recognize my 3 day old OSCAR grib file? (for currents).
Sherry s/v Soggy Paws

1. Sea Current Gribs

I am familiar with OSCAR. I believe this data source has been incorporated into new NOAA models and is now RTOFS which is intended to be a more comprehensive model. Unfortunately, it does not yet incorporate the effects of Coastal Tidal Current in large bodies of water such as the Gulf of Maine, etc. but they are working on improvements. There are other good sources for "current" in Europe as well. Additionally there are new satellite generated current models that are more immediate, but are discontinuous (kind of banded) that offer greater specific detail, which are not available yet.

The reading of gribs is dependent on gribs_pi and both v4.8.8 and v5.0 gribs_pi read RTOFS files which have sea current and sea temperature. The grib_pi in v5.0 is more advanced in this respect. I have tested both v4.8.8 and v5.0 grib_pi just now and RTOFS seems to work fine. I would suggest that you try downloading that version using the grib_pi interface.
Incidentally, it is useful to know how to load two grib files (one RTOFS and one GFS, for example). For that please see the documentation.

I have not yet tested wx_routing for Ov50 with this file, but will do so.

Alternatively, do you have another specific source that you use, and can you provide a link or upload a small file for testing? I don't have any Oscar files in my grib downloads anymore, for testing.

Some Other Sources

• https://opengribs.org/en/gribs
• About Oscar some time ago OCEAN SURFACE CURRENTS
• Grib Forecasts - Frank's page Listing of GRIB and other objective forecasts - Franks-Weather - The Weather Window

However for grib_pi, RTOFS is the only "current" grib data I know of.

PS Just found Oscar https://podaac.jpl.nasa.gov/dataset/...4_OC_third-deg
Oscar surface currents https://www.esr.org/research/oscar/o...face-currents/
Soggy Paws Where do you download those from?

2. High Res Background Map

Please review https://opencpn.org/wiki/dokuwiki/do...background_map
I believe this is clear. Note "Older versions"

A portable version creates its own dedicated opencpn.ini file on the USB stick. Edit that ini file to point the high res to the appropriate accessible directory.

https://opencpn.org/wiki/dokuwiki/do...background_map

I would use the chart downloader in your portable version or do it manually.

[rgleason]

Also under opencpn.ini
[Directories]
BasemapDir=C:\\Data-Dart\\Chart\\GSHHG\\
For example.


Also my copy of Opencpn v4.2.1 does not recognize gshhs files located in places other than
C:\Program Files (x86)\OpenCPN 4.2.1\gshhs


I do not know when this was changed to recognize

[Directories]
BasemapDir=C:\\Data-Dart\\Chart\\GSHHG\\


and my directory

C:\Data-Dart\Chart\GSHHG

[rgleason]

David's page in Starpath Resources is more explicit about ocean currents


https://www.starpath.com/currents/




Interesting comparison to Rtofs to HF Radar
http://davidburchnavigation.blogspot...sts-to-hf.html

[SoggyPaws]

Thanks very much for your replies.

The OSCAR GRIB can be requested via email by emailing query@svsarana.com and this is exactly what I used this week to request my OSCAR file.

Oscar:7n,03s,125e,145e

When NOAA removed the easy access to OSCAR, the original saildocs query quit working. But Eric of svsarana.com set up a download mechanism to still serve the queries. It seems to work, and the current data displays in the sailmail grib file viewer.

RTOFS vs OSCAR--I've never been able to resolve that question in my mind. I have googled many times to try to find whether anyone has scientifically validated the data one versus the other (and the answer might vary depending on where in the world you are). When I have gotten both and compared the two, the currents they predict are VERY different, and in my part of the world (western Pacific and SE Asia), OSCAR seemed to fit better. I hadn't thought of trying to use RTOFS and at least see what happens in wxroute. I will do so today.

We are getting ready to make another 36 hour hop from Indonesia to the Philippines (where there is almost no human knowledge injected into the weather forecasting), but 2-4 knots of current in some places. I will play with it some more on passage. I have downloaded and saved the docuwiki on the background map (I had looked at the help file installed with O and couldn't find anything very useful). Thanks for the specific links.

Will be offline for about 2 days while we are on passage, but will check back here when we're finally in the marina with good internet.

Again, thanks Sean and everyone for a very useful tool for planning passages and evaluating weather!!

Sherry

[rgleason]

I have tested OSCAR files with ov500 and grib_pi and confirm that they are not working properly. The file is loaded and the file name appears in the bottom left, however the vectors are not displayed and the current at the cursor is not shown.


I have made a Github Issue here, if you have anything else to add please do so.
https://github.com/OpenCPN/OpenCPN/issues/1484

[SoggyPaws]

Actually, the OSCAR files DO load OK if you only load the single OSCAR file. The problem is (both in O5 AND in 4.8.6) is when you try to load 2 GRIB files to run a weather routing. I have tried changing selection order, etc, but it doesn't seem to matter. No current info is shown either via the cursor or on the chart.

Below is my OSCAR file in O5, just now.



I will try to follow your link and add my comment in directly.

We have made it safely to the Philippines! If only the actual weather faintly resembled any forecast I had, it would have been a beautiful trip!

Also, I think I got the hi res coastline files installed in the right place in my Portable OpenCPN.

Sherry

[rgleason]

1. I download an Oscar and it only contains a "current" checkbox and the currents do not show and are not shown at the cursor. --At least in the first file that I tested.


2. You stated: "Neither version seems to recognize an OSCAR current GRIB"
What am I supposed to think you meant? You must provide greater information and clarity or you will waste our time. Also screenshots at the beginning do help with context and understanding.


Thanks for the clarification.

I downloaded another one and it shows currents at least.
Next I will try the two grib files.

[SoggyPaws]

I found the problem and noted it on your bug report in GitHub. It has to do with the dates of the data on the two files. (repeating here for other wxroute users)

The problem appears to be that OSCAR current data is historical data, and typically the wind data is a forecast covering today and into the future. With my grib_pi settings set to "start at the nearest forecast to the current time" (this is set in Preferences in Settings/Plugins/Grib_Pi), when you load both a wind GRIB and the OSCAR current GRIB, the current file is there, but doesn't show because it's date is (typically) for yesterday or before. Clicking on the drop-down showing the dates of the "forecast" and selecting the oldest one, the current info shows up.

The problem is informing wxroute that there is (older) current data, in addition to newer wind data, I think.

In the screenshot, you can see the OSCAR file (file date 14-Nov) has loaded current info for 11-Nov. And the wind data (file date also 14-Nov) forecast starts 14-Nov. So if you have the date selected as 14-Nov, the current info will not show. Change the selected date to 11-Nov, and you can see current, but not wind!

[rgleason]

Thanks, I am going to close that reported Issue on github now.


PS: By the way. Welcome Back! Do you have a blog or website?

[SoggyPaws]

In closing the Bug report, you said "Weather Routing cannot be expected to predict what the current will be from what was."

But, I have the "Last Valid if Data Deficient" checked. Would this not seem to expect a several day old current file to extend to the current routing? It does, for wind, does it not?

The question is, does the grib_pi / wx_route interface permit wx_route to know there are 2 data sets with different "last valid" dates? If it DOES, wx_route should handle this case, IMHO.

I know that using RTOFS would be easier for everyone , however, the actual current we experienced on this last passage matched the 3 day old OSCAR data much better than the RTOFS data. I have been using "currents only" for Climatology in the wx_route settings to get some useful approximation of current (which is flowing 1-3 knots in places around here, so is significant to get right for passage planning/timing).

BTW: Website: http://svsoggypaws.com blog https://svsoggypaws.blogspot.com

[did-g]

Originally Posted by SoggyPaws

In closing the Bug report, you said "Weather Routing cannot be expected to predict what the current will be from what was."

But, I have the "Last Valid if Data Deficient" checked. Would this not seem to expect a several day old current file to extend to the current routing? It does, for wind, does it not?

IIRC this option is not used for current because It doesn't make sense for tidal current.
A work around would be to use command line tools like grib_set or cdo and create a new record with a false date.


Otherwise and not out of the box at
Copernicus - Marine environment monitoring service lio/access-to-products/

there's some current data.

[rgleason]

I believe you are correct about current data not using Last Valid.


I used to have a Copernicus account. It is a great resource. If you could guide us to how to download reasonable current files that are predictive from here it might be a good resource.


The other thing that could be done is to mess with the grib file, change its time and time span and duplicate it across the time period where you need it. I don't know enough about grib to do that but would be interested in how.


Maybe we could make a utility that does that easily.

[did-g]

Originally Posted by rgleason

I believe you are correct about current data not using Last Valid.

I used to have a Copernicus account. It is a great resource. If you could guide us to how to download reasonable current files that are predictive from here it might be a good resource.

Downloading is easy, convertion to grib is a little harder.
I made a grib subsetter for UK MOC
MyOcean Viewer

(http://resources.marine.copernicus.e...UM-001-024.pdf )

at:

https://www.grib-downloader.tk/grib/smoc?x=125&X=145&y=-3&Y=7

with x longitude min, X longitude max, y latitude min, Y latitude max
only total u et v available, update at 13 H UTC.

I double checked around Manche area and Guinea Gulf. seems sensible, but there's up to 180 ° diff with SoggyPaws' oscar file!

Originally Posted by rgleason

The other thing that could be done is to mess with the grib file, change its time and time span and duplicate it across the time period where you need it. I don't know enough about grib to do that but would be interested in how.

Maybe we could make a utility that does that easily.

cdo (http://code.zmaw.de/projects/cdo) already can with setdate and copy operators.

[rgleason]

Dave just merged didier's PR

https://github.com/OpenCPN/OpenCPN/p...ent-2821942811
so "When exporting a track to route use the right time for departure, ie UTC"
in the next release.