Board index FlightGear Development Weather

Detailed weather does not use metar wind

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

Re: Detailed weather does not use metar wind

Postby KL-666 » Thu Jan 08, 2015 11:43 am

Hi Thorsten,

Yes i have been a bit quiet, that is because i am testing the 1/d situation all the time. To properly test, i have to fly a while each time, so i can pick up several metars underway before landing. If i try to compare 1/d and 1/d^10 on the same route, i have a hard time to get the same conditions, because metars underway can change within an hour.

All i know for now is rough statistics. With 1/d the wind at the airport is often off the metar wind. With the 1/d^10 calculation, it is almost always right. But even with that calculation i have had once or twice that the wind was 20-40 degrees off at the airport. I also tested a calculation that ended in 1/d^4, but that did not seem to differ from the original 1/d.

Overall i can say the calculation with 1/d^10 i sent you before is quite satisfactory to me. But it would be better if someone else flew around with it too for while. Pity your fast machine is not on the internet.

I think the issue of gust calculation not picking up new wind is most important to solve. What i did for now is replace:
Code: Select all
var winddir_last = interpolated_conditions.wind_from_heading_deg;
with
Code: Select all
var winddir_last = winddir;

It might not be completely in line with the logic as intended, but at least it is better than nothing for now.

Kind regards, Vincent
KL-666
 
Posts: 781
Joined: Sat Jan 19, 2013 2:32 pm

Re: Detailed weather does not use metar wind

Postby St.Michel » Thu Jan 08, 2015 3:47 pm

You write here with this attitude that whatever you are planning to do is obviously so much superior to what I have done and the solution to all problems which nobody before you reported in years. And I neither care for this attitude, nor do I care for unproven claims.

Thorsten, please - can we leave this "ego-thing" - this leads to nothing...

I don't think, that all whatever I planning is superior. I hope only, that it could be a progress. (And 2 pages back, it seemed that you also thought so.)
I can't do this alone and I can't do this against You. (And even if I could, there would be no use to do this!)
And I don't want to overtrump You - you said, that Your method to calculate ALOFT winds was only a workaround, and I say, I'd like to enhance this. You say, nobody will need this - and I say, who don't need this, will not even notice this.
(And I think the most of us don't even know, that there is anyway a method, that calculates ALOFT winds - and how and why. But to say, that nobody reported a problem with altitude winds, is not quite correct.)

After our last disput I wrote Your a PM and provided to apologize me at the forum. I said, I don't speak a versatile english and perhaps You misunderstand this as "this attitude". But You said, this is needles and we can keep it professional AND in the forum (because ideas and explanations could be useful for others).
But this is not professional. Whatever I say is wrong. And when I fight for my opinion, then You allege me a wrong attitude.

I don't want to attack or impress You - but when You say something, that is wrong (or when I think, that is it) then I say this. You're not my chef and not my teacher.
And what You say about alt-winds IS wrong. I read several books about this last time, I often have had a look at "real weather" and "tested" my new knowledge. And also Your picture seems to confirm this - altitude-winds are preferably quite uniform:
Image

For the 5. Jan in the west it shows an very uneven ground-wind:
Image

I would "predict", that the wind-speed there is rather low - and this data seems to confirm this:
http://earth.nullschool.net/#2015/01/05 ... 40.25,3000

My method will reshapes a slow wind with an assumed (stronger) westerly wind - and so we would have a more uniform alt-wind there. A stronger (and perhaps more reliable) ground-wind will not be reshaped (but smoothed with other METARs). At the moment - and perhaps never - the direction of the alt-stream can be wrong (it is somehow westerly). So it don't will recreate the real weather - but it creates a "reasonable" weather, I think; perhaps a bit "schoolbook like"...
This stream could/should be shifted/triggered by pressure-systems (but for this we need a set of METARs) and its axis perhaps could even mark/simulate a simple jetstream.

(For Mexico it would not yet supply a good solution, but there perhaps a "trade-wind" model would help...)

And again:
I don't want to use for flight-planning a "real-weather-map" from the internet. It would be marvelous, if the calculated wind would be coincident in that way (but I don't think, that this is possible).
I want to read out (or illustrate) our weather and take this for planning.
And I think, that this should not be insoluble, because this is the same wind (and the same algorithm) that we use now, to calculate the wind at planes position. (This should also work, without anyway changing the actual method.)
St.Michel
 
Posts: 87
Joined: Tue Apr 15, 2014 9:20 am

Re: Detailed weather does not use metar wind

Postby KL-666 » Thu Jan 08, 2015 9:53 pm

What i understand of st.michel's argument is that aloft wind is generally more uniform than ground wind, and that aloft wind solely based on ground wind will make aloft wind too diverse to compete with uniformity like in reality.

I see two ways to satisfy this wish:

1) Online aloft wind data like matar
I do not know if this exists, but since metar is live gettable, i reckon aloft winds must be too.

2) Fake aloft wind tendency
For large parts of the world choose a general aloft wind tendency. Or for the whole world postulate that the main tendency is west-east or whatever. Then make the individual metars pull on that horizontal lines. So the individual metars do not fully determine the end result. The result could be somewhat like the aloft wind maps you guys have shown me. Of course they are not real, but more uniform.

In all cases the base of weather calculation should be nearby weather info (like in current AW). Not calculating the world weather. That is just not feasible with current computing power.

Kind regards, Vincent
KL-666
 
Posts: 781
Joined: Sat Jan 19, 2013 2:32 pm

Re: Detailed weather does not use metar wind

Postby Thorsten » Fri Jan 09, 2015 9:20 am

Thorsten, please - can we leave this "ego-thing" - this leads to nothing...


Sorry, from where I stand, I have given things a fair try but it doesn't work for me.

After pages of discussion, I'm not even clear on what exactly it is you want to do except somehow alter the way winds work. At some point it revolved about making an offline semi-random model for high altitude winds. Then you changed to averaging METARs. Then it was getting a better model of low altitude winds and terrain effects, Fourier-transforming the terrain. Then you wanted a weather map usable for flight planning. Basically, every time we have some conversation, your goal has subtly changed.

At the same time, I don't get the impression you're actually interested in my arguments, I get the impression you're just interested in making yours. When I say 'the problem discussed here is about low altitude winds' your response was 'but people are interested in predictable winds in any case'. Sorry, but that gives me the distinct impression you don't care what problem we're discussing, you want to make your point anyway - whether it fits the occasion or not.

You don't deal well with me not agreeing 100%. Even a mild As I said earlier, I can readily see that pushing real aloft winds improves things, but not that swapping one workaround model for another workaround model does. gets me a response like I did some research and have some ideas to make it better - but without any effect, as it seems... . Note that I didn't say that what you're doing is wrong, I didn't say that what you are doing is not better, I didn't say this shouldn't be done - all I said is that I can't see this readily. I intentionally phrased it that way, because the wording keeps the possibility open that the fault may be entirely mine for not seeing something which you see but didn't explain.


Contrast this with the interaction with KL-666 in this thread. There's an actual problem which is well described and argued (for vectoring, ATC needs to be reasonably sure that all approaching planes feel something close to the wind reported by METAR during approach). There's an identified reason (the way data is interpolated), there's a clear path to explore (the interpolation weight) a pointer to the relevant code and some experimental changes. And two bugs found on the way. It's a purely professional interaction in addition - no 'this is so bad' and such like. So it's a win-win.

I have limited time at the moment, my coding focus is not on weather but on an improvement to the tree rendering C++ and GLSL code, and you make the time I spend discussing weather rather unpleasant for me.

Since my time is limited, I'll just grab one aspect and explain it in depth.

For instance, you make strong statements here.

And who is not able to have a look into the code, has no possibility to determine the wind above or under the actual altitude - and actually no one between the stations.


I am frankly baffled. How do you imagine, say, an airspeed indicator works? Do you really think the weather system should generate the reading of the airspeed indicator?

Of course not! The weather system talks to the FDM via a set of interface points - in fact any FG weather system talks to the FDM through interface points. The airspeed indicator code picks up what it wants to know from there and computes the indicated airspeed itself. The weather system talks to the rendering framework similarly via a different set of interface points.

Likewise, the weather system doesn't draw a map in the GUI - its purpose is to supply the information to whatever instrument wants to draw a map. Now, since here we're not passing values but functions, the interface is more complicated - there has to be a layer querying what weather system is running for starters. But - AW actually supplies all that's needed - you can query whether it is running, you can query which wind model is running, and you can call local_weather.wind_interpolation(lat, lon, alt) to get the wind the simulation thinks is at an arbitrary point in the world (of course, the farther you are from the plane, the more pointless that value will be). You could call this function in a windsock Nasal to make it show the ground wind rather than the wind at the location of the plane for instance.

And you get to do all that with less than 5 lines of Nasal. So rather than not supplying the capability, AW has very much all that's needed. And it's all nicely modularized. The data to be interpolated is separately from the way you generate the data (so you can put any winds you fancy at the simple expense of calling the set_wind_ipoint function), you have a well-defined function call to get wind at any position (note that the whole setup was designed that way, it never was supposed to give you wind at the aircraft position only),...

After yet, after spending a few weeks with the code looking at winds, you can write flat-out: no one (has the possibility to determine winds) between the stations. You phrase this as certainty and criticism - not as something you're unsure of, not as a question or suggestion - for you it's a fact. Except you're completely wrong of course.

You may believe this is down to some ego problem, but I think there's quite genuine problems in the communication here. Sorry, but I don't have the time or energy to sort that out at any cost. I don't want to spend my time explaining how AW works every time you missed the existence of a function and feel you need to criticize AW when you could have simply looked it up. I don't want to spend half an hour assembling an argument to be told by you 'This is not right.'

Please sleep over it, maybe you can appreciate it then.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Detailed weather does not use metar wind

Postby sanhozay » Fri Jan 09, 2015 10:30 am

KL-666 wrote in Thu Jan 08, 2015 9:53 pm:1) Online aloft wind data like matar
I do not know if this exists, but since metar is live gettable, i reckon aloft winds must be too.

There is a Wiki article describing a method for using online aloft wind data:

http://wiki.flightgear.org/Howto:Fetch_live_aloft_data

EDIT: I didn't try the whole thing, but just tried the URL that would be generated by the AWK script and it would appear it now needs some sort of Jeppesen data plan login.
sanhozay
 
Posts: 1207
Joined: Thu Dec 26, 2013 12:57 pm
Location: EGNM
Callsign: G-SHOZ
Version: Git
OS: Ubuntu 16.04

Re: Detailed weather does not use metar wind

Postby St.Michel » Fri Jan 09, 2015 4:32 pm

I am frankly baffled. How do you imagine, say, an airspeed indicator works? Do you really think the weather system should generate the reading of the airspeed indicator?

How did You get this idea?...
(I think, the weather system has to compute the wind at planes position. So it generates also a part of the IAS.
To do this, I think, local_weather.wind_interpolation(lat, lon, alt) will be called constantly - where [lat,lon,alt] indicates the actual planes position. Because normally systems are encapsulated, we have interfaces and the airspeed indicator do not call the function by itself.)

What I said is, that a pilot has no possibility, to call this function with e.g. [lat,lon, alt-2500] or [lat+25mi, lon-10mi, alt+5400ft] - in order to know the wind there, because this is one of its waypoints. (Not without some skills that are more programmers-like than aviators-like.)
But this would be a weather-forecast, like I have in mind. To show the return-value of local_weather.wind_interpolation(gridPoint_x, gridPoint_y, FL_z) somehow at the map. (And because we normally do such forecast for that flight-level (respectively pressure-altitude), for that we calculate ALOFT-values, we could simplify this to a new function, because we don't need to interpolate in altitude then.)

And this is quite independent from "how to get the ALOFT-values" itself.
The best way would be, to take real-data, I think, because we could plan our flights also with internet-tools then (especially in a wider range). But also to create our own ALOFTs in a wider range around our actual position and have this accessible, would help.

Basically, every time we have some conversation, your goal has subtly changed.

Yes, I try to adapt my ideas to the facts. When e.g. we can't scan a distant terrain, because it is not loaded (and if we could, it would be impossible, because this would slow-down FG dramatically) - then there is no use in edge-detecting by image-processing-methods. (The idea itself is not bad, because to do such tasks in frequency domain is often quite efficiently.) So I'm thinking about a new approach...

The main goal is to have a predictable wind, that can be used for navigational task - this were the first 2 sentences that I posted here viewtopic.php?f=69&t=24538 (and second, to have a more uniform wind field, because of the same reason).
I never would have a "offline-model" - I would know, if life-data will be come soon. And semi-random-values was an idea, to solve or defuse the situation, that different FG-instances have different weather because of using/including random-values by generating it. (And I also never demanded, that AW will be MP-compatible - I've asked, in order to regard this.)

When I say 'the problem discussed here is about low altitude winds' your response was 'but people are interested in predictable winds in any case'. Sorry, but that gives me the distinct impression you don't care what problem we're discussing, you want to make your point anyway - whether it fits the occasion or not.

When low-altitude-winds are right + ALOFTs too + also the method of simulating the boundary layer (and this is what You actually say) - then there is no proper reason, to change something in the interpolation-method. Because when the wind is (more or less) like real wind - and it changes more, then we would expect - then this is a fact, and we have to find a way to arrange.

What I would say was (and is), that this could be more easily possible, when we would (even) know, wich wind is in different altitudes.
(And anyway, above, this is also wrong cited - I've said: "I believe, the idea of predictable wind would please not only me.")

Contrast this with the interaction with KL-666 in this thread. There's an ... experimental changes. And two bugs found on the way. It's a purely professional interaction in addition - no 'this is so bad' and such like. So it's a win-win.

Yes, but my hints will be ignored or not called error. This is sadly not the same situation...
(And I don't mean my 'this is so bad' - what I actually also not have posted - I mean e.g. this viewtopic.php?f=69&t=24538#p224245, viewtopic.php?f=69&t=24538#p224290 or viewtopic.php?f=69&t=24726#p226085)

The situation is deadlocked.
What can I do? Re-register me with a new user-name? Perhaps I try this, sometimes...
St.Michel
 
Posts: 87
Joined: Tue Apr 15, 2014 9:20 am

Re: Detailed weather does not use metar wind

Postby Thorsten » Fri Jan 09, 2015 7:26 pm

Please sleep over it, maybe you can appreciate it then.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Detailed weather does not use metar wind

Postby Thorsten » Sat Jan 10, 2015 12:23 pm

Taking my time, sleeping things over, reading through what you wrote, I find my position unchanged.

The main goal is to have a predictable wind, that can be used for navigational task


We have that - input any wind you line as a series of waypoints, and you'll have a predictable windfield. I've stated that already. So that's obviously not your main goal.

Or write a gui which displays METAR info along your selected route, use the existing functions to extrapolate it to altitude - you get a prediction for winds along your route. That's apparently also not your goal because you continue to talk about modifying the weather system.

There's a multitude of ways you can have a predictable wind (the simplest is to set it to a constant), and you're not happy with the vast majority of them. So it's not clear at all to me what of this multitude you want.

What I said is, that a pilot has no possibility, to call this function with e.g. [lat,lon, alt-2500] or [lat+25mi, lon-10mi, alt+5400ft] - in order to know the wind there, because this is one of its waypoints. (Not without some skills that are more programmers-like than aviators-like.)


First, you said explicitly and actually no one (has a possibility to determine wind) between the stations..

Second, that's a truism. In order to call a function, you need to be able to call a function. You can do it from the Nasal console in 10 second, you can write a minimalistic GUI in 10 minutes, you can make a Canvas GUI within the day or so - the point is, none of this requires any modification of AW, it's GUI work, not weather work. We don't need to have any discussion or any new scheme in order to query an AW function - anyone can do that at his leisure.

So I'll chalk this up as muddling different problems together.

Yes, but my hints will be ignored or not called error This is sadly not the same situation...


So, what's the implication of what you're saying here?

I've had past controversial arguments about FDM (YaSim vs. JSBSim) with KL-666 and I haven't known you at all. Despite our history being a blank slate and some tense moments in the one with KL-666, I for some unspecified reason decided to to treat your bug reports very differently and consistently ignore what you say? Wouldn't you expect that if any of this was for personal reasons, it'd work the other way round?

Or could the reason perhaps be that METAR not registering properly is an actual bug, whereas getting one random number rather than another is not?

So yes, it's not the same situation, and that's because a lot of your claims aren't actually correct as made.

The situation is deadlocked.


Ask yourself why. In your response, I find just more of the very things I told you don't work for me. And I find you continuing to ignore my explanations.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Detailed weather does not use metar wind

Postby Thorsten » Wed Jan 14, 2015 8:49 am

I think the issue of gust calculation not picking up new wind is most important to solve. What i did for now is replace:

Code: Select all
var winddir_last = interpolated_conditions.wind_from_heading_deg;

with

Code: Select all
var winddir_last = winddir;


It might not be completely in line with the logic as intended, but at least it is better than nothing for now.


No, that just breaks the variable direction wind code. It's fairly subtle - as far as I can spot, it'd work fine if you have gusts and some variation in direction, as then the directionally varying winds would on average creep to the new mean (I suspect...) But if the directional variability is zero, then this can't happen.

In any case, I'm on it, but it doesn't seem to be a simple fix, there's something else going on that's producing weird results...
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Previous

Return to Weather

Who is online

Users browsing this forum: No registered users and 4 guests