Closed jojom4n closed 1 year ago
Interesting find. Can you post a log where you think the estimated values are unreasonable? These are just estimations so maybe "incorrect" isn't the right word.
The function windSpeed() uses a well-known formula that expects, as reference speed, the wind speed in meters/s and should return also a value in meters/seconds.
Looks like I used something called the log wind profile to estimate wind speeds at altitude, but doing some research now, maybe the power law wind profile would have been more appropriate for estimations at these altitudes. Here's some references for reading. However, with just trying a few numbers, it seems the power law might be more likely to give extreme values.
https://en.wikipedia.org/wiki/Log_wind_profile https://en.wikipedia.org/wiki/Wind_profile_power_law
Now, even if you pass to windSpeed() the argument Wind.SpeedMPS (meters per seconds, I guess), the variable Wind.SpeedMPS contains the same exact value as Wind.SpeedKTS (knots per seconds).
This may be worth some investigation. These values are directly fetched from CheckWX and the m/s and kt values shouldn't match unless they're both zero. If you have logs of this happening that might be useful.
I don't know why it happens, but it happens and I cross-checked by observing values returned by RealWeather and the ones I calculated by hand and some other web calculators for wind shear at different heights.
Results from different calculators may vary depending on what assumptions are made. Realweather uses a "roughness class" of somewhere between 1 and 1.5 (0.04 meters for the roughness length). Ideally this is somewhere between open agricultural land and agricultural land with sheltering hedgerows. This roughness value is the primary factor that determines how extreme the differences between a ground observation and an airborne observation will be. This could also be made configurable if you find the current assumption doesn't provide desired results for your use case.
Consequently, with moderate wind (in knots/s) at ground level, windSpeed(), for 2.000 and 8.000 meters, returns insane values and applies them to the mission.
Thanks again for the write-up, and I'm curious to dig into it a little more. If you can upload some logs where you observe these unreasonable wind speeds I might be able to help in troubleshooting.
Thanks for prompt feedback.
No log unfortunately, because I use RW through DCSServerBot's extension and it does not log RW's results, but I'll attach the following screens. Here's current weather on my server:
This is the mission (modified by RW) in mission editor:
Now, wind at 19 knots is the value correctly retrieved from CheckWX for my reference airbase (LTDA) and 19 knots = 9.77 m/s. Wind at 2000 meters (6000 feet), using a calculator (https://www.rensmart.com/Information/WindSheer#:~:text=v%20%3D%20vref%20ln(z,know%20at%20height%20zref.) which applies the same formula which windSpeed() uses and the roughness value you pass as argument to the formula (0.04), should therefore be:
Wind at 19.15 m/s is about 37 knots, while on the server we have 58 knots.
To add some real mistery to the whole issue, I'll add that values, applied by RW and appearing in mission editor, seem the same ones values you would have if you would use the formula using the wind speed in knots, the altitude in feet and roughness value of 0.4 (not 0.04).
It seems more than a coincidence, but I cannot figure the reason why, other than thinking that DCS is modifying values on the fly when opening mission, perhaps making wrongly some kind of conversion.
It looks like your calculator is assuming the reference wind speed measurement is taken at 10 meters which will make a big difference on the result. Real weather is assuming a reference wind speed taken 1.5 meters off the ground. This is why changing your roughness length by an order of magnitude makes the results match (both reference and roughness x10 cancels out).
Real weather's calculation looks like this:
@ 6600 ft (2000 meters) $9.77 m/s * \ln(\frac{2000 m}{0.04 m}) / \ln(\frac{1.5 m}{0.04 m}) = 29.1665 m/s = 56.695 kt$
@ 26000 ft (8000 meters) $9.77 m/s * \ln(\frac{8000 m}{0.04 m}) / \ln(\frac{1.5 m}{0.04 m}) = 32.9035 m/s = 63.959 kt$
I'm not exactly sure how DCS converts m/s to kt, hence why the values are off by ~1 in the mission editor, but the m/s value (with a precision of 3) is what is actually written to the miz file if I remember correctly.
Wikipedia suggests that AWOS stations measure wind at 30 ft (~9 meters) so maybe it makes sense to update that reference value as such. This would make the wind results at altitude less drastic, though you could still easily expect winds in the 30 - 50 kt range depending on the reported winds.
However, I think if any improvement is to be made, it probably makes more sense to altogether switch the calculation to use the power law method instead since this seems to give better results for the altitudes we're concerned with.
Yes, calculation returns pretty rude values at altitude, especially 6.000 feet. For example, on the server now the base wind is 17 knots, but at 6.000 feet is 52 knots (and "only" 59 at 26.000 feet). I can see that wind at 26.000 feet can be pretty rough, but 6.000 feet should be a bit more moderate I guess.
Switched to power law calculation in f8ae90a.
Latest release has been published with these changes. The configuration file now has a stability number which you can adjust to vary the extremity of the winds aloft you will get. A less stable atmosphere would indicate more extreme winds aloft.
https://github.com/evogelsa/DCS-real-weather/releases/tag/v1.6.0
Also for whatever it's worth I did some back-of-the-napkin checks and the new calculation seems to roughly match winds aloft data reported by windy.com
Thanks. I don't think refHeight should be a const though. CheckWX returns the elevation of weather recording instrument in meters (Elevation.meters), and some stations (for example the one I'm using in Hatay, LTDA) are at aa pretty much higher elevation than 9 meters (i.e., for Hatay, 80 meters). I'll do some test on my own after modifying the code accordingly.
Fair point. I'll reopen to include elevation. In the case that elevation data isn't provided I'll default back to 9 meters.
Thanks, Just out of curiosity, I forked to analyse different results between old formula (with refHeight equal to Elevation.meters) and new formula (using refHeight in the same way).
Incorporated in above commit.
Took the opportunity to improve ground winds as well by estimating those based off a 1 meter observation. This should make a significant difference especially for stations recording in excess of the standard 9 meters.
Feel free review and experiment with the changes. I'll hold off on publishing a new release for a bit.
Hi evogelsa, I made some tests with your latest master and a fork of mine using old formula (and elevation.meters too). I'm attaching results. A few observations: 1) new formula returns refSpeed at ground 0 level, so data is always the same you retrieve from METAR although you try to properly calculate it for 1 meter above ground;
2) old formula, in test number 4, gave insane results and the farthest from the new formula, I don't know why though;
3) new formula exhibited pretty unreliable calculations in test number 2. In this case, the station is about @2000 meters and retrieved windspeed, at this altitude, was 13 mps, But the new formula calculated 28 mps for 2000 meters. Of course, it should have calculated about 13 mps, which is the well-know windspeed retrieved from METAR.
Hope this helps.
Cheers RealWeather tests.txt
@jojom4n thanks for the detailed testing. I read the CheckWX API documentation a little more thoroughly along with performing a little more testing. I believe that we were misunderstanding the elevation property returned by the API. This elevation is actually the weather observation station MSL altitude rather than its height AGL. As such using the elevation as the refHeight
is actually counter productive, and I believe it's more correct to use the constant of 9 meters.
Although I suppose if windSpeed uses MSL altitudes rather than AGL there could be some sense to the elevation as reference height.
Latest release fixes wind calculations to use MSL altitudes and station elevation for refHeight. Enjoy!
https://github.com/evogelsa/DCS-real-weather/releases/tag/v1.6.1
Miz.go calls function windSpeed() to calculate wind shear at different heights, but the results are wrong.
The function windSpeed() uses a well-known formula that expects, as reference speed, the wind speed in meters/s and should return also a value in meters/seconds.
Now, even if you pass to windSpeed() the argument Wind.SpeedMPS (meters per seconds, I guess), the variable Wind.SpeedMPS contains the same exact value as Wind.SpeedKTS (knots per seconds).
I don't know why it happens, but it happens and I cross-checked by observing values returned by RealWeather and the ones I calculated by hand and some other web calculators for wind shear at different heights.
Consequently, with moderate wind (in knots/s) at ground level, windSpeed(), for 2.000 and 8.000 meters, returns insane values and applies them to the mission.