Global wind models

[martins]

I am currently experimenting with wind - the stuff that tends to blow aircraft off course and turns landings into hit and miss affairs. I don't want to implement this as just random vector fields, but give it at least a semblance of a plausible global field distribution. Therefore, I am looking for reasonable (and reasonably simple) global wind models. For example, mean vector field distributions as a function of

• latitude
• altitude
• season

For a refinement, possibly also

• longitude
• time of day

In addition to the means, possibly also standard deviations on different time scales and "typical" variations (distribution and temporal development of high/low pressure regions and resulting wind patterns).

Does anybody have a suggestion? I came across this paper, which has some useful information to start with. Although digitising the plots would be a pain. Vector field data in electronic format would help a lot. Also the graphs are slightly puzzling me. The vector fields appear to have a strong east/west orientation, with hardly any north-south component. I though the convection towards the equator at low altitudes (and flow away from the equator at high altitudes) was a major component of the global wind pattern. Is the magnitude of this effect so much smaller than the east-west component?

Apart from the global average effects, some models of small scale effects will also be needed. (turbulence, gusts, etc.) What are the (spatial and temporal) correlation lengths, i.e. how rapidly can the vectors change over time and space?

Are there any public-domain global wind algorithms around? What do other flight simulators use?

 

[Urwumpe]

What about making the winds of a planet part of a DLL? Then you just need to care about the interface to Orbiter and how it suits you best for performance, and let other people look for accurate wind models.

I only know of wind maps, but I am sure there are also CSV tables with such data. Anybody knowing a climate scientist to ask?

 

[martins]

What about making the winds of a planet part of a DLL? Then you just need to care about the interface to Orbiter and how it suits you best for performance, and let other people look for accurate wind models.

Good idea. But even so, I'd like to try my hand on at least a simplistic model rather than just wait for somebody else to do it.

 

[Urwumpe]

Good idea. But even so, I'd like to try my hand on at least a simplistic model rather than just wait for somebody else to do it.

Well, you are right, there should be some initial capability in the release.

I have found this paper, but it only covers the oceans and has no data sets, but it gives a few good hints on where to ask questions.

http://w3k.gkss.de/ksd/Publications/Horstmann_et_al.pdf

Ah, there, better... maybe the conditions of use are limiting.

http://data-portal.ecmwf.int/data/d/demeter_mnth/1950/

Data from the projects available on this server is provided without charge and may be used for research and education only. Commercial use of the data is not permitted.
Research is understood as any project organised by a university, scientific institute or similar (private or institutional), for non-commercial research purposes only. A necessary condition for the recognition of non-commercial purposes is that all the results obtained are openly available at delivery costs only, without any delay linked to commercial objectives, and that the research itself is submitted for open publication.
Although every care has been taken in preparing and testing the data, ECMWF cannot guarantee that the data are correct in all circumstances; neither does ECMWF accept any liability whatsoever for any error or omission in the data, or for any loss or damage arising from its use.
Any person extracting data from this server will accept responsibility for informing all data users of these conditions.
Data must not be supplied as a whole or in part to any third party without the authorisation of ECMWF.
Articles, papers, or written scientific works of any form, based in whole or in part on data supplied by ECMWF, will contain an acknowledgment concerning the supplied data.

I would say, this is not in favor of Orbiter, but then, it could be still negotiable.

 

[Zatnikitelman]

I'm not sure how much it helps, but the data generated in the U.S. by our weather models is pretty much public domain. Though mostly concerned with models showing specific forecasts for the short-term rather than overall patterns, you might could try starting at NOAA's model analysis page: http://www.nco.ncep.noaa.gov/pmb/nwprod/analysis/

There are also several colleges here that do atmospheric research and may have some data that's useful. Now I'm not sure if they have restrictions on their use of data however, but here's some of the big ones:
University of Alabama, Huntsville: http://www.nsstc.uah.edu/atmos/index.html
Plymouth State University: http://vortex.plymouth.edu/
Penn State University: http://www.met.psu.edu/
And the University of Oklahoma which has on-campus our National Severe Storms Laboratory, and The National Weather Center (different from the National Weather Service), and while primarily focused on severe weather, might have some useful information: http://ags.ou.edu/

 

[Wishbone]

I have been looking at GRAM recently, which is the model for Martian atmosphere, including winds. Before that, was experimenting with GRIB 2.0 format. The problem is different players will have widely different fidelity requirements. Hence, the interface should be as generic as possible. There should be choice between altitude and pressure level. Time of day can be expressed as elevation of the central star (if you are not planning to relax the constraint on the number of stars in a system), and season as the angle of the planetary body off the equinox (how do you define seasons for Titan, I wonder?)
And yes, the fewer constraints your reference implementation imposes the better for modders. Orbiter engine IMHO should not constrain the storage model for wind/weather data. Extra components may be required in the future (vorticity, shear etc.).

Just my 2 pennies.

 

[kevin580]

Hmm...I love this idea, sounds good

Just my 2 pennies.

I think you mean "Just my :2cents:".

 

[Wishbone]

That was 2 cents or eurocents... I could go with kopecks, y'know. Back on topic: a reference implementation could use 2D FFT internally for northward and eastward (or whatever Martin's handedness convention dictates ) wind components separately, on a very rough grid.

Two Earthly phenomena should be given some consideration: jet streams and tropospheric storms, with some customization/override from within scenarios (sci-fi writers don't like to be forced to use historical weather).

 

[Urwumpe]

I would recommend having the wind models in the atmosphere models and both models be modular... so people could produce generic wind model modules later that can be used for fictional star systems.

 

[Wishbone]

BTW, you can kill me, but please consider negative elevations, in case of launches from nearby the Caspian Sea or Valles Marineris. :tiphat:

 

[martins]

I have been looking at GRAM recently, which is the model for Martian atmosphere, including winds. Before that, was experimenting with GRIB 2.0 format. The problem is different players will have widely different fidelity requirements. Hence, the interface should be as generic as possible. There should be choice between altitude and pressure level. Time of day can be expressed as elevation of the central star (if you are not planning to relax the constraint on the number of stars in a system), and season as the angle of the planetary body off the equinox (how do you define seasons for Titan, I wonder?)
And yes, the fewer constraints your reference implementation imposes the better for modders. Orbiter engine IMHO should not constrain the storage model for wind/weather data. Extra components may be required in the future (vorticity, shear etc.).

Actually, for the module interface I would wash my hands of all these complications and pass them off to the module implementor. The interface will simply query the velocity vector for a given location and time

VECTOR3 Celbody::WindVelocity (time, longitude, latitude, altitude)

How the vector was arrived at is irrelevant to orbiter, so calculating the relevant parameters like solar angle, equivalent pressure etc. is all up to the module; the interface won't impose any constraints at all.

 

[Moach]

my, this is really something!

if i might throw in a quick thought while we're on the subject - what about adding a turbulence parameter to be defined in the same fashion as winds?

a CELBODY module would only need to supply a callback to define a general scalar for "turbulenceness" (and maybe a couple of frequency parameters) at a given lat/lon/alt sampling point...


then this value could be factored in as noise for the wind force... quick and simple (i hope)


just an idea... either way, the CELBODY implementation could account for turbulence and "noise it in" on its own, i guess...

 

[N_Molson]

While it is of little use because I only remember the big lines of it, I read a book 1 year ago that was intitled "Planetary Atmospheres".

There was a study of each known planetary atmosphere, including the gas giants, and the idea was that the model was roughly the same everywhere (east/west alternating stripes of wind).

The axial tilt was a very important factor, with the difference of temperature between the day and night sides.

Therese Encrenaz - Atmosphères Planétaires, origine et évolution

I don't know if it's available in english, though.

 

[Donamy]

could this involve moving cloud patterns ?

 

[Robsoie]

Interesting.
If a wind model makes it into Orbiter, flying in Neptune will take a completely different level of crazy

 

[PeterRoss]

could this involve moving cloud patterns ?

Having some connection between wind and clouds will let us have real sandstorms on Mars! :shifty:

 

[martins]

could this involve moving cloud patterns ?

Dynamic cloud patterns on a global scale is a big ask. Maybe we could start with some more modest applications, like the occasional tumbleweed ball rolling through the picture ... :lol:

Edit:

Seriously though, the wind vector field could be used as a displacement field for distorting the cloud texture map. This is something similar to nonrigid registration frequently used in medical imaging. The difference is that for registration, this is a single, linear operation, or at least a modestly nonlinear operation over a finite range. For clouds this would be a completely nonlinear problem over an infinite range. I.e. you take the vector field to displace the clouds from one time frame to the next, then use the same displacement field on the new texture for the next time frame, etc. This may work over very small time frames (a few hours, unless there are extreme wind speeds involved) but beyond that, the cloud patterns will quickly become invalid.

In addition, coulds don't just move. They also form and disperse, so other factors like temperature, pressure, vertical velocity components, moisture, evaporation and condenstation, etc. will have to be taken into account. This quickly leads to an atmospheric model that is magnitudes more complicated than orbiter itself.

A proper model-based solution like this is beyond the scope of orbiter, but some more hacky approaches could be more feasible (like using multiple cloud maps taken at intervals of some hours, and slowly blending from one to the next. Except for the jump when you cycle back to the first image in the sequence, this may not look too bad).

 

[PeterRoss]

Dynamic cloud patterns on a global scale is a big ask. Maybe we could start with some more modest applications, like the occasional tumbleweed ball rolling through the picture ... :lol:

Well, they say one guy said something about asking something for it to be given Seriously, you'll have to make your windmap discrete anyway, so why not to combine it with cell texturing of cloud layers? (Now they'll tell me I'm speaking some nonsense here...:facepalm: Oh, can a man dream?)

 

[Krikkit]

Edward Lorenz was trying to model global atmospheric patterns when he discovered chaos theory. So needless to say this will be no trivial matter and I wish you the best of luck.

 

[Ripley]

...The axial tilt was a very important factor, with the difference of temperature between the day and night sides...

And land <--> sea mass, too.