Terminology - TWS / TWA

[rgleason]

Under
Tactics https://opencpn-manuals.github.io/main/tactics/index.html#_4_terminology
Dashboard_Tactics https://dashboard-tactics-pi.readthedocs.io/en/latest/tactics/tactics.html#Calculate-true-wind-data
(has more detail and discusses certain aspects, but has the same terminology)

1. Make it clear what is being used (grnd or wtr)
2. Add Ground wind speed/direction/ (as if anchored) with a note that WR refers to this as TWS/D relative to ground.
3. State that TWA & TWS can be relative to water or ground, there is no concensus, and that it should be noted which is being used whenever possible.
4. TWAground TWSground , TWAwater, TWSwater OR maybe TWAg TWSg TWAw TWSw

Refer to in line code documentation in weather_routing regarding terminology.
See line 528 weatherroutingUI.h
b4225aa

[rgleason]

Predictwind Definition (TWS & TWA relative to ground)

has TWS and TWD as when stationary as if anchored or at dock.
https://www.predictwind.com/glossary/t/true-wind-speed

• True wind speed is the actual speed of the wind relative to a stationary point, while apparent wind speed is the wind speed experienced on a moving vessel.
• The apparent wind is a combination of the true wind and the wind created by the vessel's motion.

Cruising Compass (TWS & TWA relative to ground)

https://www.bwsailing.com/cc/2017/05/calculating-the-true-wind-and-why-it-matters/

• There are several ways to define the wind. For weather work at sea we care only about the true wind. This true wind is the speed and the direction of the wind relative to the fixed earth under the ocean.
• Tied up at the dock, we feel the true wind. Once we get underway, however, our own motion changes the wind we feel, and then it is called the apparent wind.
• TWS = True Wind Speed (relative to the fixed earth)
• TWD = True Wind Direction (relative to true north)

Raymarine Definition (TWA & TWS relative to water)

https://support.raymarine.com/s/article/Apparent-Wind--True-Wind-and-Ground-Wind--and-data-required-to-calculate-them?language=en_US

Also see discussion: https://forum.raymarine.com/showthread.php?tid=987

• True Wind - What Raymarine refers to as True Wind (TWA, TWS) is always wind-over-water, not wind-over-ground (more on this below.) We calculate this from AWA and AWS, plus speed-through-water (STW, from a paddle-wheel or equivalent.)

• It's not possible to calculate proper True Wind from GPS speed (SOG.) If you're looking at your wind instrument and you have AWA and AWS but TWS is showing as dashes (-.-kn) then you don't have Speed data coming in.

• Ground Wind - Ground Wind is what you'd measure standing on the dock, referenced to north (GWS and GWD.) This requires AWA/AWS (direct wind measurement), GPS COG/SOG (how the boat is moving over the ground) and compass Heading (where the boat/wind-vane is pointing, relative to north.)

David Burch Starpath (TWA & TWS relative to water)

True Wind and Ground Wind, why both are needed.
https://davidburchnavigation.blogspot.com/2021/12/TW-v-GW.html

• The true wind on the left above is relative to the water, and if that water is moving the ground wind will not be the same as the true wind.

[rgleason]

Conclusion

There is no consensus about TWA and TWS, so we will always have to be clear about what is being used in context.
(relative to ground , over ground or grnd) or (relative, over water to water or wtr)

David Burch Starpath regarding this issue:

Ben Ellison has pointed out (www.panbo.com) that many performance sailors prefer to know the wind vector relative to the water as opposed to the fixed ground below it, which is what we would get by simply using S for SOG and H for COG. This is the way many instruments compute this data, though many models now offer options. He proposes to call this wind the Water Wind, as opposed to True Wind (which as shown above is not correct), and then do away with the term True Wind and call that Ground Wind. There is clearly logic in this terminology, and it drives home the point that we should think on these differences. We will have to see how the sport and industry responds.

I am old fashioned in these matters, and will likely stick with true wind, and just check that it is computed properly when it matters. But then, I still use GMT when I should say UTC1.

[rgleason]

asking Copilot: In Polar Plots what is the definition of TWS/TWA? is it relative to water or ground?

In polar plots used for sailing, True Wind Speed (TWS) and True Wind Angle (TWA) are "unaffected by the boats motion"

• TWS represents the actual speed of the wind as it moves across the water, unaffected by the boat's motion.
• TWA is the angle between the direction of the true wind and the direction the boat is heading.

These metrics are crucial for understanding a sailboat's performance under various wind conditions, as polar plots graphically display the boat's speed at different TWAs for various TWS values.

Sailing fast - TWA and TWS (relative to ground, anchored, docked, stationary in the water)

https://mandurahyachtacademy.au/twa-and-tws/
True Wind Speed (TWS)
Definition: TWS is the actual speed of the wind as it would be experienced if the boat were stationary in the water.
Reference: Independent of the boat’s motion (as opposed to Apparent Wind Speed, AWS, which accounts for the boat’s speed).

[rgleason]

asking Copilot: Does the way polars are recorded determine how the TWS and TWA is defined?

Yes, the method used to record polars can influence how True Wind Speed (TWS) and True Wind Angle (TWA) are defined and interpreted. Here's how:

1. Real-World Testing:

   • If the polar plot data is gathered through on-the-water testing, the TWS and TWA are measured relative to the water. This approach reflects practical sailing conditions and performance.

2. Simulated or Modeled Data:

   • Computational modeling software assumes the water as the reference point by default, so TWS and TWA are also relative to the water, not the ground. These models are designed to simulate realistic conditions for sailing.

3. Instrument Calibration:

   • Instruments like anemometers and wind vanes are typically calibrated to measure the wind relative to the water’s surface. This setup ensures consistency in defining TWS and TWA across different polar plot recording methods.

The emphasis on the water as the reference frame aligns with the fact that sailboats interact with the wind and water, not the stationary ground. As a result, TWS and TWA definitions are closely tied to this practical perspective.

Would you like to explore how modern technologies, like onboard systems, help sailors generate accurate polar plots?

[rgleason]

Therefore, I believe that all polars are using TWS/TWA measured relative to the water.

Indeed Raymarine the Instrument maker for many in this world, uses TWS relative to the water.
So does the diagram in Tactics, despite all the other countering statements, we are using instrument data to create polars.
I believe Predictwind and Cruising Compass have it screwed up

@sebastien-rosset @quinton-hoole

And therefore, Weather_routing is no different. It is using TWS/TWA measured relative to the water!!!

Please make sure that this is the way TWS / TWA is defined, because Weather_routing has to read Polar files and on of the best ways that polar files are created is by recording the polar data with Wind instruments (which measure TWS/TWA as relative to water).

[sebastien-rosset]

I will use GWS, GWS, TWS and TWD for variable names the code and the UI. All of these are needed for the computations.

In the UI, I will add tooltips whenever possible, and if there is enough space, expand the acronyms.

[rgleason]

That sounds good to me. In the manual we can make it clearer hopefully.

[rgleason]

@sebastien-rosset May I close this now? or should I leave it open?

[quinton-hoole]

It is my opinion that in the code, we should use unambiguous terms (like WIND_SPEED_OVER_GROUND, WIND_SPEED_OVER_WATER etc), precisely because ambiguous terms like TWS are used by different people to mean different things (as evidenced above). I don't personally have an interest in debating which people are right and which people are wrong, only in making sure that someone reading and writing the code, understands exactly what they are looking at. The very fact that the three of us, and predictwind, and starpath, and raymarine, and B&G don't have a common understanding of what TWS means (and we're all relatively knowlegable about this stuff), tells me simply that the terms are ambiguous and widely misunderstood (not something we want to happen inside the code).

As for the presentation, I think that's more up for debate, should be configurable (like the B&G instruments) to suit the specific use case and user.

Having said all that, this is not a hill I'm interested in fighting for. Just wanted to add another perspective. I don't think there's a right answer here.

[quinton-hoole]

If you really want to mess your brain up, imagine a boat trying to sail past a dock in strong current. Because of the current, the boat is standing still relative to the ground. A guy standing on the dock, next to the boat, holds an anemometer in his hand and says the true wind speed is 10 knots. The sailor on the boat says the apparent wind is 10 knots, but the true wind is 20 knots. They are a few meters away from each other, stationary relative to each other, and looking each other in the eye. They are both right, but but both very confused. And the local weather station agrees with the guy on the doc, and says the wind is blowing at 10 knots. If the sailor on the boat said instead that the wind speed relative to the water he happens to be in at the moment is 20 knots, all confusion goes away.

[rgleason]

My point is The plugin is using Data derived from instruments isn't it?
How can you be sure it is TWS relative to ground? How do you know you are not mislabeling it?

Perhaps we should look more carefully at polar_pi which records the data coming from the instrument?

[sebastien-rosset]

My point is The plugin is using Data derived from instruments isn't it?

The input data is from GRIBs, climatology, shapefiles (OSMSHP or GSHHS), boundaries (OCPNDraw), polars and routing configuration. The plugin does not use any data coming directly from instruments, and specifically it does not consume any NMEA data directly, if that's what you meant.

Given these inputs, the plugin predicts the future values of GWS, GWD, TWA, TWD, TWS, AWA, STW, CTW, COG, SOG, HEADING for every point in the isochrons. That is, if somehow predictions were 100% accurate, and you sail by following the optimal path and the conditions are exactly the same, what you would read on the instruments (from NMEA data) would be the same as what has been predicted. Even though the predicted values will be different from the reality, I agree it's a good idea to match the terminology between predicted and instrument (NMEA) readings such that the user can easily compare. For example, previously the WR plugin was displaying the "Wind velocity", so it wasn't clear how this mapped to NMEA data.

How can you be sure it is TWS relative to ground? How do you know you are not mislabeling it?

In the WR plugin, we know whether a predicted wind value is relative to water or ground, but it's as good as the input data.

1. The wind data over ground is obtained directly from the GRIB files or climatology data. Given any lat/lon coordinate and timestamp in the future, the plugin does a lookup in the GRIB file to determine GWS and GWD.
2. The wind data over water is also obtained from GRIB files, by reading both the wind and currents. This is where it gets a bit tricky: if the current data is available, then wind data over water is somewhat realistic. But if there is no wind data in the input GRIB files, then the wind data over water will be calculated to be exactly the same as wind data over ground, because in that case the plugin assumes the current is zero.

[rgleason]

That is a good explanation, worth keeping.

The plugin does not use any data coming directly from instruments,

But along comes the polar file which is used with the grib data in some form, as GWS and GWD or as TWS (relative to water) and TWS (relative to water).

The polar file can be created by:

1. Instruments - the best way if instruments are calibrated.
2. Velocity prediction programs.-inaccurate
3. Manually - inaccurate

So I ask what is TWA\TWS In the polar files?

Can we always be sure?

[sebastien-rosset]

That is a good explanation, worth keeping.

But along comes the polar file which is used with the grib data in some form, as GWS and GWD or as TWS (relative to water) and TWS (relative to water).

The polar file can be created by:

1. Instruments - the best way if instruments are calibrated.
2. Velocity prediction programs.-inaccurate
3. Manually - inaccurate

So I ask what is TWS/TWD ( or is it the other way?) In the polar files?

Can we always be sure?

Ah ok, sure. But the WR plugin does not care how the polar was constructed. Whether the polar was created manually, from instruments, provided by vendor or any other process, the WR plugin expects the polar to provide boat speed for a set of wind angles (TWA) and wind speed (TWS). The polar is expected to provide these values without any current, i.e. current speed = 0.

In other words, the WR plugin wants a CSV file like this. Note there is no information about whether data from obtained from NMEA data, from manual input or something else. It's just a CSV file with wind angle, wind speed and boat speed.

[rgleason]

the WR plugin does not care how the polar was constructed. Whether the polar was created manually, from instruments, provided by vendor or any other process, the WR plugin expects the polar to provide boat speed for a set of wind angles (TWA) and wind speed (TWS). The polar is expected to provide these values without any current, leeway, etc i.e. current speed = 0. If the boat is moving, then set and drift (leeway and current speed) must be removed by calculation.

So despite what Raymarine uses for TWA\TWS all Polar files should be recorded with current speed=0 which is TWA\TWS anchored, at the dock or relative to ground!

I hope you are sure of this. Can we be sure that Polar_pi when using the speedo, or nmea, or whatever is recording
TWA\TWS without current, as if anchored or at dock, grounded? Maybe this is a different Issue, but should be checked I think.
Using C:\Users\fcgle\AppData\Local\opencpn\plugins\weather_routing_pi\data\polars\a40.pol

[rgleason]

It happens that this is the B&G display I am installing now with a new Jefa LD100 AP.
Since this is for the Display (not WR_pi, Grib_pi, Climatology_pi, Polar_pi), isn't this just a preference setting?

I think I have reached a reasonably good understanding of the terminology and I appreciate this discussion.
I just ask that you and Quinton try to keep your in-code comments clear about what is being used in the calculations.
If you'd like this closed, please go ahead and close it.

I will be referring to it to improve/clarify the Terminology in Tactics and may have some other questions. Thanks.

[sebastien-rosset]

It happens that this is the B&G display I am installing now with a new Jefa LD100 AP.
Since this is for the Display (not WR_pi, Grib_pi, Climatology_pi, Polar_pi), isn't this just a preference setting?

It is a preference setting that can have a major impact on sailing tactics. To calculate the TWD and TWS, you can decide to use speed over water and heading, or COG/SOG. On the H5000 system, you can also take the pitch, roll and yaw rates as well as the heel and trim angles, which are used to apply more advanced calculations.

I think I have reached a reasonably good understanding of the terminology and I appreciate this discussion.
I just ask that you and Quinton try to keep your in-code comments clear about what is being used in the calculations.

From that perspective, the code has already improved a lot. The variable names and labels are more meaningful and consistent with other parts of OpenCPN, and there are code comments.There is still room for improvement for sure.

If you'd like this closed, please go ahead and close it.

I will be referring to it to improve/clarify the Terminology in Tactics and may have some other questions. Thanks.

[quinton-hoole]

I've been following along here. Great discussion.

One other important thing worthy of clarification. In the absence of GPS or quite sophisticated water movement instruments, I assume it is impossible to determine leeway from the boat? And to make weather routings even vaguely accurate, they need to take into account leeway (which is typically substantial). And the polar curve does not account for leeway (if I understand correctly), because it's based on wind speed over water apparent wind direction (which is then converted to wind direction over water aka TWD using only AWA and STW). So leeway gets lost in the process. And given that routing is relative to ground (I want to get from Point A on the ground to Point B on the ground) we have to take into account leeway some other way. Is that in there somewhere? Sorry, my ocpn is crashing at the moment, so I can't check.

[sebastien-rosset]

And to make weather routings even vaguely accurate, they need to take into account leeway (which is typically substantial)

hmm, the wind forecast accuracy is typically the most significant factor influencing weather routing precision on large keelboats, not leeway. For large keelboats with substantial fixed keels, leeway is relatively minimal (often just a few degrees) compared to smaller boats or those with retractable keels.

1. Differences between predicted and actual wind speed/direction
2. Local effects not captured in weather models
3. Temporal shifts in weather systems arriving earlier/later than forecast
4. Micro-climate variations near coastlines or islands
5. Waves, cross waves, patterns, wave-current interactions
6. Crew fatigue and safety

These wind prediction discrepancies can completely change optimal routing decisions, whereas small leeway variations might only adjust your course by a minor amount. Even a 10-15 degree wind shift or 5-knot wind speed difference can dramatically affect optimal sail selection and routing strategy.

There is code for leeway but it's not enabled right now. There is also leeway code in the tactics plugin, that could be useful.

But I think for better modeling, leeway is not the first priority. The major areas of enhancements are: Ensemble forecast integration; advanced wave modeling integration, real-time polar adjustments, improve current modeling, historic performance database, bathymetry aware routing, reverse isochrons.

[rgleason]

Quinton I like that question. "So leeway gets lost in the process?"
Is that why Thom

[quinton-hoole]

And to make weather routings even vaguely accurate, they need to take into account leeway (which is typically substantial)

hmm, the wind forecast accuracy is typically the most significant factor influencing weather routing precision on large keelboats, not leeway. For large keelboats with substantial fixed keels, leeway is relatively minimal (often just a few degrees) compared to smaller boats or those with retractable keels.

1. Differences between predicted and actual wind speed/direction
2. Local effects not captured in weather models
3. Temporal shifts in weather systems arriving earlier/later than forecast
4. Micro-climate variations near coastlines or islands
5. Waves, cross waves, patterns, wave-current interactions
6. Crew fatigue and safety

These wind prediction discrepancies can completely change optimal routing decisions, whereas small leeway variations might only adjust your course by a minor amount. Even a 10-15 degree wind shift or 5-knot wind speed difference can dramatically affect optimal sail selection and routing strategy.

There is code for leeway but it's not enabled right now. There is also leeway code in the tactics plugin, that could be useful.

But I think for better modeling, leeway is not the first priority. The major areas of enhancements are: Ensemble forecast integration; advanced wave modeling integration, real-time polar adjustments, improve current modeling, historic performance database, bathymetry aware routing, reverse isochrons.

@sebastien-rosset I get it that there are many factors that make weather routing calculations non-optimal. In my relatively limited experience (although I have crossed three large oceans now) leeway is a big one. The leeway on many large cats, for example, can be in the order of 15 degrees, depending on wind direction and speed (and waves, of course). This article says up to 20 degrees for monohulls, which is consistent with my experience. That makes an enormous difference to things like estimated passage time, and achievable beating direction, especially upwind. Once the passage time becomes highly inaccurate, many of the other effects get compounded (because, for example, you end up not sailing through the weather you thought you would, because both the time and course in the routing might become infeasible).

I agree that we need to improve all those other things on your list, but leeway should be near the top of that list, IMO.
It's also worth noting that ocean sailing (where one most needs weather routing) is dramatically different than coastal sailing, in that weather forecasts are far more accurate in the ocean than near land, wind effects due to land features are largely absent etc.

[sebastien-rosset]

Sure, sounds good. For initial contributions, may I suggest a list of good first issues?
https://github.com/rgleason/weather_routing_pi/issues?q=is%3Aissue%20state%3Aopen%20label%3AgoodFirstIssue
Starting with small changes with limited scope is one way to get acquainted with the code base.

[quinton-hoole]

Sure, sounds good. For initial contributions, may I suggest a list of good first issues? https://github.com/rgleason/weather_routing_pi/issues?q=is%3Aissue%20state%3Aopen%20label%3AgoodFirstIssue Starting with small changes with limited scope is one way to get acquainted with the code base.

Yes, as I've mentioned, I want to get some decent test coverage over the code first. I find it quite difficult to make reliable code changes without having tests in place to catch regressions. Feel free to advise otherwise. I see you've managed to make quite significant code changes without automated tests in place. I'm quite surprised.

[rgleason]

Tactics https://opencpn-manuals.github.io/main/tactics/index.html#_3_8_settings_in_the_ini_file
Regarding Leeway, Tactics has a setting choices for

• Boat's Leeway Factor
• Use Heel Sensor
• Fixed/Max Leeway
• Manual heel input - a table for leeway that can be used if you do not have adequate instrumentation.

Perhaps that could be used to help account for leeway.
Something to consider in the future.

[quinton-hoole]

Good idea. I think leeway is ideally represented as a polar curve, as it varies based on both wind angle and wind speed. I believe we already have support for this kind of combining of polars.

[quinton-hoole]

Here is an additional very useful article, focussed mainly on boat speed and direction (relative to both ground and water).

https://davidburchnavigation.blogspot.com/2023/06/speed-and-heading-basic-but-not-always.html

I'd love to find an equivalent article on wind speed and direction.

[rgleason]

Good idea. I think leeway is ideally represented as a polar curve, as it varies based on both wind angle and wind speed. I believe we already have support for this kind of combining of polars.

Good point, and that might be a way to have users utilize the existing interface to create a leeway polar file manually, but then that heeling/leeway polar file would deduct from the boat polars acting to reduce performance.

[sebastien-rosset]

For reference, here is the relevant leeway code in the WR plugin:

weather_routing_pi/include/Polar.h

Lines 437 to 452 in 512fc73

	/**
	* Calculates the angle between the boat's heading and its course through
	* water (leeway angle).
	*
	* The leeway angle occurs due to the sideways force of the sail being
	* balanced by the keel/centerboard, causing the boat to move slightly
	* sideways while sailing.
	*
	* @param awa The apparent wind angle in radians
	* @param aws The apparent wind speed in knots
	* @return The leeway angle in radians
	*
	* @note The current implementation returns 0. This feature is not yet
	* implemented.
	*/
	double AngleofAttackBoat(double awa, double aws);

weather_routing_pi/src/SailboatTransform.cpp

Lines 1 to 91 in 512fc73

	/* to calculate power required to get the boat on plane
	horsepower = Disp * lwl / ((2.3-(8.26 / (Disp / (.01 lwl)^3 )^.311))*8.3)^3
	The boat has forces:
	apparent
	wind ^ powered
	\ | thrust
	\ | /|
	\| / sail
	/\ / power
	| |
	| | ---->
	| | leeway
	|__|
	|
	| drag
	\|/
	technically drag is going against any movement,
	but we can simplify and have it go against forward movement
	Since we know BV is related to square root
	of power input, the coefficient k computes speed
	f - forward velocity
	s - slip velocity
	j - keel lateral force at 1 knot
	k - drag at 1 knot
	l - keel lift factor
	k = wetted_sq_ft drag_coefficient
	Drag is related to velocity times wetted surface area squared
	D = k f
	a(t) = (P - D)/m
	f(infinity) = integral(a(t), t, 0..infinity)
	P = k V
	P = V P
	2
	P = k V
	A __
	FSx = k eta sin (-) \/aws
	2
	A __
	FSy = k eta cos (-) \/aws
	2
	FMx = sqrt(P k)
	FMy = 0
	FKx = f (l s - k)
	FKy = - s j
	f = (FSx + FKx + FMx)dt = (k eta sin(A/2)*sqrt(aws) + f*(l*s-k)) dt
	s = (FSy + FKy + FMy)dt
	s(inf) = k eta cos(A/2) sqrt(aws) / j
	f(inf) = eta sin(A/2) sqrt(aws) / (1 - l / j s(inf))
	eta sin(A/2) sqrt(aws) + P
	---------------------------
	f(inf) = 1 - l s(inf)
	-
	k
	(define (s eta A aws k j) (* k eta (cos (/ (deg2rad A) 2)) (sqrt aws) (/ j)))
	(define (f eta A aws l k j P) (/ (+ (* eta (sin (/ (deg2rad A) 2)) (sqrt aws))
	P) (- 1 (* (/ l k) (s eta A aws k j))))) (define (aoa eta A aws l k j P)
	(rad2deg (atan (s eta A aws k j) (v eta A aws l k j P)))) (define (BV eta A aws
	l k j P) (sqrt (+ (square (s eta A aws k j)) (square (f eta A aws l k j P)))))
	aoa - angle of attack, direction keel is moving thru water
	aoa = atan2(s, f)
	BV
	_______
	BV = / 2 2
	\/ f + s
	*/
	/* difference between direction we face and direction moving thru water */
	double BoatPlan::AngleofAttackBoat(double A, double aws) { return 0; }

It's just a stub implementation for now.

[quinton-hoole]

Two more great articles from Starpath. We're not imagining the confusion - it's real :-)

https://davidburchnavigation.blogspot.com/2021/12/TW-v-GW.html

especially

https://davidburchnavigation.blogspot.com/2021/12/TW-v-GW.html?showComment=1641578318982#c2762166955327506743

Also

https://davidburchnavigation.blogspot.com/2023/06/speed-and-heading-basic-but-not-always.html

[rgleason]

I linked to those above.