#2537 Wind settings in AWS with missing Live Data

[eatdirt]

Let me open a bug report for this one, discussed on the mailing list.

If AWS is engaged, together with Live Data, and, for some reasons, the retrieval of Live Data fails, we get a NIL METAR in the GUI and a warning "Local Weather, Metar not available aborting". The same weather GUI also reports wind of 0 knot from direction 0 degree.

However, the wind in the sim (read from /environment/wind-speed-kt) takes other values, which can be as large as 70 kts on ground. In fact, AWS, in this situation, takes a constant wind value all over the atmosphere, and this value is what is set in the aloft section of Environment/environment.xml at the time you encounter the issue.

Example, you fly above 30000 ft, you get:

 <entry>
        <elevation-ft type="double">30000</elevation-ft>
        <wind-from-heading-deg type="double">340</wind-from-heading-deg>
        <wind-speed-kt type="double">70</wind-speed-kt>
   </entry>

and this remains constant whatever your altitude afterwards.

If you engage BWS instead, then, it starts identically, if you were flying above 30000ft, you get 70 knots of wind, but the wind gets updated to the other aloft entries if you plunge down to the ground (you get 10 knots on the ground).

So for some reasons, AWS gets frozen at the initial set values. On the ML, Thorsten explained:

Let me chime in, because I understand what is going on. It seems to be an unforseen interactions of several factors:

1) BW has a different wind model from AW in that each wind later is specified in the GUI/represented inside the property tree. AW represents the wind layer structure only as Nasal variables, does any altitude and spatial interpolation/shear inside Nasal and writes the result.

2) The default environment entry of 70 kts is hence a reasonable default for BW, because BW would specify lower values at lower layers. However...

3) Due to the initialization altitude of the scenario high up (60.000 ft or so?) - what appears to be happening that in the absence of a live METAR, FG uses the BW default for 60.000 ft as stand-in for a METAR information. Since METAR however specifies ground winds, AW in turn thinks that the wind on the ground is 70 kts and estimates the winds at altitude from there (which'd come out even higher).

So... nobody could easily have forseen that we'd ever want to init at high altitude and run AW, but the step that goes wrong is that the BW default for high winds leaks into the property representation of the current METAR - instead, the ground wind needs to be used in the reported METAR properties and all will be fine.

Checking all metar entries in /environment/metar, they all seem fine and set 0 knot of base-wind-speed, /environment/metar/data="". The flag /environment/meta/valid="false", which also seems ok?

I am wondering if the NIL metar simply forces AWS to quit prematurely thereby preventing any further updates on the wind settings based on current elevation?

Any input welcome!

Cheers,
Chris.

[Erik Hofman]

Looking at the code I think FGEnvironment::_recalc_ne() in environment.cxx is to blame since it does not compensate for altitude in contrast to, for example, FGEnvironment::_recalc_sl_temperature().

[eatdirt]

I don't have the big picture, but it looks to me that Local Weather finds an invalid METAR, with tiles having the METAR type, and then simply abort, so nothing is left to compute anything? (Basic weather is not re-activated).

So, I have found a very stupid workaround, when this is happening, let's revert to basic weather.

Nasal/local_weather/local_weather.nas line 3847

else if ((getprop("/environment/metar/valid") == 0) and (getprop(lw~"tmp/tile-management") == "METAR"))
    {
    print("No METAR available, aborting...");
    setprop("/sim/messages/pilot", "Local weather: No METAR available...");
    setprop( "/environment/realwx/enabled", 0 );
    setprop("/nasal/local_weather/enabled", 0);
    return;
    }

The two new lines are:

    setprop( "/environment/realwx/enabled", 0 );
    setprop("/nasal/local_weather/enabled", 0);

The first disable real-weather-fetch, and could actually be skipped (but it sounds nicer to do so?), the second switch back to basic weather.

I don't know the side effects of doing this but the basic wind aloft layer model enters the game. WDYT?

[eatdirt]

Well, I can say that this is not a nice workaround, because the live data actually fails to retrieve a metar quite often (even with a good internet connexion). And, of course, once in basic weather, it does not come back to live data without clicking on it.

Which, suggests that, possibly, various bugs reported on the forum about unrealistic behaviour on grounds while the wind displayed in the weather window is small might actually be the very same problem!

[Erik Hofman]

So it looks like the weather interpolator is disabled when METAR is enabled but could not be retrieved. Sticking to the last know value. This is supposed to be at 90000ft:

LayerInterpolateControllerImplementation::update
enabled: 0, altitude_agl_ft: 0.105815

[Erik Hofman]

Alright, some success:

If you (re-)enable /environment/config/enabled (after switching to AWS) the wind speeds will get interpolated back to the lower values at lower altitude. This is done in FGData/Environment/interpolator.xml

[eatdirt]

Oh, thanks Erik, I'll toy around with your suggestion!

[eatdirt]

This works quite smoothly for me

else if ((getprop("/environment/metar/valid") == 0) and (getprop(lw~"tmp/tile-management") == "METAR"))
    {
    print("No METAR available, aborting...");
    setprop("/sim/messages/pilot", "Local weather: No METAR available...");
   setprop("/environment/config/enabled", 1);
    return;
    }

The interpolator kicks in with the basic aloft model, AWS remains switched on, when a live METAR gets back and I click on "apply" the prop /environment/config/enable becomes null again.
I'll do more testing to see if that badly interferes with other things, but your idea looks good!

[Erik Hofman]

If this turns out to work correctly it can also be done automatically inside FGData/Environment/interpolator.xml, no need to keep the message box visible then.

[eatdirt]

Cool, I would say just push it on next, it will let time to test it to discover any unexpected side effects!

[Erik Hofman]

Alright, a fix has been pushed which should solve this issue.

[eatdirt]

Thanks Erik. I have tested the new interpolator.xml (copy-pasted on 2020.3.6), unfortunately that does not fix the issue.

The /environment/config/enable is false, the new one /environment/config/livedata-disabled is true but none of the wind entries are updated, locked at 70knots for all altitudes :-/

[Erik Hofman]

That;'s odd, I did test it and it seemed to work properly.

[eatdirt]

Could you confirm that the changes are only in interpolator.xml?

For reproducing, I start a session with AWS and LIVE DATA switched on from a previous session, internet connexion down and then:

fgfs --aircraft=SpaceShuttle-TAEM  --prop:/sim/config/shuttle/mdu-groups=1 --airport=KTTS

The Shuttle starts at 60kft alt, and I monitor /environment/wind-speed-* while the shuttle goes down into the atmosphere. I don't get any change with new interpolator.xml [but I did with the explicit setprop()]

Edit: It seems that the whole interpolator.xml logic is actually ignored, I am still getting the wind interpolator starting only by clicking on /environment/config/enabled (switching it to true) and stopping when it is false. The livedata-disabled switch seems to be totally ignored. Very weird!