Board index FlightGear Development Weather

Advanced Weather debugging

Everything related to weather simulation, visuals should be discussed in the shader subforum.

Re: Advanced Weather debugging

Postby legoboyvdlp » Wed Mar 27, 2019 1:08 pm

Image

A first test. It seems to work well - now I just need to feed that data into advanced weather and make something that will schedule this to run every so often.
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: Advanced Weather debugging

Postby legoboyvdlp » Mon May 06, 2019 9:18 am

Ok - I'm needing help here.

First - there is a rather strange nasal error which I was wondering if someone experienced in nasal could look into. I'm getting a nil error from the same code that works for the old code. Basically, I have to create a new OOP WindIPoint. This IPoint has a built in nasal vector (that is, a coding vector) containing several maths vectors (composed of a direction and velocity). They are added as such:
Code: Select all
var wv = windVec.new(d0, v0);
      append(altvec, wv);


Unfortunately when the rest of local weather tries to read that, it fails. I get a nil error on this line:
Code: Select all
var res = add_vectors(dir_min, (1-f) * vmin, dir_max, f * vmax);

I traced it down to vmin being nil. When I call this on my new wind IPoint
Code: Select all
var vmin = w.alt[i-1].v;

or

Code: Select all
var vmin = w.alt[0].v;


I get nil back even though in theory it should contain my FIRST wind velocity. My SECOND wind velocity at

Code: Select all
var vmin = w.alt[1].v;


returns perfectly fine - just that w.alt[0].v; is nil for whatever reason. It shouldn't be, because it works just fine for other windIpoints! Can anyone see what's going on at a glance?
I asked Thorsten but (given he wrote that ten years ago understandably so) he is as stumped as I am...

pastebin of my local-weather.nas

local-weather.nas:
line 310 - the code that fails
line 339 - wind_interpolation(), the function that calls line 310
line 3433 - the function I use to create a new windIpoint object
line 4371 - windIpoint object

The strange thing is that the same code in wind_interpolation() works perfectly well for METAR windipoints - so it has to be something with how the windIpoint is initialized.




Also, I need comments as to how to resolve something else. Basically, at present I can get aloft weather for every 0.5 degrees. The question is, they conflict with METAR, in that METAR is using heuristics or something to generate winds aloft. The METAR windIpoints created tends to conflict because they don't have any real data to work with. The result can be a wind direction / speed drastically different from my aloft data. So, there are aloft windIpoints and METAR windIpoints - the code treats them the same, so that causes conflicts.

the question is what do I do? Do I
a) totally remove METAR points above a certain altitude - only use aloft data when above a certain altitude. Result: no jumping, always uses aloft data. May be a drastic change in wind speed / direction at removal of METAR when you incorporate aloft data.

b) only use aloft data when distance to a METAR point exceeds 0.5 degrees - result: no jumping, but will only use real world aloft data when it lacks own data. May be drastic change in wind speed / direction as you move from one to the other, but this can be interpolated over 0.25 degrees.

c) hack METAR points so they use real data for the ground but change them so they use aloft data for altitude. Result: lower resolution of aloft data everywhere, never any jumping (unless it is in real world data). Worldwide real aloft data. But hacky solution. And hard to do.

What do you think?

Notice that local-weather.nas is not ready for use - its for looking for the nasal error only! It will not work without my aloft weather external program, anyway.
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: Advanced Weather debugging

Postby wlbragg » Mon May 06, 2019 6:14 pm

Shot in the dark here, but can w.alt[i-1] ever be giving you 0-1 = -1?
IE: i = 0 and then subtracts 1
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7588
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: Advanced Weather debugging

Postby legoboyvdlp » Mon May 06, 2019 7:13 pm

I've checked that and nope - the index, , being used is 1;
[i]var vmin = w.alt[i].v;
returns my second point, so I expect var vmin = w.alt[i - 1].v; to return the first, but thats nil. Even when I call var vmin = w.alt[0].v; I still get nil. It has to be to do with how its initialized.

But thanks anyway!

Jonathan
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: Advanced Weather debugging

Postby V12 » Tue May 07, 2019 5:15 am

line 300 and 301 :
for (var i = 0; i<9; i=i+1)
{if (alt_wind < wind_altitude_array[i]) {break;}}

if the condition alt_wind < wind_altitude_array[i] is not true (ie wind_altitude_array[i] >= alt_wind), loop is breaked with i=0, on the and line 310 is indexer i-1 really -1 and var vmin = w.alt[i-1].v will return nil.
Fly high, fly fast - fly Concorde !
V12
 
Posts: 2757
Joined: Thu Jan 12, 2017 5:27 pm
Location: LZIB
Callsign: BAWV12

Re: Advanced Weather debugging

Postby legoboyvdlp » Tue May 07, 2019 9:49 am

I'm afraid not - the index i is clearly 1:

Code: Select all
Adding aloft weather point for 27.93155061499999,-15.38558745
 Vmin is null!
 1
 1083.755495041428
 5000
 
 15.2110922752
 
Nasal runtime error: nil used in numeric context


That is the result of:
Code: Select all
if (vmin == nil) {
print("Vmin is null!");   
print(i);
print(alt_wind);
print(wind_altitude_array[i]);
print(w.alt);
print(w.alt[i].v);
print(w.alt[i-1].v);
}


I expect w.alt to be nil since its not an actual number but a vector; however, I expect
print(w.alt[i-1].v); to print my first point, since print(w.alt[i].v); prints my second point.

Also, index i is explicitly 1 there. Thanks anyway!
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: Advanced Weather debugging

Postby legoboyvdlp » Tue May 07, 2019 10:22 am

Ok - stranger and stranger...

I tried:
Code: Select all
print("First altvec: " ~ d0 ~ " " ~ v0);


in the .new() function. However, I get a nonscalar error here, while it works for other points... (The ~ character is a tilde - it just doesn't show up here as one).

So it must be that somehow or other d0 or v0 is already nil when the windIpoint is being initialized.



Edit - ok - I traced the nil right back to my aloft function.
So, this is returning nil:
Code: Select all
print(getprop("/environment/aloftwind/windspd/mb1000"));

The property however does exist and has a value.

Image

It just doesn't make sense - why is that particular property nil when I know for a fact it isn't nil?
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: Advanced Weather debugging

Postby wlbragg » Tue May 07, 2019 5:11 pm

These properties are of your own creation, no tied properties?
Can you try renaming the variable that holds the information you want, even if only to test.
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7588
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: Advanced Weather debugging

Postby legoboyvdlp » Tue May 07, 2019 5:27 pm

Sure, can do. They are my own creation, created using a protocol.xml file. But the other properties work - its only that single one thats nil! I'll keep checking though... wondering if its because I'm using a setlistener on another one of the properties and perhaps that property hasn't been updated yet...?
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: Advanced Weather debugging

Postby legoboyvdlp » Sat May 18, 2019 3:57 pm

I've since fixed the nil.
The issue was that I had a setlistener on the property /environment/aloftwind/winddir/mb1000 while /environment/aloftwind/windspd/mb1000 was not created until after the other one was written to.
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: Advanced Weather debugging

Postby Thorsten » Sat May 18, 2019 7:15 pm

Yay... In hindsight, these things usually make sense - standing in front of them, they're just baffling in a major way...
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Advanced Weather debugging

Postby V12 » Tue Aug 20, 2019 6:20 pm

Interesting idea from another topic :

SurferTim wrote in Tue Aug 20, 2019 9:35 am:
V12 wrote in Tue Aug 20, 2019 7:09 am:Hmmm, again discontinuity in weather. I'm happy that I'm not alone with this nasty problem. I crashed many times in GA aircrafts with this reason - steep wind speed and direction changes. When You are climbing 80 kts in C172 a 20 kts headwind change direction about 180 degs in half second, You have almost unsolvable problem. When You have this problem 3 or 4 times in one day, You will stop use GA airplanes or leave FG.

I see a third alternative. I haven't looked into it deep enough yet, but now you have my interest up.

There must be a way to prevent radical wind direction, speed, and altimeter setting changes (the three settings that could kill you) to just change in an instant. It needs to be slowed up somehow. I have used setListener very effectively in the past. Is there a way to get a new METAR report, then slowly change each of those three settings over 30 seconds or so? That might give a pilot time to adjust.
Fly high, fly fast - fly Concorde !
V12
 
Posts: 2757
Joined: Thu Jan 12, 2017 5:27 pm
Location: LZIB
Callsign: BAWV12

Re: Advanced Weather debugging

Postby legoboyvdlp » Tue Aug 20, 2019 7:47 pm

There - is - a way and - it already - works. I find it highly unlikely you have a 20 knot complete flip of direction unless for instance you manually edited weather to change that, or you have a rather large storm in which case maybe it isn't general aviation weather :P


However, when you are flying close to stall, even a very small wind change could bring you just under the line - and in the case of yasim you get a loss of control.
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: Advanced Weather debugging

Postby Isaak » Tue Aug 20, 2019 8:41 pm

Lego: I often see wind direction changes at high altitudes of e.g. a 60 knot tailwind to 50 knot headwind with live weather (or even greater) et vice versa in a fraction of a second. I use aloft waypoints wind model. I don't bother much anymore and I'm glad the 777 isn't so realistic that it breaks my flight. After maybe 20 seconds I'm able to recover, be it with a structural airframe failure warning that doesn't do anything else. I've given up on trying to convince people who are familiar enough with the code that this happens a lot. Side effect is that it's not in my interest to make the structural airframe damage do something so I won't touch any of that code.
Want to support medical research with your pc? Start Folding at Home and join team FlightGear!
Isaak
 
Posts: 768
Joined: Sat Jun 04, 2011 3:52 pm
Location: Hamme, Belgium
Pronouns: he, him
Callsign: OO-ISA
Version: next
OS: Windows 10

Re: Advanced Weather debugging

Postby Thorsten » Tue Aug 20, 2019 8:47 pm

I often see wind direction changes at high altitudes of e.g. a 60 knot tailwind to 50 knot headwind with live weather (or even greater) et vice versa in a fraction of a second. I use aloft waypoints wind model.


I've basically given up to convince people that if you give any weather simulation bad input data it's going to give you bad results. METAR is not a viable representation of high-altitude winds because it doesn't report any in the first place. At airliner cruise altitude, you're not flying with 'live weather' - you're flying with 'I have no clue what it might be like up there' weather.

Since the tool exists, maybe you should use actual aloft wind data instead.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

PreviousNext

Return to Weather

Who is online

Users browsing this forum: No registered users and 1 guest