Sounds to me like you've got that wing section (i.e. the flap) beyond the peak of the L/D curve, while the bulk of the wing is in front of the L/D curve. If that is the case, it is certainly something that will often happen in real life and your solver needs to cope with it. Without looking at the code, I can't make specific suggestions.
> Curtis L. Olson wrote: > > So, if I am at my max speed with 0 flaps in a straight and level > > configuration, then there is *no way* that lowering the flaps should > > net you additional speed while maintaining the same straight and level > > flight path. I don't care how well you explain it. :-) > > Not buyin' it, huh? OK, you're right. There's a bug. But, to be > fair, my explanation (or hand-waving, you make the call) was spot on, > too. :) > > The problem is actually kind of deep. YASim specifies control surface > drag in relative units. A flap with a drag of "2" will double the > surface's drag when deployed. And, in fact, it does. But in the > wrong coordinates. > > Because the code works in the surface's orientation (each Surface > object gets its own orientation matrix in YASim), the value I'm > doubling is the drag along the surface plane -- what amounts to the > parasite drag in most treatments. The induced drag, which constitutes > the bulk of the actual force in anything but an unloaded dive, isn't > changed. So drag goes up only a little. But lift goes up a lot, so > the autopilot trims the aircraft to a lower AoA, and the overall drag > goes *down* for the same lift. Which is the bogus effect you saw. > > So, the obvious solution would be to multiply the drag along the > relative wind direction, instead of along the surface plane. > Unfortunately, this causes the YASim solver to blow up and fail to > find a solution. Here's an attempt at an explanation: > > The solver is basically a Newton-Raphson engine that twiddles two > variables: the lift-to-drag ratio of the wings, and the overall drag > coefficient. It modifies the L/D ratio to keep the plane in the air > at the approach speed, and modifies the overall drag to make the drag > equal to the thrust at the specified cruise speed (it also plays with > the cruise AoA and tail incidence, but those aren't relevant to this > problem). > > But in this situation, it gets into a divergent cycle. The solver > bumps the L/D ratio a little bit. But this causes the drag to go up, > too, since some of the lift is pointing backwards at non-zero AoA. So > the overall drag coefficient gets pushed down a bit to compensate. > But now, we need more lift! So the L/D ratio goes up again, and the > drag down, and the thing diverges. > > There's a deep truth here that I'm not seeing. The functions here are > all continuous, and real-world systems based on continuous functions > can't show this kind of divergence (there's a theorem to that effect > somewhere). I'll keep thinking; whack me if I've missed something > obvious. I suspect the final solution is going to have to work in the > surface's drag plane, and not the winds... > > Andy > > -- > Andrew J. Ross NextBus Information Systems > Senior Software Engineer Emeryville, CA > [EMAIL PROTECTED] http://www.nextbus.com > "Men go crazy in conflagrations. They only get better one by one." > - Sting (misquoted) > > > _______________________________________________ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
