Recently we have seen a lot of codes used to unlock our products being offered for discounted prices. Almost all of them are bought using stolen credit cards. These codes will all be blocked by our systems and you will have to try to get your money back from the seller, we are unable to assist in these matters. Do be very careful when you see a deal that is almost too good to be true, it probably is too good to be true.

Jump to content
Sign in to follow this  
B21

Using FSX terrain for ridge lift calculation

Recommended Posts

My analysis work on the 'ground elevation probe' technique to derive ridge lift from the live FSX terrain around the user aircraft is completed and I've spent a few days documenting the approach:

Efficient simulation of topographic lift in FSX

This work is complimentary to the work Peter has done on CumulusX! and we should see if the code can be combined.

I would imagine the possibility of a pure module in FSX with no user interface that quietly applies ridge lift throughout the landscape which would co-exist with CumulusX! providing thermals and Cu's, without needing CumulusX! as a pre-requisite, AND/OR the the technique could be programmed into CumulusX! as a fallback for it to use when no slope file is available.

However, I was surprised and disappointed to find out that simconnect provides no simple mechanism to apply lift to the user aircraft - if 'AMBIENT WIND Y' could be controlled via simconnect this ridge lift module would now be complete. Peter has done some outstanding work in working around this limitation and controlling the aircraft altitude directly, and for FSX as far as I can see CumulusX! is going to be the *only* simconnect code that injects dynamic lift into the simulator. For the next version of FS I'm guessing simconnect lift injection will be simple.

Seasons greetings...

Ian

Share this post


Link to post

Hi Ian,

I read your nice article about slope probing, and it looks quite promising. It should be possible to create a client data area on the SimConnect server to exchange lift information. I could request lift from the probed slopes from there and integrate it into the CumulusX!-engine.

Yet I'm still a bit curious if it would result always into a a reasonable behaviour. You may remember that in an old post, the look-windward consideration was already there, but I remember that it could sometimes produce paradox results.

My other question is about the slope-to-lift transfer function. You have chosen for a modified atan-approach, which I cannot follow in all details.

What I understand is, that in a first instance using the tangens of the vertical slope angle for obtaining the vertical wind component would result in a flow truly parallel to the slope surface, so that the aircraft would not drift into the ridge, even without correction angle.

On the other hand side, at steep slopes, the lift will be unnaturally strong, because of the fact that FS(...X) holds the horizontal wind component constant, even in case of a vertical wall of rock. The wind "blows" through. BTW, a 90° value can not occur in a usual slope data base, because the base distance is always 3", thus not zero.

I made the compromise of a sin-approach using the true slope angle, which will give you a reasonable, yet weaker, ridge lift, but requires you to correct in windward direction. At flat slopes the difference is minimal anyway.

So my basic lift function is:

vertical wind = cos(wind_dir - slope_dir)*sin(slope_angle)*wind_speed

where

slope_angle = atan(dh/dx), dh being the difference in elevation and dx the distance on ground. However, I do not calculate this ion my own but take it as given from the slope-data-base

My last question is that factor of 4 in the formula atan(4*x/y)/2, which is partly compensated by the division by two. In effect, when applying the sine-function for obtaining the vertical wind component, the lift at flat slopes would be approximately two times stronger than expected from geometry. Is that reasonable? Maybe my lift production is too weak at flat slopes. At least I recognize the great fun with the lift from original CCS2004-slope-data, which have a similar effect. In CumulusX! I realize similar effort to stay aloft as in reality at typical weather conditions. I thinks it's really worth a discussion.

There is already some confusion in the format of the slope-data files because of the various origins. CCS2004 indeed emphasises flat slopes, too. The majority of external data sources apparently promote a pure geometrical approach.

My first preference actually would be, to keep the slope-data purely geometrical and make all adaptions in the transfer function of geometry-to-lift.

best regards,

Peter

Share this post


Link to post

Hi Peter - I agree it's an interesting problem - I've commented on your questions/points below:

What I understand is, that in a first instance using the tangens of the vertical slope angle for obtaining the vertical wind component would result in a flow truly parallel to the slope surface, so that the aircraft would not drift into the ridge, even without correction angle.

I'm not sure I understand this question, but possibly you are not taking into account the fact that sampling the ground into the wind (i.e. taking the slope in *that* direction, not keeping the natural (steepest) direction of the slope, is analagous to your cos(wind_dir-slope_dir) function. I.e. if the natural slope is parallel with the wind, the into wind slope will be zero. It is simpler to think of the approach as the natural process of the vertical component of the wind being affected by the land that wind has actully just flown over, even if that is parallel to a ridge. I.e. it is (nominally) irrelevant to the vertical component that there is a slope off to one side or the other. Drift one way or another is unaffected in any approach as we're only affecting the vertical displacement of the glider - maybe I didn't understand this point.

On the other hand side, at steep slopes, the lift will be unnaturally strong, because of the fact that FS(...X) holds the horizontal wind component constant, even in case of a vertical wall of rock. The wind "blows" through. BTW, a 90° value can not occur in a usual slope data base, because the base distance is always 3", thus not zero.

Well, the atan function asymptotically approaches pi/2 as slope approaches infinity, so I don't think the issue is the concern you're thinking of which is what would happen if we used pure slope as a factor for lift. Really it comes down to a comparison of the behaviour of the two approaches for various slopes, and I produced a chart of sin(atan(x/y)) versus atan(4*x/y)/2 :

slope_calc.jpg

I think both approaches are reasonable - in the first instance I didn't notice that you had atan already in your formula as slope_angle and came up with the entire function using atan independently. The 4x multiplier for gentle slopes comes from my testing in FSX of the Appalacian ridge near Blairstown, New Jersey that I have flown for a few years - real world slopes are not very steep, but they still work quite well in moderate winds. The linear /2 factor is fairly irrelevant as my subsequent 'lift factor' calculations have linear multipliers which I'd expect to adjust after testing.

In general I'm wholly supportive of *not* making the lift stronger than it should be, and the terrain formulae I've given would need to be tested and adjusted after flying in FSX. The way CumulusX! already decreases the lift as you get higher AGL is a fantastic improvement.

I need to fly with CumulusX! some more to give you better feedback on the current ridge lift - should I assume the slope lift value in the debug window is the lift being applied to the aircraft, and is it still valid in slew mode when stationary? It doesn't seem to correlate with the vario, although I have installed your update.

I'll look into the 'client data area' functionality - I've seen it in the docs and would think it'll be very simple. An idea - how many samples is the current slope calculation based on and how far from the user aircraft are they? Maybe for FSX I should give you a slope angle and direction rather than a lift calculation, to keep things common with/without slope files.

regards - Ian

Share this post


Link to post
how many samples is the current slope calculation based on and how far from the user aircraft are they?

Update - I looked at the CCS2004 user guide and the slope calculation is on a 3" (3 second) grid, i.e. four points about 100 metres apart. A *triangle* can be guaranteed to have its points on a plane but an area bounded by *four* points is more likely to be a hump or a saddle, i.e. there's no definite calculation of the slope of a four-point 3D surface as the four points are unlikely to be co-planar... my guess is there's a simplification that effectively turns the rectangle into a triangle, e.g. by averaging two of the points (if the four points *were* co-planar this would change the slope).

My ground sampling code as-is can be configured to sample points 50 meters NW, NE, SW and SE of the aircraft and I can write the code to calculate slope magnitude and direction from that. I'll compute Slope Angle (degrees) and Slope_dir (degrees) and see how they compare with the numbers CumulsX! is displaying. I note from the debug window that Slope Angle is always positive and Slope_dir always points towards the *downwards* direction.

I read up on the simconnect client data and we simply need to agree the data area format (and name).

I wonder if the odd results you got from the 'barrel' probe were related to the issue of needing to give FSX some processing cycles before asking for the ground elevation after the move ? You certainly get erroneous results if you request the ground elevation of the probe *immediately* after the setdata call. But there could be other issues I haven't found yet...

regards - Ian

Share this post


Link to post
I'm not sure I understand this question, but possibly you are not taking into account the fact that sampling the ground into the wind (i.e. taking the slope in *that* direction, not keeping the natural (steepest) direction of the slope, is analagous to your cos(wind_dir-slope_dir) function. I.e. if the natural slope is parallel with the wind, the into wind slope will be zero. It is simpler to think of the approach as the natural process of the vertical component of the wind being affected by the land that wind has actully just flown over, even if that is parallel to a ridge. I.e. it is (nominally) irrelevant to the vertical component that there is a slope off to one side or the other. Drift one way or another is unaffected in any approach as we're only affecting the vertical displacement of the glider - maybe I didn't understand this point.

This is probably a misunderstanding. What I meant was, that when you analyse the resulting windvector in a vertical plane oreinted into wind direction, than the stream lines are in parallel to the slope surface, when you use a tangens-function of the slope angle (maybe better: inclination) to obtain the vertical component of the wind. This means that only little windward steering correction is need by the pilot to avoid drifting into the slope. If you use the sine-function, than vertical wind component is too little and the streamlines are ending on the slope surface, sometimes meaning a strong drift towards the slope and requiring for a significant correction angle. As an example in case of a vertical slope, the stream lines are only pointing up in 45° rather than 90°. On the other hand side, the tanges would produce an infinite lift, since FSX does not consider any barriers, reducing the horizontal component.

Of course, the cosine-effect of wind-direction and slope-orientation is already considered by all approaches, and your's as well.

My ground sampling code as-is can be configured to sample points 50 meters NW, NE, SW and SE of the aircraft and I can write the code to calculate slope magnitude and direction from that. I'll compute Slope Angle (degrees) and Slope_dir (degrees) and see how they compare with the numbers CumulsX! is displaying. I note from the debug window that Slope Angle is always positive and Slope_dir always points towards the *downwards* direction.

I read up on the simconnect client data and we simply need to agree the data area format (and name).

Correct. I propose you to make a suggestion. Maybe its even configurable in cumulusX!. I think its best, if a simple lift parameter in double is provided here, because I think it could be most consistent to encapsulate the slope detection and evaluation at a single place, and the interface is easy. Then I have only to select if either the slope data base lift is used or the lift from the client data area.

I wonder if the odd results you got from the 'barrel' probe were related to the issue of needing to give FSX some processing cycles before asking for the ground elevation after the move ? You certainly get erroneous results if you request the ground elevation of the probe *immediately* after the setdata call. But there could be other issues I haven't found yet...

I'm not sure what you mean. Ah, my experiment put the barrel initally airborne intentionally, because I was considering it as another way to produce clouds. The problem for the moment is, that they would simply fall to ground. It would be good to know if there is a timing problem at all, anyway.

Below, you see a comparison of the three models, whereas for CCS2004 the difference that happens already with the creation of slope codes is considered. Then the CumulusX! model which ispurely gemoetric, except from the effect that is uses the sine-function rather than tanges, and finally, the atan(4x/y)/2 approach, though not considering the superposition of the four slope factors.

best regards, Peter

PS: CCS2004 applies only half the sink at 180° wind, being very forgiving to those flying into lee side.

post-176-1198957032.gif

Share this post


Link to post

Ian,

Maybe a stupid question, but does your "4-points approach" for calculating the slope-angle by scanning the ground-altitudes aside the aircraft also work when the direction the aircraft is flying is not parallel to the ridge? In other words: when flying upwind over a ridge in a 90 degrees angle, does the airplane get sink in the lee of the ridge and lift when I am over the top. As far a I understand your approach in this case the 4 points will calculate equal altitudes and so no lift will be produced.

Please feel free to call me a ignorent fool if I am wrong. In fact I hope I am wrong, because I'm excited about your and Peter's work so far.

Greetings,

Bert

What a night sleep can do to a person: Never mind, I reread the article and saw that the 4 points are measured upwind and downwind of the user-aircraft. So the approach should work in any direction the airplane flies.

Share this post


Link to post
What a night sleep can do

Hey well done - I actually think the approach has some subtleties to it so wouldn't assume it's obvious from first read. Calculating the slope natively in the windward direction is a significant simplification device which has some fundamental merit - that is the land the wind is flowing over to effect the plane. Once you grasp the concept it's easy to imagine other samples that might improve the simulation, e.g. a sample in the direction of flight which would give early warning of you approaching a gap in a ridge. The point is it's so few samples because you're only trying to calculate the ridge lift at a single point (the user aircraft) it can be very efficient. I started with the basic idea of one sample at the user aircraft and one 500m into wind, and then added the others. I very much wonder whether my 'main' lift being based on the slope out to 1000 meters upwind, and the other probes modifying that value, might be looking too far upwind - CumulusX by comparison is looking a max of 100m upwind.

Peter re 'infinite lift' I get your point that the FSX wind still flows at the same rate horizontally so you'd need an infinite climb rate to avoid a vertical slope, but I don't see any material difference between sin(slope angle) and atan(slope) in that regard - for a slope between +/- infinity they both produce lift factors between fixed limits (1 and pi/2 respectively). So it's just a debate between which produces the most effective formula for lift. *Unless* you are adjusting the X & Z position of the plane as well as Y (vertical).

Thanks for the charts comparing the functions - the difference between the upper and lower limits is ok because that can be factored out but the conceptual model leading to the right choice of function is interesting. I'll think more about it.

I'll produce a version of my sim_probe that produces a lift value in a client data area, with a client program to display it. My thought is

Struct RidgeLiftData {
  double lift,        // lift (meters/second) to apply to user aircraft
  int status,         // status of sim_probe module (0=ok, 1 = general error, others = reserved)
  double version, // version of sim_probe software
}

Happy New Year,

Ian

Share this post


Link to post

Hi Ian,

find below a code snippet realating to the saddle/hump problem

Update - I looked at the CCS2004 user guide and the slope calculation is on a 3" (3 second) grid, i.e. four points about 100 metres apart. A *triangle* can be guaranteed to have its points on a plane but an area bounded by *four* points is more likely to be a hump or a saddle, i.e. there's no definite calculation of the slope of a four-point 3D surface as the four points are unlikely to be co-planar... my guess is there's a simplification that effectively turns the rectangle into a triangle, e.g. by averaging two of the points (if the four points *were* co-planar this would change the slope).

Dim dy As Double = cellsize / 180 * PI * 6380000 * Cos((j * cellsize + yllcorner) / 180 * PI)

Dim dx As Double = cellsize / 180 * PI * 6380000

Dim dh1 As Double = ElevationBuffer(i + 1 + ncols * (j + 1)) - ElevationBuffer(i + ncols * j)

Dim dh2 As Double = ElevationBuffer(i + ncols * (j + 1)) - ElevationBuffer(i + 1 + ncols * j)

Dim x As Double = -dy * dh2 - dy * dh1

Dim y As Double = dx * dh1 - dx * dh2

Dim z As Double = dx * dy - dx * -dy

Dim slope_dir As Integer = Int((Atan2(-y, x) / 2 / PI * 16 + 16.5) Mod 16)

Dim slope_angle As Integer = Int((Acos(z / Sqrt(x ^ 2 + y ^ 2 + z ^ 2)) * 2 / PI * 15 + 0.5) Mod 16)

dy, and dx are the edges of a patch at the position of interest. dx is pointint to north, dy to west, resulting a right hand coordinate system. yllcorner is the lower left latitude of the slope tile, being used, j the row from which the current sample is taken. ElevationBuffer is a flat structure containing the elevation data starting from lower left corner, row by row (meaning the index i adresses the longitude).

I'm considering to vectors, one from the lower left corner of the path to the upper right with an elevation difference of dh1, the other from the lower right to the upper left. In hact those are not fully orthogonal, but they are non-colinear anyway.

If the four points are coplanar, then all is very well. If not, the two vectors are not intersecting, because there is an edge dividing the patch into two non-coplanar sub-facets. In the worst case, it's even a ridge. Then the tow vectors are sitting on different planes. Simply disregard this, and proceed as if these are connecting at the starting points, being now coplanar on a virtual plane.

Now I form the vector product, giving the normal vector of this plane. The x/y parts form the projection into the ground plane and thus atan2 the negative orientation (because dy points to west), the z-part represents the vertical projection and the cosine of the inclination, because a vertical normal means an inclination of zero.

These are casted into two integers from 0-15, which are later tranformed into hex cyphers.

What happens now with saddles and humps? You may consider the procedure as is shifting a pair of diagonal coordinates vertically until the corners are coplanar again. This means that you obtain a sort of average effect of the two vertices of the two sub facets of the patch. This is not bad, if it is simply an edge in a slope, which is monotonous, otherwise. In case of a ridge, it's a bit worse. Then you may have too weak lift (or even sink) when you are still on the windward side of the ridge, or vice versa on the lee-side. Actually, this is the best you can do unless you want to split the matrix again with twice the number of parameters. Still one could consider, to calculate the normal vector even online, thus not using a slope data base at all, rather than the elevation data base, or from your probin approach. In this case you could easily distinguis betwenn the different facets.

Peter re 'infinite lift' I get your point that the FSX wind still flows at the same rate horizontally so you'd need an infinite climb rate to avoid a vertical slope, but I don't see any material difference between sin(slope angle) and atan(slope) in that regard - for a slope between +/- infinity they both produce lift factors between fixed limits (1 and pi/2 respectively). So it's just a debate between which produces the most effective formula for lift. *Unless* you are adjusting the X & Z position of the plane as well as Y (vertical).

Actually the maximum effective wind deflection with sin(slope angle) is only 45°. However I admit, that after trying myself some well known slopes (Oerlinghausen 16kn/210°, Weinstraße, 16kn/280°) I come to the impression, too, that flat slopes seem to be a bit weak. It was possible to stay aloft, nevertheless, but in reality I would have taken the next place to land out. I could consider an exponent approach like something of (sin)^0.x, which would emphasize flat slopes, too, while leaving the maximum constant.

Yet I don't have personal experience in these two regions. It would be nice to have some more reference, and of course a good explanation. Perhaps we are not wrong at all, at the end.

best regards,

Peter

post-176-1199307690.gif

post-176-1199307723.gif

Share this post


Link to post

Thanks Peter - I've just seen your post and will digest it. I'll need to work out if it uses more than four samples somehow so you can tell whether the rectangle has a ridge across the high corners or a valley between the low - with only four samples I don't think this is possible.

Can you confirm you have the expectation that my sim_probe will calculate the lift value for ridge lift derived from the FSX terrain and wind and pass that to CumulusX!, rather than passing the slope?

I've modified slightly the lift calculation formulae (without changing the basic principle of using slopes calculated at various distances upwind and downwind of the user aircraft). The formula still requires tuning, but I've attached a run-time sample of ground elevation and derived lift below. Please note at this stage do *not* be concerned with the absolute value of lift/sink (it's scaled a bit low currently) but just look at the relative values at different points in the terrain. This chart was produced by slewing at 50 meters per second (~100 knots) perpendicular to the ridge and sampling the ground elevation once-per-second, and recording the elevations returned by the probes and the calculated lift at ground level.

run-time_sample.jpg

At this stage, the illustration confirms that the ground sampling technique does produce stable results and we can derive from it a usable lift value. The formulae used for lift calculation still need tuning - this is *not* the final version!

Right Peter - now I'll go back and read your post really carefully...

Thanks - Ian

Share this post


Link to post

okeydoke - I've now read your post more carefully and understand there's an effective averaging for the saddle/hump problem - this was the bit I was unsure about - thanks for the formula.

I'm sorry I don't understand how sin(slope angle) maximises at 45 degrees (instead of 90) - I've obviously misunderstood your calculation in some way. EDIT: Yahayy I've seen the light! You mean that even if the sin function maxes out at 1.0 (for a slope of 90 deg), producing a lift equal to the windspeed, the glider will still be carried aloft at the angle of 45 degrees. i.e. up at the windspeed and downwind at the windspeed. Yup fair enough. I understand this means the yaw angle will be wrong for a glider flying parallel to a ridge with particularly steep slopes. But for common ridge-soaring slopes (30-60 degrees) and wind of ~ 20 knots there won't be much of a discrepancy. END EDIT.

Regarding the slope lift factor, I've been experimenting with sin(atan(4*slope*slope)*sign(slope) - the blue line below, with the plain sin function in pink:

sin_atan_4xslope_squared.jpg

The idea of the function is

(a) to normalise the maximum to 1 rather than +/- infinity for the slope, or +/- 90 degrees for the slope angle - this is particularly helpful to my use of four probes as I can be clear each one produces a factor in the range -1..1.

(B) to pretty much maximise the lift at a slope of 45 degrees reasoning that steeper slopes do not give much better lift

© actually to *reduce* the lift at a slope angle below about 10 degrees to mitigate the appearance of lift spots on otherwise fairly flat land.

I actually produce FOUR lift factors, based on slopes to each of the upwind/downwind probes, and another area of experimentation is the appropriate distance for each probe and the weight to apply to each. At the moment I have the probes at -250, 0 (user aircraft), 250, 750 and 2000 meters (these distances are shorter than before).

I'm testing a hypothesis that lift should max out at half the wind strength, so consequently the weights of my four lift factors should add up to 0.5. There is a subtelty in that my downwind probe only ever contributes a *positive* factor, i.e. it is zeroed if the downwind slope would otherwise produce a negative factor, and the far upwind slope only ever contributes a *negative* factor, i.e. it's zeroed if it goes positive. The reasoning for the latter is upwind high ground will reduce the lift at the aircraft, but lower high ground a long way upwind doesn't improve the lift.

I'm testing on the Appalacian ridges near Blairstown, New Jersey which I've flown for many years.

Regards - Ian

Share this post


Link to post
Can you confirm you have the expectation that my sim_probe will calculate the lift value for ridge lift derived from the FSX terrain and wind and pass that to CumulusX!, rather than passing the slope?

Definitively. That's the most simple interface. Otherwise we would do algorithm development at two places, because I had to implement your findings first and make sure they do not get extra bugs from my side.

(a) to normalise the maximum to 1 rather than +/- infinity for the slope, or +/- 90 degrees for the slope angle - this is particularly helpful to my use of four probes as I can be clear each one produces a factor in the range -1..1.

No problem.

(B) to pretty much maximise the lift at a slope of 45 degrees reasoning that steeper slopes do not give much better lift

Is it? This might be explained by an article I found yesterday partly about orographic flows (in German), which indicates, that at certain conditions flows go around rather than over a mountain area.

Look at http://www.wetteran.de/knowledge/orographi...ecipitation.htm and a link to : http://www.meted.ucar.edu/mesoprim/flowtopo/index.htm (English tutorial)

From that I picked three interesting statements:

Slope lft is positively affected by instable stratification.

At stable stratification there will be no useful slope lift if windspeed is too low in relation to slope height.

© actually to *reduce* the lift at a slope angle below about 10 degrees to mitigate the appearance of lift spots on otherwise fairly flat land.

Not sure, if this is correct. Maybe the lift at flat slopes will be too low (compare with thermal influence above).

In addition, I don't have a good resolution in the traditional sope data base because of the 16-step-resolution. The because of symmetry reasons I chose the steppings as 3,12,18,...87°. Of course this does not affect the probing approach.

best regards,

Peter

Share this post


Link to post
(re reduced slope below 10 degrees) Not sure, if this is correct.

you're probably right - I'm just experimenting. Re steeper slopes though I reckon ridge lift does maximise at about 45 degrees of slope and a simple 'sine' gives too much emphasis to going steeper. I watched the tutorial, and actually it chimes with my other thought... that the 'wind speed' shouldn't be a linear multiplier. Maybe for wind speeds below 5 knots (2.5m/s) the lift should be closer to zero.

At the moment I'm juggling the following parameters for my elevation probe lift equation (and I've put my current 'state of the art' in brackets after each):

* distances upwind/-downwind of the four probes (plus 0 for the user aircraft) (0,250,750,2000,-250)

* the formula for 'slope factor' calculation - sine(atan(slope)) vs atan(slope) vs atan(slope squared) etc (atan(4*slope*slope))

* the weight to apply to each slope factor to sum to the total 'base lift factor' (0.25, 0.15, 0.5 (-ve only), 0.1(+ve only))

* the formula to apply to the wind speed (x1)

* the formula to apply based on user aircraft height AGL (not done yet)

I've put a real sample of about 8 kilometers worth of probe readings into a spreadsheet and I'm trying various tweaks of the parameters. *All* these options give pretty good simulation of ridge lift though so we're only talking about fine tuning. I also compare the results with a simple sine of the local slope angle at 50m intervals and there isn't a huge difference. However, using the multiple probes can already be seen to improve the simulation in specific situations - the 'wind shadow' of upwind high ground is working, and the probes technique is inherently less susceptible to spikes of lift/sink above small ground features.

Peter - what actual formula did you use for user aircraft height AGL ? A 'tweak' I'm expecting is if the lift is positive, and the 250m upwind probe is actually higher than the ground elevation beneath the user aircraft (so slope 0 is actually negative), then the lift will *begin* above the altitude of the 250m upwind probe (maybe 100m above?), so in effect there's a lift shadow behind that little bit of upwind ground. By definition the other lift factors have outweighed the presumably shallow negative local slope otherwise the lift wouldn't have been positive - any comments here appreciated.

When all this is done I think the most significant factor will actually be the average strength multiplier of the wind, i.e. how much lift do you get in a 20 knot breeze on a typical slope, rather than how detailed and accurate the simulation is (sadly). On a *great* day with a 25 knot (13m/s?) wind directly on the ridge, you can cruise at 110/120 knots, i.e. you're coming down at maybe 2.5 meters per second so it seems to me that the overall factor should be about 0.2 in that situation, but that's lower than in CumulusX! today. And when I'm cruising the ridge I'm really (really!) watching out for 'gaps' I have to jump but the detail of the steepness of the slope doesn't feature that much in my real-world flying. Peter please comment - I wonder if you've increased the lift a bit to compensate for gentle slopes but that leaves it high at the top end and it could be better to modify the 'sine' function to emphasise slopes from 15-45 degrees more and have 80 degree slopes not much better than 45 degree slopes. Please DO let me know what you think of this.

In any case I'll re-structure the sim_probe module to that it writes the lift value into a client data area, and a simple module that reads the client area and displays the value in a console window, so the code will be ready to plug into CumulusX!. This'll be done this weekend but I'll carry on tweaking the actual model.

thanks...

Ian

Share this post


Link to post
...

Peter - what actual formula did you use for user aircraft height AGL ?

...

Peter please comment - I wonder if you've increased the lift a bit to compensate for gentle slopes but that leaves it high at the top end and it could be better to modify the 'sine' function to emphasise slopes from 15-45 degrees more and have 80 degree slopes not much better than 45 degree slopes. Please DO let me know what you think of this.

...

The formula is:

Lift = BaseLift * (1 - Exp(-AltitudeAGL, 0) / 10)) * Exp(-Max(AltitudeAGL, 0) / (GroundAltitude/2))

with

BaseLift = WindSpeed*cos(WindDir-SlopeDir)*sin(SlopeAngle)

The first exponential component gives a decay of lift very close to ground, the second term is the actual decay for higher AGL altitudes. The reasoning for the scaling with ground altitude is, that the higher the mountains, the deeper the valleys (most of the tme, but perhaps not in Tibet).

At the time, the approach is straight forward geometry (therefor the "sine"), because I don't have a good reasoning yet, how to increase of decrease the lift in certain conditions. I do not like adjusting things until just I feel it being correct.

From the tutorial there was the effect of the filling up the canyons perpendicular to the main ridge with wedges of air, resulting in lift behaviour that is mostly determined by the main ridge. This could be a reasonable explanation for the perception that gentle slopes (with canyons) are working too bad in the simulation. Currently, the overall result when flying over the "Slope Data Base" is a sort of averaging the main slope and the canyons. I think this is effectively the case in the 2D-approach of probing, too. In return this would mean, that for the simulation the "main ridge" should have to be detected, and the canyons need to be disregarded. I do not see an easy solution for this yet, but if possible, it would be nicely in line with the published material.

I think there are several ways to go forward for the time being, and one is certainly to collect experience from RW pilots on specific ridges and compare, as your's. My own experience is very limited here.

best regards,

Peter

Share this post


Link to post
Lift = BaseLift * (1 - Exp(-AltitudeAGL, 0) / 10)) * Exp(-Max(AltitudeAGL, 0) / (GroundAltitude/2))

Is there a Min function missing from the first exponent? I'm guessing you can somehow sometimes get a negative AGL altitude. And the first exp factor is designed to reduce the base lift at ground level to 0.9 of the max value?

Re the lift factor maximising at some slope value less than 90 degrees, I think the idea that the wind does not go vertical for a vertical slope is valid, i.e.

post-5237-1213361946_thumb.jpg

I have the version of my sim_probe which writes to a client data area

client data area name name: b21_sim_probe

struct SimLift { double lift; int status = 0; double version=1.00 }

And I wrote a 1-page 'sim_probe_monitor' which reads from that client data area and displays the lift each time it changes - all working well and available as demo source if you want it.

I could use a version of CumulusX! that reads from that data area for testing - then I can see what the lift is like to fly in - alternatively let me know how you apply the lift to the aircraft and I can build a test harness for that.

Regards Ian

post-16-1199610722.jpg

Share this post


Link to post
Is there a Min function missing from the first exponent? I'm guessing you can somehow sometimes get a negative AGL altitude. And the first exp factor is designed to reduce the base lift at ground level to 0.9 of the max value?

...

Re the lift factor maximising at some slope value less than 90 degrees, I think the idea that the wind does not go vertical for a vertical slope is valid, i.e.

I have the version of my sim_probe which writes to a client data area

...

And I wrote a 1-page 'sim_probe_monitor' which reads from that client data area and displays the lift each time it changes - all working well and available as demo source if you want it.

I could use a version of CumulusX! that reads from that data area for testing - then I can see what the lift is like to fly in - alternatively let me know how you apply the lift to the aircraft and I can build a test harness for that.

Sorry, I was a bit to fanatic with formatting the actula code line. Correctly:

Lift = BaseLift * (1 - Exp(-Max(AltitudeAGL, 0) / 10)) * Exp(-Max(AltitudeAGL, 0) / (GroundAltitude/2))

which means, lift profile is 0%/0m-70%/10m-87%/20m-95%/20 m ....

I would like to integrate the switch in CumulusX, so for testing it would be good to have the sim_probe module available. In addition, there is not a secret about the code for making the lift, however there is a lot of bywork to manage most of the sim states (slewing, pausing, initialisatio) correctly, and it's even not yet complete.

So it might be more efficient to let it be handles by CumulusX.

However if you like to do it, here is a short recipy how to proceed:

Set up a structure for reading aircraft position, including wind, time, ground altitude, and World Velocity Y

If you want to make the vario TE compensated, than add also true airpeed to the list.

The update rate requirement is once per sim-frame or per visual frame at least for the World Position Y, World Velocity Y, the time and, in case for Airspeed True. Otherwise the plane is jerky. The position and wind conditions may also run on lower rate.

Set up another structure for sending World Position Y, Variometer Rate and Vertical Speed (the latter is the gauge rather than movement of the plane)

Map a "FreezeAltitudeEvent" with high priority and send it to the sim.

From this moment on calculate lift, add to World velocity Y and integrate the World Position Y. Send the data back to the sim. You may also update Variometer Rate (Audio) and Vertical Speed for proper Audio signal and VSI (not the Variometer gauge, whic makes something like a Netto-vario, but wrong)

You have to take care to capture and process pause, slew and other sim start and stop events correctly, otherwise you'll get weird effects, and IÄm still not through with it.

I'm currently integrating CumulusX! into the FSX user interface. However there seems to be a roadblock for Windows Forms displaying over the Full Screen mode.

For the time being it is pretty broken. At least one can turn on and off the lift and switch over to the Main Menu. FSX window disappears in the background, however does not return easily with switching back to the sim. Instead it need some switching fro and to until it returns.

Apparently I would have to switch from GDI+ to something like WPF, however this seems not to be supported by VS Express. Do you know an easier alternative?

regards,

Peter

Share this post


Link to post

Right! I've cruised around the FSX landscape a thousand times tweaking my ridge lift calculation model and it's now ready to ship to Peter for testing with CumulusX!. Peter send me a message on here where I can email the source and executables to.

For reference, the parameters currently in the model include:

(1) FIVE probes of FSX ground altititude (i.e. inside the sim, not using a slope file) upwind and downwind of the user aircraft, at distances of 0m, 250m, 750m, 2000m and -100m.

(2) The FOUR slopes between each adjacent probe are calculated and modified using the formula charted in *blue* below. I've included the Sine curve in red for comparison.

post-16139-1213385092_thumb.jpg

This normalizes each slope factor into the range -1..1, with the lift/sink maximising around 45 degrees, i.e. the lift improves up to a slope of 45 degrees and after that it maxes out.

(3) Each slope factor is weighted with the values 250m=0.2, 750m=0.2, 2000m=0.5 (negative only), -100m=0.2 (positive only), i.e. the slope to the far upwind probe (at 2000m) can only reduce a lift value, representing the wind shadow of an upwind ridge, while a nearby back-slope (to -100m) can only *add* to the lift value.

(4) The weighted slope factors are added together and multiplied by the wind producing the 'base lift' applicable if the user is ideally positioned above the ground, and multiplied by a factor taking into account the elevation of the user aircraft above the ground, giving the final 'user lift'. The graph of that 'user AGL' function is below:

post-16891-1213393736_thumb.jpg

This places the strongest lift 40 to 130 meters above the ground. Below 40m AGL the lift decays linearly to 0.5 its full value, and aboce 130m the lift decays exponentially using a factor relative to the ground elevation at the user aircraft - the higher the ground, the higher the lift will go, represented by the multiple lines on the chart with ridges at 500m (~1500 feet) to 2000m (~6000 feet). The function is essentially consistent with the approach used in CumulusX! with slope files but I have normalised the function to max at 1.0 and in fact reduced the benefit of higher altitudes as the 750m probe already benefits longer slopes to a degree.

(5) As presented in another thread, this computation combined gives the following distribution of lift across a real FSX sampled landscape.

We now need to test with CumulusX! actually injecting this lift into the sim so it affects the user aircraft (so far I've just been monitoring the lift value calculated in a debug window while slewing the aircraft).

Ian

post-16-1199971401.jpg

post-16-1199971911.jpg

post-16-1199972309.jpg

Share this post


Link to post
(3) Each slope factor is weighted with the values 250m=0.2, 750m=0.2, 2000m=0.5 (negative only), -100m=0.2 (positive only), i.e. the slope to the far upwind probe (at 2000m) can only reduce a lift value, representing the wind shadow of an upwind ridge, while a nearby back-slope (to -100m) can only *add* to the lift value.

We now need to test with CumulusX! actually injecting this lift into the sim so it affects the user aircraft (so far I've just been monitoring the lift value calculated in a debug window while slewing the aircraft).

Looks pretty convincing. My only remark is, that it seems to me that the formula gives a max of lift of 0.6 on an infinite slope of say 60°, when all lift factors are positive. Then the 2000m-factor is disregarded, while the remaining three add up to 0.6.

You can expect an updated CumulusX!-version at the weekend.

best regards,

Peter

PS: Downloaded your b21_simprobe.exe, but get an error message:

"This application could not be started because the configuration is not correct. Please re-install the application." (Translation from German)

Share this post


Link to post
the formula gives a max of lift of 0.6 on an infinite slope of say 60°, when all lift factors are positive.

You've interpreted the code absolutely correctly - it's good to be able to have a discussion at this level of detail. The slope factor weights can be tuned during flight testing with CumulusX!. I have about 500 ridge-soaring hours out of my 1100 hours total, and in a 20 knot breeze you'd never find 20 knots lift anywhere, regardless of the slope, apart from turbulence or thermal-induced surges. The 0.6 maximum is kind of a guesstimate compromise which I suspect is on the high side for the majority of terrain. There's also a relationship between the 0.5 negative weighting of the far upwind slope and the positive maximum and more typical values - i.e. high ground 2 km upwind has the chance of killing lift on a local slope.

You can expect an updated CumulusX!-version at the weekend.

Fantastic - thanks - I'll exchange with you a complete version of sim_probe that has the full lift calculation and feeds the client data area, plus a demo 'sim_probe_monitor' as a sample source that reads the client data area - as you can have multiple simconnect clients subscribing to the same data area, this should be able to co-exist with CumulusX! to help testing.

PS: Downloaded your b21_simprobe.exe, but get an error message:

"This application could not be started because the configuration is not correct. Please re-install the application." (Translation from German)

I think you most likely need the Visual C++ Runtime, which should be distributed with any Visual C++ application. They are available here:

download from the Microsoft site

I apologise, as sim_probe is my first visual c++ application and I had no idea there would be a requirement to include the runtime library from Msoft. Hey at least it's not .NET :big_boss: *EDIT*: the download is a pre-requisite, *but*, I've just read on the MS Dev website that "debug applications are not re-distributable" and that's exactly how I left the exe version on the website... so the proper versions I give you will be compiled as ' released' versions, and I'll update the one on the website. *END EDIT*

Please note the executable linked to my original paper is just the terrain scanning code - there's no lift calculation or client data area - feel free to experiment with that one (open a command window and start it after FSX starts but *before* you go into free flight) and when you start a flight you should see the purple igloos appear near the aircraft in the sim and a scrolling printout of the probe elevation values in the command window (fixed direction to the NE I think) but I'll send you a link to the proper 'CumulusX!-ready' version this weekend.

There will be the source and executables for three programs:

sim_probe.exe - the 'CumulusX!-ready' code that writes to the client data area

sim_probe_debug.exe - the *same* code but with write statements enabled to display the parameters in a console window

sim_probe_monitor.exe - a simple simconnect console program that reads and displays the client data each time it changes (once per second).

The client data area is defined in C++ with the following:

const char* SIMLIFT_NAME = "b21_sim_probe";

// structure for lift value client data
struct SimLift {
    double lift;
    int status; // 0 = ok, 1 = problem, others = reserved
    double version;
};

I don't know if you've written a simconnect client data client before but it was pretty straightforward and the C++ source in sim_probe_monitor.cpp will at least show the simconnect calls with the right parameters.

Ian

Share this post


Link to post

Peter/anyone - for a quick test - here's the sim_probe I've compiled as a 'Released' version. Please download the C++ library (1.7MB I think) I linked to in the previous post and install that, then download the sim_probe.exe (only 14 kb) I've attached here:

the new 'b21_sim_probe.exe' on my site

then

1) Start FSX

2) run b21_sim_probe.exe (either double click the executable wherever you've downloaded it, or open a 'console window' and run it from there.)

3) start a flight in windowed mode (so you can still see the console window), preferably over hilly ground, and with a decent wind.

The console window should show something like:

And if you look carefully upwind in the sim, you should see a purple igloo 250m away on the ground, plus others at 750m, 2000m and -100m.

This is just a check to see if I've got the settings right for an install on a PC other than mine (this code does *not* inject lift into the sim). Peter FYI this *is* the version with the client data area in it..., but I can send you the 'monitor' when we've confirmed this install code is on the right lines.

Thanks,

Ian

post-16-1200075864.jpg

post-16-1200076161.jpg

Share this post


Link to post

Hey Peter, and Ian, Have you all had a chance to realize Wave lift into CumulusX! yet? In the original thread "CumulusX!, Ridge Soaring in FSX", Snehulak just posted and came up with more documentation for wave lift. It's possible either one of you two have seen this data before, but just wanted to make sure if it can be possibly implimented in the future.

sf4JC

Share this post


Link to post

Ian,

I downloaded the files and run FSX and the .exe as instructed. I see the .exe file produce new data every 1, 2 or 3 seconds and have all 4 purple objects in sight. So it works (I have FSX SP2 and Vista 32-bit).

Bert

Share this post


Link to post

It works for me, too.

I have also the new version nearly ready and I get some data from the b21_sim_probe, at least my handler for the update of the client area works.

Apparently I ahve a problem to convert it into my structure. I made exactly as in the example for the RequestDataOnSimObject, but somehow VB.NET cannot convert the received data structure into the my local structure.

I'm interested in the monitor app, perhaps I can learn from it.

One remark: Initially, b21_sim_probe didn't create the probe objects, because of waiting for a sim start event. This however did not happen because FSX was already running. After switching to some menu and back it started regular opration, finally.

best regards,

Peter

Share this post


Link to post

Ok, got it. Hooray to Ian!

And documentation isn't Aces team's big strength.

So here its: CumulusX! 0.91

The checkboxes enable/disable the indicated lift type, however SlopeDataBase has preference over Slope Probe, and Scriptfile over Autothermals, unless uncecked.

This means: Whenever there is avalid slope database, it will be used if you have checked the checkbox. Slope Probe lift is not added on top. So if you want to run Slope Probe alone, leave the Slope Data Base uncecked. This produces an automatic fallback to slope probe if there is no valid slope data base available.

In order to make the current simprobe version runing properly you should either load it in the opening screen, or switch once to some dialog and back.

The same principle holds for the script file. If you have defined a script file and for some reason it doesn't work (format error, or simply missing) you will get AutoThermals by default, again unless you uncheck. Vice versa you can skip an existing script file by unchecking its mark.

And here is also a sample EXE.xml which autoamticallly starts CumulusX! on FSX startup. It goes into the user settings directory of FSX (where dll.xml is already, \Documents and Settings\your user name\Application Data\Microsoft\FSX).

<?xml version="1.0" encoding="Windows-1252"?>
<SimBase.Document Type="Launch" version="1,0">
<Descr>Launch</Descr>
<Filename>EXE.xml</Filename>
<Disabled>False</Disabled>
<Launch.ManualLoad>False</Launch.ManualLoad>
<Launch.Addon>
<Disabled>False</Disabled>
<ManualLoad>False</ManualLoad>
<Name>Addon Application</Name>
<Path>C:\--- insert your current cumulusX!-location here----\CumulusX.exe</Path>
<CommandLine></CommandLine>
<NewConsole>True</NewConsole>
</Launch.Addon>
</SimBase.Document>
[/codebox]

Cheers,

Peter

Edit: I put a new version 0.911 into the CumulusX! thread in response to the problem with XP64. As I saw that nobody had yet made download of 0.91 I didn't want to confuse with excessive releases at a time.

post-176-1200088442.jpg

Share this post


Link to post

Hi Ian,

played around a bit with it for a while now, and it works very well. Most of the time the differences between the slope data base and the Simprobe appear not very big, except in sink, where simprobe appears to be much more moderate. At light slope CumulusX! produces an estimate of 30% more lift, which coincides well with the expectations from the formula.

Once I had an effect, after hopping from Mifflin back to Germany by means of the map display, that FPS went down totally. Could it happen, that occasionally probes are left over? It seems that FSX suffers terribly from wide spread objects. After stopping and restarting simprobe the effect was gone, and I know that in such a case all objects are discarded, which the client has created.

regards,

Peter

Share this post


Link to post
Guest
This topic is now closed to further replies.
Sign in to follow this  

×
×
  • Create New...