> Well, FlighGear has its own atmosphere model that is also used by the > other subsystems (e.g. instruments, weather reports, visual system, AI > traffic and whatnot). So far there has been few reasons not use that > model also for the FDM. > > I think the FDM only needs to know the atmospheric properties "here > and now" while a whole simulation system such as FG (idealy) needs more > than that (not that we are there yet, but Thorsten R's work is > interesting > and promising). I'd like to see the wind socks reflect the condition at > their position rather than the conditions where my aircraft is > eventually.
The way I understand this, the issues are to some degree separate (?). I believe (correct me if I'm wrong) that what Jon is largely talking about is the altitude extrapolation of atmosphere conditions, i.e. given that I specify pressure, temperature and dew point at sea level, how will these change as a function of altitude. Within some reasonable set of assumptions, you can compute these by solving physics equations. What the weather system does is specify these values *at sea level* as a function of (lat, lon) - the altitude interpolation is still done by the built-in Flightgear atmosphere model, and as far as I know it'd be no problem to use the JSBSim atmosphere for that purpose instead. As far as the properties in /environment/ are concerned (I assume they're used by the FDM...), one'd probably just switch from one function calculating the altitude dependence of pressure from the sea level value to a different one. What is explicitly modelled in the weather system is the altitude dependence of parameters such as visibility which are not the solution of a simple physics equation (you'd need to solve the whole weather system hydrodynamics to know where high-altitude haze layers form...). The temperature dependence of air is somewhere inbetween - there are some simple factors which make it cooler as you go up in altitude, but then airmasses form fronts, and the detailed pattern depends on how these fronts are arranged. I don't think we do this properly as of now, but it's probably not that terribly important. Recently, we also started to model light attenuation in the atmosphere - which is partly due to dust and haze, partly due to clouds - strictly speaking that's also part of the atmosphere model, but in all likelihood not something JSBSim does :-) I don't think an atmosphere model (in the above sense as altitude extrapolation of values specified at sea level) would usually include wind - you can't compute the windfield easily runtime by solving physics, so for all practical purposes it's a vector field which you impose externally. So I'm not quite sure there is a real problem, it just seems to me a semantic issue what parameters are all included in 'atmosphere model'. If you want a windsock which shows conditions at its positions by the way, then just give it some Nasal code which makes it dependent on the results of a function call and I'll supply a function that specifies the wind at that (lat, lon, alt). If you ask for it regularly, you can even drive it in gusty winds... Local Weather has all that info - you just need to ask it nicely - since writing to property nodes is rather slow, I tend to avoid it these days and store most info Nasal-internally. Cheers, * Thorsten ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ Flightgear-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/flightgear-devel
