A user reports that our neaps-*.tcd loads in OpenCPN but not in qtVlm, while the classic harmonics-dwf-*-free.tcd loads in both (OpenCPN discussion #5164).
Root cause
Our TCD includes high-order compound constituents that aren't in the standard XTide congen set: 4MSK11, 4MSN12, 5MS12, 2M2NK9, 4MN10, M10, 3Mnu8, and similar (orders 7 through 12). These come from TICON via @neaps/tide-predictor, which defines 477 constituents; 128 end up in the built file.
OpenCPN's current libtcd reads the constituent list straight from the file, so unfamiliar names are fine. qtVlm ships an older, stricter engine that only recognizes the standard set and fails on the extras. The classic dwf file works everywhere because it uses only the standard constituents.
Worth ruling out explicitly: the year range is standard (1700 to 2100, same as dwf) and the constituent count (128) is below the standard 175. So it's the specific names, not the size or the year span.
Proposed fix
We can't change qtVlm, so the fix is on our side: publish a second release artifact restricted to the standard XTide constituent set, e.g. neaps-YYYYMMDD-standard.tcd, alongside the full file. The high-order terms carry very small amplitudes, so dropping them costs almost nothing in prediction accuracy but restores compatibility with qtVlm and any other reader that assumes the standard set. The full file stays the default for OpenCPN and XTide.
Open questions
- Which list to treat as the compatibility baseline (XTide congen, or the exact dwf set).
- Whether to implement it as a constituent filter in
packages/tcd/build.ts before build_tide_db.
A user reports that our
neaps-*.tcdloads in OpenCPN but not in qtVlm, while the classicharmonics-dwf-*-free.tcdloads in both (OpenCPN discussion #5164).Root cause
Our TCD includes high-order compound constituents that aren't in the standard XTide congen set:
4MSK11,4MSN12,5MS12,2M2NK9,4MN10,M10,3Mnu8, and similar (orders 7 through 12). These come from TICON via@neaps/tide-predictor, which defines 477 constituents; 128 end up in the built file.OpenCPN's current libtcd reads the constituent list straight from the file, so unfamiliar names are fine. qtVlm ships an older, stricter engine that only recognizes the standard set and fails on the extras. The classic dwf file works everywhere because it uses only the standard constituents.
Worth ruling out explicitly: the year range is standard (1700 to 2100, same as dwf) and the constituent count (128) is below the standard 175. So it's the specific names, not the size or the year span.
Proposed fix
We can't change qtVlm, so the fix is on our side: publish a second release artifact restricted to the standard XTide constituent set, e.g.
neaps-YYYYMMDD-standard.tcd, alongside the full file. The high-order terms carry very small amplitudes, so dropping them costs almost nothing in prediction accuracy but restores compatibility with qtVlm and any other reader that assumes the standard set. The full file stays the default for OpenCPN and XTide.Open questions
packages/tcd/build.tsbeforebuild_tide_db.