Detailed weather does not use metar wind

[Thorsten]

I just wish that somehow the wind direction could get much closer to the airports metar even when close by a very different wind direction metar is passed.

In the situation discussed, the weather system would need to know what airport you actually want to go to know whether halfway between KSFO and KSJC you should get full KSFO or full KSJC weather.

AW wasn't ever designed with multiplayer in mind - I have sketched a scheme how it should be modified to work consistently in MP posted in the forum, but since I don't do MP, I won't work on it and so far nobody else was interested in coding it.

[Thorsten]

And if the answer is 'yes', can I just patch that code myself or is it better to download something from somewhere and then do something with it?

If the question is about the gust fix - that went to GIT, so you'll either get it from there, or on 3.4 or you'll have to patch whatever older version you're using yourself.

[KL-666]

Hi Thorsten,

I found a thread "clouds online" with AW and MP in it. Did you mean that one?

Getting MP involved is way too complicated i think. That is why i was thinking along the line of getting the weather closer to the metar at the client side, when aircraft pack close to each other (on the same airport).

Some issues with extremely near each other airports may be unsolvable. That is a thing one has to live with. But if only generally the weather would move a bit quicker towards the nearest metar, then that would already be a good compromise. When you land somewhere, at some moment the airport you land at is closest. Such moving quicker towards the nearest metar needs only to happen at low altitude and does not need to reflect the metar perfectly, it just needs to be a bit more near the metar.

Possibly the weather gets a bit less realistic at low level (faster changes), but on the other hand every ones weather is more the same at an airport. I do not know which of the two tips the balance. Just sharing this thought, not pushing in any direction

Kind regards, Vincent

[sanhozay]

In the situation discussed, the weather system would need to know what airport you actually want to go to know whether halfway between KSFO and KSJC you should get full KSFO or full KSJC weather.

If the route manager is active, the destination ICAO is easily found and could be used to weight the algorithm?

EDIT: That's the worst idea I've had this year. Simulating local weather conditions based on the destination of an aircraft is ridiculous.

[Johan G]

If the route manager is active...

EDIT: ... Simulating local weather conditions based on the destination of an aircraft is ridiculous.

Good thing you caught it yourself. In addition it would be dependent upon if someone is using the route manager or not...

[Thorsten]

But if only generally the weather would move a bit quicker towards the nearest metar, then that would already be a good compromise.

I guess here you can try whether you find a better solution yourself, it's fairly easy. There's no 'correct' way of doing interpolation between stations. The function you're looking for is

Code: Select all

###################################
# windfield spatial interpolation
###################################

var wind_interpolation = func (lat, lon, alt) {

var sum_norm = 0;
var sum_wind = [0,0];

var wsize = size(windIpointArray);
   
for (var i = 0; i < wsize; i=i+1) {
   
   
   var w = windIpointArray[i];

   var wpos = geo.Coord.new();
   wpos.set_latlon(w.lat,w.lon,1000.0);

   var ppos = geo.Coord.new();
   ppos.set_latlon(lat,lon,1000.0);

   var d = ppos.distance_to(wpos);
   if (d <100.0) {d = 100.0;} # to prevent singularity at zero

   sum_norm = sum_norm + (1./d) * w.weight;

   var res = wind_altitude_interpolation(alt,w);
   
   sum_wind = add_vectors(sum_wind[0], sum_wind[1], res[0], (res[1]/d) * w.weight);   

   # gradually fade in the interpolation weight of newly added points to
   # avoid sudden jumps

   if (w.weight < 1.0) {w.weight = w.weight + 0.02;}

   }

sum_wind[1] = sum_wind[1] /sum_norm;

return sum_wind;
}

and the relevant lines are

Code: Select all

sum_norm = sum_norm + (1./d) * w.weight;
sum_wind = add_vectors(sum_wind[0], sum_wind[1], res[0], (res[1]/d) * w.weight);   


where an 1/d interpolation weight is used - which is a relatively slow fade of the influence of distant stations. You can try to replace that by a more sharply peaked function for instance 1/r^2, or exp(-r), or exp(-r^2) which, as you suspect, gives you more drastic changes at 'edges' of the influence of stations but enforces the winds to be as specified by METAR further out from the station.

Since the interpolation routine knows altitude, you can also make the scheme altitude dependent if you like.

I don't know what works best here - if you find a good solution and it doesn't screw up the experience for me, then I'll be happy to commit it.

One thing one could do do reduce dependence on the direction from which you approach is to poll multiple stations in the vicinity rather than the nearest one and just dump all METAR within 300 km or so into the interpolator. So regardless from where you come, you'd get weather driven by the same assortment of stations.

I found a thread "clouds online" with AW and MP in it. Did you mean that one?

Yes, that's the one. And yes, it's fairly involved. The issue is always that modeling weather 'close' to an aircraft is much easier then across the whole world (think even something as simple as local cartesian coordinate patches vs. geoid coordinates, or continuity of airflow in wind modeling), but that MP weather synchronization somehow requires a near-global solution.

Using METAR helps to a degree here.

[St.Michel]

I think it is less a problem of interpolation between the stations... Perhaps it would be more usefull, to match the METAR-generated altitude-weather a bit?!

Now the wind/weather is derived only from METAR. But if we have a more or less ground-influenced wind (influenced by the real terrain), then it can lead to a very uneven altitude-wind-field.

Example:
We have a "real" western altitude-wind, say 90°.
This will be slowed down by the terrain - and from this depending it also turns because of the coriolis-effect. When slowed down only less (over or near the sea), then ~20-30°. But in hilly terrain with forests up to 50-60°. Say we have a METAR from near the sea, we will have there a reported wind-direction from 70°. The next airport, inland has the same "weather", but the wind is slowed down more, and so we have there 30° reported.
And if we have a terrain, that influences the wind by its shape (e.g. a valley), then the METAR-reported ground-wind perhaps differs much more...

At the moment, the altitude-wind is generated from the METAR-reported ground-wind: re-speed and turn back (by a random-influenced but more or less fixed value).
So it could be more useful, to generate the new alt-wind depending from the actual values. So, that it differs as less as possible. Turn the wind that way, that it matches to the present wind.

Over a METAR-station, that will be more "trimmed" - we would have than a bigger difference alt/ground - but this would (or could) be right. (but for this, we ought to "trim" the right station!)
The problem is, that there seems to be no way to decide, which METAR comes nearer to the "real", uninfluenced altitude-wind. And second, new METAR-stations appears "time by time" (and then, when we are already "nearby") - it would be better, to have this (in a bigger radius) in before, to interpolate a more consistent wind-field. (And so it would be possible, to decide, which METAR is or could be an outlier.)

And interpolating a bigger radius should also lead to more consistent conditions in sense of MP or a weather-forecast...

[Thorsten]

I think it is less a problem of interpolation between the stations... Perhaps it would be more usefull, to match the METAR-generated altitude-weather a bit?!

It's a different problem - he wants a consistent low altitude wind which doesn't depend from which direction you approach an airport.

I agree that your approach to the high altitude winds is a reasonable one, and also that interpolating high altitude winds from a larger number of stations is a good idea. But it won't fix the particular issue that planes on approach, i.e. 5000 ft and below should have a wind that's predictable for the controller regardless where they come from.

If you have one wind at KSFO and one wind at KSJC and you're close to the ground right in the middle, you need to have some kind of interpolation to determine the value you assign. You can vary from a smooth to a patchy scheme, but you need to have one.

[St.Michel]

It's a different problem - he wants a consistent low altitude wind which doesn't depend from which direction you approach an airport.

Yes, I now. But normally we fly over the boundary layer (or at least there, where the wind is not full ground-affected). And would be the alt-wind quite consistent - so then we should have a quite real experience (I hope...). When the wind differs from KSFO to KSJC - so it differs...

The problem is (I think You explained this in that way) - that a new METAR not will be influence the interpolation immediately - because this could lead to a "jump" in wind-direction - but will be "faded in" after a time. But in that case of near airports we are already landed...
But this should be solved, when the next METAR would be "long ago" included. And so we would have a (more or less) predictable wind - regardless from source-direction. Some of the included METAR-stations should be the same then in every case, and so the altitude-wind quite similar. (I mean/hope, that the residual difference should be within tolerable "real" deviations.)

And perhaps it would be also a idea, to interpolate the ground wind, too?...
Near the airport, we should predict wind quite consistent to METAR, but further away, it can (and have to!) vary a lot - especially when METAR differs. Later this can be influenced by terrain info's (so that we change wind-speed and -direction "consistent" with the terrain. And for such a fluctuating wind we can evaluate a new METAR immediately.
So we would calculate a (fictive) ground wind below the plane (on ground!) and interpolate the actual wind then between the alt-wind and this calculated ground-wind (instead of METAR).
(To do such ground-wind-calculation would moreover only nessecary, when flying within the boundary layer!)

[Thorsten]

Yes, I now. But normally we fly over the boundary layer (or at least there, where the wind is not full ground-affected). And would be the alt-wind quite consistent - so then we should have a quite real experience (I hope...). When the wind differs from KSFO to KSJC - so it differs...

I'm not sure we're on the same page here.

Say we have two METAR reports. These are ground winds, i.e. they include the boundary layer effect. If we would know how the terrain in the vicinity of the two reporting stations is, we could (within AW at least) compute the boundary layer effect and deduce the wind just above the boundary layer at both stations.

Problem 1: We can't in general assume we know the terrain at a nearby station because we may not have loaded it (for a whole host of reasons including LOD setting, poor visibility, the station being 200 miles away,...) So we can't really get the winds above boundary layer, we can just guesstimate them.

So then you say that the wind above the two station should be consistent. I think it doesn't have to be - perhaps at an altitude of 10.000 ft that's somewhat true, but I can conceive of multiple situations in which it isn't (think thunderstorm between the stations - low winds would flow into the storm from both sides and high winds would flow away from it).

Problem 2: Even away from the boundary layer, the actual windfield between two stations may be rather complicated - assuming it has a complicated form may be as wrong as assuming it has a simple form.

The problem is (I think You explained this in that way) - that a new METAR not will be influence the interpolation immediately - because this could lead to a "jump" in wind-direction - but will be "faded in" after a time. But in that case of near airports we are already landed...

It takes, I think, 20-30 seconds to fade a point in. You'll be hard-pressed to land by that time...

But this should be solved, when the next METAR would be "long ago" included. And so we would have a (more or less) predictable wind - regardless from source-direction

Yes, as I said earlier, including all METAR stations in a certain radius rather than the past history of closest ones would stabilize things to some degree. Still - you need to find out how many stations are in radius, you need to fade them in once they become active, you need to fade them out,... but this part is doable at least.

Near the airport, we should predict wind quite consistent to METAR, but further away, it can (and have to!) vary a lot - especially when METAR differs.

Yeah - that's what we have right now. We do a spatial interpolation between stations to determine ground winds. So near the airport it will be forced to agree with the reported wind. The question above was what precisely 'near' entails - KL-666 basically asked whether we can extend 'near' to a larger radius around the station. Which I think we can by changing the function giving the weight to a point.

So we would calculate a (fictive) ground wind below the plane (on ground!) and interpolate the actual wind then between the alt-wind and this calculated ground-wind (instead of METAR).

So we're interpolating the wind between a fictive aloft wind and a fictive ground wind then, i.e. we just don't use METAR and make it up? How's that supposed to lead to the correct reported wind at the airfield?

I think you're not appreciating the problem in your approach. We've got two data points, ground wind here and there. We have limited knowledge of the lay of the terrain. To derive a realistic wind distribution from such sparse data set isn't possible. You can make a simple scheme or a complicated scheme, but they will be both similarly unrealistic. You can't get a complete 4-dim function from two points, the math just doesn't work out that way.

[KL-666]

Hi Thorsten,

The field of multiple metars is a nice idea. Possibly it can also be used as a "natural" fading mechanism. While moving (flying) new metars come into and others go out of the field, the remaining metars in the field will keep the effect low of entering and leaving, until more of the like metars have entered the field.

I just see two drawbacks:
- the weather may become rather bland, being always the mean of several metars
- everyone will have the same weather at an airport, yet the wind need not match the airports metar wind (thinking of atc and atis).

At the moment i am experimenting with the code you gave me. Trying this:

Code: Select all

    var agl = getprop("/position/altitude-agl-ft");
    if(agl < 5000){
        if(agl < 500){agl = 500;}
        d = d^(5000/agl);
    }
    sum_norm = sum_norm + (1./d) * w.weight;


The idea is to gradually fade out former metars faster, the lower you get. From 5000-2500 ft you go from d to d^2, from 2500 to 500 ft the fade out speeds up to d^10. At the airport i get with this wind very close to the metar wind.

While test flying i noticed something odd. Entering a metar with gust does absolutely nothing with the wind. Also not when landing. It stays at the direction of the wind before entering the gust metar. Then i looked at the code again and see something odd happening. In all cases in the loop you use winddir, which i see as current/new wind. But in case of gust you use interpolated_conditions.wind_from_heading_deg, which i see as old/current wind. So in case of entering a gust area you never get new wind.

If i take for all iterations winddir as basis for calculations, i do get a similar effect entering a gust metar, like entering any other metar: gradual change.

Code: Select all

winddir_last = winddir;

Is there a reason why you want to keep new metars wind out of the calculation when a gust area is entered?

Kind regards, Vincent

[Thorsten]

Is there a reason why you want to keep new metars wind out of the calculation when a gust area is entered?

No, it's almost certainly not intentional. The gust code came after the METAR code (I think) and since I hardly ever use real weather or METAR input, I must have missed on testing that the combination doesn't play nice even if each bit individually does.

[St.Michel]

At the moment, we have two METAR reports (that can differs a lot) and compute from this two ALOFTs (that then also differs a lot).
This leads to the problem that we try to solve.

My idea is, to generate a more consistent altitude-wind-field (like described) - and I hope, although the METAR from station to station differs a lot (what they are doing because this are real measured data) the wind over the station does not (much)).

(You say, there could be more complicated cases - like thunderstorm. But perhaps this is not a typical situation; and leads also in "real life" to not very predictable winds... For a first step I would assume, that the alt-winds are more or less uniform.)


@ KL-666
The idea of " field of multiple metars" is less, to calculate the ALOFTs as average from this field. The altitude-wind-field also changes by position and is "linked" to the ground-wind. We have "to keep" this linked variation.
Ideally we would have alt-wind-direction (fictive path W-O): 240,250,255,270,280,... (because of shape of the cyclone), and speed from ~20-30kn
On ground the wind is slower and turns, say (ideal): 210, 220, 225, 240, 250 and ~15kn

What we do now, is: to take this METAR-values and reconstruct the alt wind (by taking this "knowledge) - turn ~30° and speed x ~2; so we should get a uniform alt-wind-field:
233, 249, 256, 270, 282, ...

But the problem is: The real ground wind can differ a lot, say we have METAR-reports: 210, 223, 190, 230, 249
and so the reconstructed alt-wind will be also non-uniform. The idea is, to turn and speed up the values in that kind, that we get a preferably uniform wind field: identify the 190° and turn more at this point. (Perhaps at 190° the wind is also considerable slower: then the reason is (maybe) the terrain-roughness, if not, then perhaps the terrain-shape... And of course, the reason could be a "real" anomaly, but - how your linked wind-map shows - normally it is quite uniform, http://earth.nullschool.net/#current/wi ... 30.99,2011)

(For me the incitement is: An uneven wind-field can disturb navigational tasks - when you try to calculate the wind drift. So I need for this a predictable wind.)

When the wind differs from KSFO to KSJC - so it differs...

I'm not sure we're on the same page here.

When we fly from KSFO to KSJC and they report different ground-wind - so the wind have to change by time (in real life and FG, too!).
When the alt-wind is the same (what normally should be about this 25 miles), the difference should occur only at the boundary layer and is caused by the terrain.

I would predict, that the wind will not continuously change along the path:
It should be quite uniform over the bay and than change abrupt over the baylands and than over the urban terrain again - and this could be simulated by scanning the terrain (water / flat land / city).
But also without such scanning we can predict, that along the path the wind changes from time to time in a rather abrupt manner (in an interval given by the METAR-reports).

Yeah - that's what we have right now. We do a spatial interpolation between stations to determine ground winds.

I thought, we generate (sometimes quite different) ALOFT-values over the METAR-stations, interpolate from this the wind at the planes lon/lat position (in this case interpolate the values from the 5000ft-layer) and take this as input-value to calculate the ground-effected wind (depending from planes altitude).
If not, that is the way like I mean.

So we're interpolating the wind between a fictive aloft wind and a fictive ground wind then, i.e. we just don't use METAR and make it up?

We use METAR - for both!
The fictive ALOFT-value from a (hopefully) quite stable wind-field - and the fictive ground wind as a simulation of a quite uneven ground influenced wind. This is (like I think) a quite properly modeling of the real conditions. And when we come down, the wind will then change from stable to uneven conditions.

The reported wind at the airfield itself will not be changed! If we come close to the airfield the wind is more and more like reported.
(And so we also don't ever need to scan the terrain round the airfield. The wind there is always like reported! This would only be needed for a better calculation/prediction of how the ALOFT-value differs from the METAR-value (trying to calculate more consistent alt-winds). To calculate the ground wind at planes position, we have to scan at its position (- and I hope, this will always be loaded? also without visibility? - but without this, we don't have to sync this...) That it seems to be impossible to scan a not visible, distant terrain I have understood...)

It takes, I think, 20-30 seconds to fade a point in.

I mean, You said this can take 10 minutes?...
But if so, and the "old METAR" is already far away and the new one differs a lot - the interpolation leads to a jump in wind-direction and -speed? (This is, what I sometimes notice.)

[St.Michel]

An additional reason could be:
The (altitude) wind speed depends from the pressure difference, the pressure gradient. So we would have another criterion to "predict" the wind. But normally at startup we have only one METAR-report, and we can't calculate a difference.

Is there somewhere a "piece of code" or a tutorial, that describes, how to get such distant METAR-reports?

[Thorsten]

I mean, You said this can take 10 minutes?.

No, I didn't.

Here's the problem in a nutshell:

You have this:



You want this:



Sometimes they're similar. Sometimes surface winds are just randomized high altitude winds and a strong variation of surface winds is underneath smooth high altitude winds. Sometimes a strong variation of surface winds correlates with a strong variation of altitude winds (especially close to a low pressure whirl). Sometimes you see coriolis deflection. Sometimes you don't - even over the flat mid-west, the flow lines coincide.

How, short of solving fluid dynamics, do you want to get all these cases? Averaging METARs for high altitude winds gives you sometimes a better answer than taking a single METAR, sometimes a worse answer. You can devise a more complicated scheme than the current one, but you'll still get it wrong regularly because the atmosphere is too complicated to do it in real time - they're using hour-long runs on supercomputers to get the above plots.

But the problem is: The real ground wind can differ a lot, say we have METAR-reports: 210, 223, 190, 230, 249
and so the reconstructed alt-wind will be also non-uniform.

But in many cases that's real - see the wind maps.

I mean, you're talking a non-existing algorithm here which can somehow take out the terrain effect on the wind in real time. I'd like to see that algorithm before we discuss what we can do with it. And I'd like to convince myself not only that it is possible to come up with an algorithm which is more complicated than what AW has now, but with one that's actually better.