Incorrect Tide & Currents Shown

[davidjade]

I'm new to OpenCPN but fairly technical. I set up the tide dataset using that latest data file from XTide (harmonics-dwf-20121224-free.tcd). I can see current & tide stations and bring them up but the data does not match what XTides shows. As an example, Thatcher Pass (San Juans, US waters) for Sept 8th, 2013:

OpenCPN shows (transcribed from the current window):
05:00 00.56 kts 300
06:00 00.52 kts 300
07:00 00.33 kts 300
08:00 00.07 kts 300
09:00 00.27 kts 075
10:00 00.59 kts 075
11:00 00.78 kts 075
12:00 00.81 kts 075
(shown timezone Z-07:00)


XTide shows:
05:00 AM PDT 0.391794
06:00 AM PDT 0.563740
07:00 AM PDT 0.524507
08:00 AM PDT 0.361093
09:00 AM PDT 0.155659
10:00 AM PDT -0.163175
11:00 AM PDT -0.587176
12:00 PM PDT -0.821660

Again, both programs are using the same harmonic dataset from Xtide. In OpenCPN I have removed all other datasets.

It is not just this one current/tide station, I am finding that all of them are off a little bit. Even though this is very obvious when looking at the raw data if you compare the graphs they are in fact very similar but what you find is that the major events (high, low, slack) are all shifted in time in OpenCPN by a small amount like the graph (and data) are being stretched.

I can also see this error when hovering over the graph with the mouse as the major high, low, slack events, are all off by about 45 minutes.

Has anyone else seen this? Is there some place I should officially report this so that it can be addressed?

thanks,
David

[nohal]

David...
Thanks for the report, please file it in the bug tracker at OpenCPN::Tracker All Projects: Tasklist

Pavel

[bdbcat]

David....

Thanks for the report.

I'm confused, I guess. In your post, you show a current velocity report from OCPN, and a tide level report from XTide.

May we see a tide level report from both programs at the same location, with the same harmonic set, please?

Thanks
Dave

[davidjade]

Both of those examples are current velocity reports for Thatcher Pass, which is just one of the places where I am seeing the problem.

I had originally thought that tides were skewed as well but it seems that they match close enough. Here is the tide reports for Armitage Island, Thatcher Pass for today which seems to match.

OpenCPN:
04:49 00.83 ft LW
13:37 06.18 ft HW
17:48 05.62 ft LW
22:05 06.64 ft HW

XTide:
04:49 AM PDT 0.83 feet Low Tide
01:37 PM PDT 6.18 feet High Tide
05:47 PM PDT 5.62 feet Low Tide
10:04 PM PDT 6.64 feet High Tide

Sorry for the misleading title as it appears that it is only currents that are affected.

David

Ps. I reported this as FS#1098 in the bug tracker and have noted that only currents seem affected.

[HappySeagull]

bah, humbug. the xtide dataset is not that great anyways. Slack water according to the NOAA is at 1030

Tidal Current Predictions

O's own dataset is better

[cagney]

Reference Station :
Hansweert, Netherlands



Thomas

[bdbcat]

Thomas...

That is a bug, I guess. I'll wager that you have two or more tcd datasets loaded at once, XTide and some Euro set in this case.

This is an internal confusion over tcd file set indices.
I think I remember suspecting that this would happen, but rationalized back then that most users would only have one tcd file loaded, for their local area. Then, promptly forgot about it

On the list....
Dave

[bdbcat]

Folks...

It seems to be a problem with subordinate current stations only.

See, for instance, Rosario Straight Current (which is a Master Station)
longitude: -122.7800
latitude: 48.4583

Can we agree that Xtide and OCPN produce results near enough to equivalent for this and other Master Stations?

I will continue to investigate subordinate station math.

Dave

[bdbcat]

davidjade....

Found and fixed the bug with subordinate tide/current stations in Binary TCD file decoding. Fix is committed to github. Will be in next Beta, or could be built from source now.

Please note that our results differ from XTide results in very small amounts, usually a few minutes, regarding the times of slack water. This is due to the older algorithm used in OpenCPN compared to the most modern XTides implementation of subordinate station time offset calculation.

With this change, I think our results are now good enough to navigate with. Do you?

Cagney:
I have not yet fixed the multiple TCD file index confusion you identified. Its a big job, but it goes on the list.

Thanks to all
Dave

[cagney]

Dave

That is no problem in practical navigation as only one .tcd file is needed at any given time depending on which side of the North Atlantic you are navigating. But for armchair sailing and testing the error pops up.

Thomas

[davidjade]

Originally Posted by bdbcat

davidjade....
With this change, I think our results are now good enough to navigate with. Do you?

I just built the master branch and can see the fixes. Here's what I now get from OpenCPN for 9/8/2013 Thatcher Pass:

05:00 0.37kts 300
06:00 0.56kts 300
07:00 0.52kts 300
08:00 0.32kts 300
09:00 0.05kts 300
10:00 0.30kts 75
11:00 0.62kts 75
12:00 0.80kts 75

And to recap, Xtide's:

05:00 AM PDT 0.391794
06:00 AM PDT 0.563740
07:00 AM PDT 0.524507
08:00 AM PDT 0.361093
09:00 AM PDT 0.155659
10:00 AM PDT -0.163175
11:00 AM PDT -0.587176
12:00 PM PDT -0.821660

Definitely better. Close enough I suppose but if I were really trying to nail slack time, both Xtide & NOAA put that at 9:36am that day and OpenCPN puts it at 9:06am. That's a 1/2 hour off - more than a few minutes and while not a problem here maybe so at other locations?

As a developer, I am curious on the reasons for the differences and why OpenCPN isn't/can't use the newer calculations from XTide's code. If it's a matter of just porting changes I could maybe look into that.

As a sailor, it would be handy to have them match as other tools I use tend to align with those.

Thanks for the fixes,
David

[bdbcat]

David...

This is just a question of developer bandwidth. The OCPN code is based upon an old version of XTide, C-code only, relatively easy to read and port. State of the art at the time OCPN implemented tides and current support.

The newest XTide was completely refactored into C++. The object hierarchy is complex, and its hard to even find the relevant lines of mathematics in the source code. But surely it is there somewhere.

So, finding the time to pick XTide apart and find/port the the newer algorithms is, IMHO, a non-trivial undertaking. I've de-prioritized it, given other issues.

Technically, the problem statement goes like this:
For secondary tide/current station, the current level is calculated using time and level offsets/multipliers from a master station. Level offsets and scale factors are no trouble. But time offsets are. The offsets may not be the same for hi and lo tide. So, we need to do a "stretch" or "compress" of time in the local time region, and recalculate the tide level at the adjusted time. This process is non-linear, and may be iterative.
It is certainly not obvious on casual code-reading how this is all done dynamically. FlaterCo's source is full of wierd special cases, each one of which applies somewhere.

Anyway, I'd be very happy to work with you if you want to take a detailed look at this.

Thanks
Dave