Flight Question Atmospheric wind effects do not feel right

[Marijn]

My first flights in Orbiter2016 were a bit strange. I found myself ice skating on the runway, moving from side to side due to over-correcting. Worse, during atmospheric flight, I noticed the slip indicator was not in the middle where it should be when flying coordinated turns using stick and rudder. Even during straight flight, the slip indicator (and therefore also the velocity vector) wanders to more than 4 degrees. Even with all controls centered. I was puzzled on what could cause this strange behaviour (and unnecessary drag).

Then I learned about the new Atmospheric wind effects feature of Orbiter 2016 which is turned on by default and I was very happy that it could be turned off. That resolved the issue.

I do have many hours in gliders, and I am totally sure that wind doesn't cause a plane to side-slip. Like a canoe crossing a river with a current doesn't slip either. It's only the ground (or shore) relative to you which moves. The only reason to slip is when you're not using the stick and rudder in the right ratio, or when using thrusters. But wind cannot cause a slip and incur drag.

Actually it could, in some very extreme (and unrealistic) situation where you are suddenly entering a layer with a very different windspeed, the intertia of mass could cause a slip, an acceleration or a decelleration, like an Albatross bird diving behind waves and pulling up again on the open ocean. But that's about it.

It seems to me that the wind is not implemented correctly in Orbiter and that it should be turned off for the best experience.

Off course, I am very happy with this fantastic new version of Orbiter and I am having lots of fun with it. I really hope to have wind as a parameter to take into account when planning a final glide.

I am curious what you people think about this and whether you did switch it off as well.

 

[JMW]

Yep, it's quite strange.

Think Martins included it early on to give a bit of immersion before Orbiter was as awesome as it is now.

 

[martins]

To be honest, the wind implementation in the current Orbiter release is very preliminary and unfinished. I want to revisit and update that component fairly soon.

Maybe this is a good place for discussing the wind implementation.

My idea was that of a 4D LOD system for assembling the wind vector v(r,t) at a given point r in the atmosphere and time t:

You define a 4D grid of a given spatial and temporal resolution covering the planet's atmosphere layer for the desired time period. You use the grid for a basis expansion by defining the basis coefficients V_i of wind velocities at the grid points and find v(r,t) by interpolating the coefficients over the basis functions.

You would use a coarse grid in r and t to define the low frequency spatiotemporal components of v, and use increasingly finer grids for incorporating more local and short-term effects. The total wind vector would be the sum of the components at all resolution levels.

At each level, the coefficients would be assembled as a combination of reasonable physical assumptions (day-night cycles, season cycles, land-water surfaces, surface terrain, jet stream, etc. and a random component. The random part would have a greater weight for the high-frequency components, while physics should be more in evidence for the low frequency.

One requirement would be reproducibility. That is, V_i should always be the same for every simulation run. This requires some thought about how to generate the random seeds. Since you will always only build a small subset of the complete 4D basis V_i, this isn't trivial. One way I could think to do this is to use an encoding of each individual grid point as a seed for the random generator. For example, at resolution n, grid point V_i = V(x_a, y_b, z_c, t_d) could be encoded as S = n*nu + a*alpha + b*beta + c*gamma + d*delta with some suitable constants nu, alpha, beta, gamma, delta, and S would be the seed used for generating V_i. Of course, reseeding the generator for every grid point will result in a not very random sequence, but maybe that isn't a problem.

How to generate the physics-based part of the wind vector is a different question. A plausible climate model may be a bit beyond Orbiter's scope.

Any thoughts?

 

[fred18]

One requirement would be reproducibility. That is, V_i should always be the same for every simulation run.

Is this absolutely mandatory? I think you designed the system absolutely well, and as far as i understood the issue is to reproduce the randomization of local gusts, puffs and wind intensity. If that's the case I don't see much why you want it to be the same at every run, since they are to some extent random events.

I think that once the cilmate model functions are set, therefore the macro wind system is working, local puffs and gusts or stuff like that can be almost-random, and therefore it's not necessary to have them absolutely the same at every simulation run.

If from the functions for example it comes out that on a certain area, on a certain date there is a gradient wind of 20 knots coming from 270*, then the random could be +-10 degrees in oscillation and +-5 knots in intensity, but that can be different at every run in my opinion.

 

[martins]

Is this absolutely mandatory? I think you designed the system absolutely well, and as far as i understood the issue is to reproduce the randomization of local gusts, puffs and wind intensity. If that's the case I don't see much why you want it to be the same at every run, since they are to some extent random events.

I think that once the cilmate model functions are set, therefore the macro wind system is working, local puffs and gusts or stuff like that can be almost-random, and therefore it's not necessary to have them absolutely the same at every simulation run.

If from the functions for example it comes out that on a certain area, on a certain date there is a gradient wind of 20 knots coming from 270*, then the random could be +-10 degrees in oscillation and +-5 knots in intensity, but that can be different at every run in my opinion.

Well as far as cosmetic effects like gusts are concerned that cause some visual shaking effects but don't affect the trajectory, I agree. But for macroscopic effects like general wind speed and direction (even small variations thereof), which will affect the trajectory, it would be good to have reproducibility, and be it just for debugging purposes. If an ascent autopilot works 99 out of 100 times but fails for some particular wind speed, you should be able to reproduce the problem by re-running the same scenario.

 

[fred18]

Well as far as cosmetic effects like gusts are concerned that cause some visual shaking effects but don't affect the trajectory, I agree. But for macroscopic effects like general wind speed and direction (even small variations thereof), which will affect the trajectory, it would be good to have reproducibility, and be it just for debugging purposes. If an ascent autopilot works 99 out of 100 times but fails for some particular wind speed, you should be able to reproduce the problem by re-running the same scenario.

Well, for debugging purposes my 2 cents are that there should be some wind options as far as setup, so people can manually set wind direction and speed (basically for all the planet I'd say). Like some flight simulators: "realistic wind" - "calm" - "custom wind", with the realistic wind developed by global climate functions. Those functions intended to reproduce at large scale some low and high pressure areas based on seasonality, that could be the same year after year, and in local areas night and day breeze, it would be ok as far as orbiter purposes, for me at least.

The point is also another one: if you want to reproduce a fine climate simluation then clouds should be part of it, otherwise you'll lose realism. That's one of the reasons why I'm saying that I wouldn't go in super realism details for this model, but i'd keep seasonality winds "summed" to local winds, some gusts (random) and that's it, year after year.

 

[Abloheet]

Are the wind parameters modelled into the new atmospheric models for Earth, using the atmosphere DLLs, in Orbiter 2016? Then winds can be modelled for the other planets too?

 

[Marijn]

Thank you for your thoughts on this. Reproducibility is indeed important. Planes mostly take-off and land into a headwind because that would give the lowest groundspeed and therefore a shorter runway will do. If reloading a landing scenario suddenly changes the wind then bad things may happen. In the same way a fine-tuned reentry plan could be compromised if the wind is not the same after a reload.

To enrich the Orbiter experience in atmospheric flight, I would suggest that wind affects the flight in the following ways:

-A headwind(component) would decrease the maximum possible glide distance flown across the surface with a given speed and altitude. This maximum distance would require a higher airspeed (lower AoA) in order to achieve the best possible L/D (=glide-ratio in my understanding).

-In the same way, a tailwind would increase the maximum possible distance flown. To achieve the best L/D in a tailwind situation the airspeed should be lowered (higher AoA).

-Wind gradient, which is the typical difference of windspeed at ground level and slightly above ground level, let's say just above the height of nearby trees, hills and buildings at 20 meters or so. A headwind would require an increased airspeed on final in order to prevend a last moment stall due to a sudden decrease of wind and loss of airspeed just before touchdown.

-Wind direction turning clockwise with altitude on a Northern Hemispere (and anti-clockwise on the South). This effect should influence the navigational plan. I do imagine it would be possible to fine-tune lateral distance to a base by choosing a favorable height and associated wind direction to take advantage of.

Wind just describes horizontal movement of an airmass. But in reality airmasses move vertically too. Although these vertical speeds are generally much lower than the horizontal speeds, the effect of vertical air movement on the glide path is quite significant and compares directly to the influence of wind. Implementing one without the other wouldn't be satisfying. With a glide ratio of 8, I would say a 1m/s of sink (of the airmass itself, not the vessel) equals the negative effect a headwind of ca. 29km/h in terms of maximum glide distance. Flying in sink would require an increased airspeed like in a headwind in order to achieve the best possible L/D which can be achieved at that moment, and while in an updraft, airspeeds should be decreased in order to maximize the L/D.

Any particle wants to take the shortest path between a high and pow point. Therefore, one might expect that the direction of wind is perpendicular to the isobars which usually are visible on weather maps , connecting lines of equal pressure. But in reality wind direction is almost parallel to the isobars. I believe this is because of the earth's rotation. I expect this effect to be important for Orbiter.

I do not know whether the glider vessels in Orbiter do have polars associated with them. I mean graphs where horizontal airspeed is plotted against vertical airspeed. Example: https://en.wikipedia.org/wiki/Polar_curve_(aerodynamics)

If so, Then the effect of wind speed on the vessel can maybe (I'am no programmer) be modelled by moving the graph to the left en right for head- and tailwinds respectivly. And in rising and sinking airmass the graph can be shifted up- and downwards. These movements can be combined . So at anytime, the effect of 3D air movement can be expressed as two numbers: shift horizontally and shift verically of the polar. When drawing the tangent from the orgin, the speed for best glide-ratio is obtained by it's slope. What I am suggesting is that wind could possibly be modelled not by defining air movement itself at various locations around the vessel, but by altering certain existing parameters of the vessel itself.

 

[kuddel]

... (I'am no programmer)...

...O.K. But by all other numbers/figures you were using I assume you are a paraglider pilot ("glide ratio of 8"), right?:thumbup:

Sorry for being off-topic, couldn't resist...

 

[Marijn]

Actually I took the value of 8 from the Aerobraking MFD while flying the XR2. That number seems to be fairly constant during all phases of a reenty. I assume that number means the best glide-ratio which can be achieved at the optimum AoA.

I do fly modern gliders with glide-ratio's of 40 or more. A value of 8 would scare me. In some situations, paragliders do actually outclimb a modern glider, because they fly tighter circles at lower speeds in the strongest parts of small thermals. But when leaving the thermals and flying straight and optimizing for distance, they're nowhere to be seen again.

 

[Thorsten]

Disclaimer: I'm the author of the weather simulation in Flightgear (as well as a hobby meteorologist), so I can claim some experience in the area.

A headwind(component) would decrease the maximum possible glide distance flown across the surface with a given speed and altitude
(...)
In the same way, a tailwind would increase the maximum possible distance flown.

I think this can be summarized as aircraft in equilibrium aerodynamical flight move relative to the airmass - so when considering grounspeed or course over ground, the wind vector needs to be added (which is really the same as the initial statement that wind does not induce sideslip). Any correct implementation of the interaction with wind and aircraft does this automatically.

A headwind would require an increased airspeed on final in order to prevend a last moment stall due to a sudden decrease of wind and loss of airspeed just before touchdown.

The boundary layer slowdown of winds is actually fairly complicated and depends on terrain topology and roughness.

I dare say that the effect is of some importance for a glider or a GA aircraft which approach and land with 40-70 kt, but I can tell you from practical experience that you can not feel this for a landing Space Shuttle initiating final flare around 230 kt for anything below storm-force winds - even if you specifically look for the effect (you do notice strong cross-winds somewhat).

-Wind direction turning clockwise with altitude on a Northern Hemispere (and anti-clockwise on the South).

This is a rather theoretical effect - in reality the high-altitude wind patterns are rather different (unlike low airmasses, they're not deflected by mountain ranges, there's phenomena like meandering jet streams and Rossby waves, driving the high altitude high and low pressure systems inverted relative to the ground which have their own wind systems associated (see below) - if you look at actual wind maps, that's not really a good approximation most of the time.

Wind just describes horizontal movement of an airmass. But in reality airmasses move vertically too. Although these vertical speeds are generally much lower than the horizontal speeds, the effect of vertical air movement on the glide path is quite significant and compares directly to the influence of wind. Implementing one without the other wouldn't be satisfying.

That's true for the convective cloud layer (the lowest 1-1.5 km) where you can have localized updrafts of 2-3 m/s (or under Cb clouds even above 10 m/s) , but the large scale vertical movements are much slower than that - the mean vertical movement downward in a high pressure region is of the orders of mm/s if I remember right and does not significantly influence the trajectory of even a glider.

Also, Spacecraft aren't exactly very aerodynamically shaped - the Shuttle technically is a glider, but in equilibrium glide in the lower atmosphere it plunges at ~7000 ft/m or ~36/s - you can't keep it afloat even underneath a thunderhead.

Therefore, one might expect that the direction of wind is perpendicular to the isobars which usually are visible on weather maps , connecting lines of equal pressure. But in reality wind direction is almost parallel to the isobars. I believe this is because of the earth's rotation.

That is indeed due to the Coriolis force acting on the air parcels as they accelerate, and it ceases to be true the closer to the ground you get where friction becomes important.

If so, Then the effect of wind speed on the vessel can maybe (I'am no programmer) be modelled by moving the graph to the left en right for head- and tailwinds respectivly.

You do aerodynamical modeling by evaluating lift, drag and the various pitching, rolling and yawing moments as a function of dynamical pressure and air stream direction. There's no need to move anything because the craft moves always relative to the air layer - only when you start to evaluate performance relative to the ground you get to notice that there is wind.

 

[boogabooga]

Worse, during atmospheric flight, I noticed the slip indicator was not in the middle where it should be when flying coordinated turns using stick and rudder. Even during straight flight, the slip indicator (and therefore also the velocity vector) wanders to more than 4 degrees. Even with all controls centered. I was puzzled on what could cause this strange behaviour (and unnecessary drag).

Are you talking about the flightpath marker of the Surface HUD?

I think what is happening here is that the flightpath marker is showing your vector relative to the ground, not the air. Not the aviation standard, but remember this is a spaceflight sim and Surface HUD needs to work just as well on the moon as it does on Earth. So, my first request for martins would be an option to toggle the Surface HUD between air relative and ground relative flightpath marker.

I second the request that there should be some user-input somewhere regarding how windy the day is- like many flight sims have.

There should also be a weather display somewhere telling you the wind speed and direction when appropriate.

 

[fred18]

I think that the discussion went a bit off topic if I'm allowed to say that:

all the effects on the vessels will be part of the vessels atmospheric flight model, which is already built and working in orbiter, therefore all the effects relevant to tail wind, nose wind, cross wind etc will be automatically correct once the wind is correctly modeled.

Point here is how to correctly build the model.

I again say that regarding that IMO there should be a global climate model with seasonality change, added to some local variation and some random super-local effects (puffs, gusts etc), and that there should be the option of choosing if we want a calm wind, a realistic wind (which basically is already there) or a custom wind, where the user may input that he wants for example wind from 90* at 10 knots with direction variation of maximum 5% and intensity variation of maximum 20% and that's it to me.

 

[martins]

Does anybody know about availability of data for building such a model, i.e. global average wind velocities as a function of location and altitude for

- seasonal variations (e.g. binned into monthly bins)
- daily variations (e.g. binned into hourly bins) after subtracting the seasonal effects

Ideally also the variances in addition to the averages, or failing that, a number of samples of global wind velocities at random time points, to estimate the variances.

(just considering Earth for now)

 

[fred18]

Just found this, don't know if it might help:

http://globalwindatlas.com/datasets.html

 

[C3PO]

Exact reproducability is not going to be important for the "average" user, but essential for some developers.

Would it be possible to use random(ish) local effects (gusts etc.) and then add a [Record local weather]? This way developers can use replays to replicate exact conditions.

 

[Face]

Exact reproducability is not going to be important for the "average" user, but essential for some developers.

Would it be possible to use random(ish) local effects (gusts etc.) and then add a [Record local weather]? This way developers can use replays to replicate exact conditions.

What about procedural techniques, where the seed of the random generator is saved?

 

[fred18]

I still believe that exact reproducibility will come from a stable global and local climate system OR through the custom wind options. Local gusts can be set to 0 to have a ripetitive environment or to a preferred number to see how the systems react to random inputs but that's it. I think that this is how the flight simulator like fsx or others works actually.
If you're checking the atmospheric autopilot and you want to see how it works with wind you can either set gusts to 0 and see if it works properly with seasonal and local winds (which will always be the same for a certain date and time), if you want to see if it works with particular winds (strong crosswind for example) you set your wind custom settings to strong wind from the cross direction. If you want to see if it reacts well to gusts, just put the gusts you want and check, but that's only for moments here and there, once the global system works, it won't be necessary to have the very same gust at the very same moment.

 

[Face]

I still believe that exact reproducibility will come from a stable global and local climate system OR through the custom wind options. Local gusts can be set to 0 to have a ripetitive environment or to a preferred number to see how the systems react to random inputs but that's it.

Well, I know that this is a very weak argument, but such a core feature would be the first I'd advice OMP users to turn off. It would make syncing 2 sessions practically impossible if the one user gets shaken through in a gust while the other experiences no wind at all while flying formations.

 

[fred18]

Well, I know that this is a very weak argument, but such a core feature would be the first I'd advice OMP users to turn off. It would make syncing 2 sessions practically impossible if the one user gets shaken through in a gust while the other experiences no wind at all while flying formations.

that would happen anyway if users choose different wind options (no wind, realistic wind, custom wind). I think it would be enough just to agree among users to set gusts to 0 for realistic, to agree on the custom settings if custom, or simply agree on no wind.