Discussion Could we build realistic-air-dynamics with FLZ-Vortex into Orbiter?

[Col Brubaker]

Years ago I played with an old version of FLZ-Vortex. to build flying wings out of styropor.
https://flz-vortex.de/

First you need to enter airfoil profiles and build a wing from it. Then you can start calculations with different angles. And there has to be an angle of indifference: https://en.wikipedia.org/wiki/Angle_of_incidence_(aerodynamics)

At a flying wings the wing tips have a slightly downwards angle of indifference. For normal planes you need to build a second wing for the elevator.
FLZ could really be used to build a very realistic real time flight behaviour into our mainly delta-wings.
- But I am not a coder. Our computers are actually fast enough now to run this in real time.

 

[Thunder Chicken]

Vortex lattice methods are derived from Prandtl's lifting line theory, and generally assume air is incompressible and inviscid. They can be used to estimate lift and moment coefficients for flight in Mach numbers less than about 0.3, but that might still be useful as the wave drag functions might bridge the gap to higher Mach numbers. They will tend to underestimate drag as viscosity and boundary layers are not considered.

There would be no need to run it in real time, or to combine it into Orbiter in any way. If you wanted to, you could put an Orbiter mesh geometry into FLZ-Vortex and have it produce a table of coefficients as a function of angle of attack which could then be entered into an add-on through the airfoil definitions. it would be far more efficient to interpolate such a table than to try to run the vortex lattice solver at every time step of an Orbiter simulation.

 

[Col Brubaker]

I see, we have the ultimate experts for such things in here. So I don't need to worry about. OK, was just an idea. I never thought about Mach 0.3 while working with Depron.
Your "table of coefficients function" could make starts and landing more realistic. And perhaps there will be a sailplane? A wind-MFD? Hang-gliding in the Alps?

Then let's change the topic and talk about a table of coefficients function:

There would be no need to run it in real time, or to combine it into Orbiter in any way. If you wanted to, you could put an Orbiter mesh geometry into FLZ-Vortex and have it produce a table of coefficients as a function of angle of attack which could then be entered into an add-on through the airfoil definitions. it would be far more efficient to interpolate such a table than to try to run the vortex lattice solver at every time step of an Orbiter simulation.

 

[Urwumpe]

I see, we have the ultimate experts for such things in here. So I don't need to worry about. OK, was just an idea. I never thought about Mach 0.3 while working with Depron.
Your "table of coefficients function" could make starts and landing more realistic. And perhaps there will be a sailplane? A wind-MFD? Hang-gliding in the Alps?

Then let's change the topic and talk about a table of coefficients function:

Well, not to spoil your fun, but let me just say one word: Space.

And space is big.

 

[Thunder Chicken]

One other issue with vortex lattice methods is that they are generally assuming attached flow to the airfoil or body being studied at all angles of attack. There are some crude approximate methods to modify these models to mimic leading edge separation, but they are rather empirical in nature. Depending on how it was implemented in the code, it is possible that you would get physically incorrect lift and drag behavior above say 15-20 degrees angle of attack.

 

[Thunder Chicken]

Then let's change the topic and talk about a table of coefficients function:

You can take a look at the Delta Glider code to see how the coefficients (CL, CM) can be entered in vectors as a function of angle of attack (AOA) and interpolated:

void VLiftCoeff (VESSEL *v, double aoa, double M, double Re, void *context, double *cl, double *cm, double *cd)
{
    int i;
    const int nabsc = 9;
    static const double AOA[nabsc] = {-180*RAD,-60*RAD,-30*RAD, -2*RAD, 15*RAD,20*RAD,25*RAD,60*RAD,180*RAD};
    static const double CL[nabsc]  = {       0,      0,   -0.4,      0,    0.7,     1,   0.8,     0,      0};
    static const double CM[nabsc]  = {       0,      0,  0.014, 0.0039, -0.006,-0.008,-0.010,     0,      0};
    for (i = 0; i < nabsc-1 && AOA[i+1] < aoa; i++);
    double f = (aoa-AOA[i]) / (AOA[i+1]-AOA[i]);
    *cl = CL[i] + (CL[i+1]-CL[i]) * f;  // aoa-dependent lift coefficient
    *cm = CM[i] + (CM[i+1]-CM[i]) * f;  // aoa-dependent moment coefficient
    double saoa = sin(aoa);
    double pd = 0.015 + 0.4*saoa*saoa;  // profile drag
    *cd = pd + oapiGetInducedDrag (*cl, 1.5, 0.7) + oapiGetWaveDrag (M, 0.75, 1.0, 1.1, 0.04);
    // profile drag + (lift-)induced drag + transonic/supersonic wave (compressibility) drag
}

So you could put a model into your vortex lattice solver, set the angle of attack, run the solver and get the coefficients.
Lather, rinse, repeat until you get a number of coefficients over a suitable range of AOA, and update the above code with those coefficients.

 

[Matias Saibene]

You can take a look at the Delta Glider code to see how the coefficients (CL, CM) can be entered in vectors as a function of angle of attack (AOA) and interpolated:

void VLiftCoeff (VESSEL *v, double aoa, double M, double Re, void *context, double *cl, double *cm, double *cd)
{
    int i;
    const int nabsc = 9;
    static const double AOA[nabsc] = {-180*RAD,-60*RAD,-30*RAD, -2*RAD, 15*RAD,20*RAD,25*RAD,60*RAD,180*RAD};
    static const double CL[nabsc]  = {       0,      0,   -0.4,      0,    0.7,     1,   0.8,     0,      0};
    static const double CM[nabsc]  = {       0,      0,  0.014, 0.0039, -0.006,-0.008,-0.010,     0,      0};
    for (i = 0; i < nabsc-1 && AOA[i+1] < aoa; i++);
    double f = (aoa-AOA[i]) / (AOA[i+1]-AOA[i]);
    *cl = CL[i] + (CL[i+1]-CL[i]) * f;  // aoa-dependent lift coefficient
    *cm = CM[i] + (CM[i+1]-CM[i]) * f;  // aoa-dependent moment coefficient
    double saoa = sin(aoa);
    double pd = 0.015 + 0.4*saoa*saoa;  // profile drag
    *cd = pd + oapiGetInducedDrag (*cl, 1.5, 0.7) + oapiGetWaveDrag (M, 0.75, 1.0, 1.1, 0.04);
    // profile drag + (lift-)induced drag + transonic/supersonic wave (compressibility) drag
}

So you could put a model into your vortex lattice solver, set the angle of attack, run the solver and get the coefficients.
Lather, rinse, repeat until you get a number of coefficients over a suitable range of AOA, and update the above code with those coefficients.

I think that's just what I need to do. Thank you!

 

[Urwumpe]

In SSU is also a more complicated version of that, using external data files.

 

[Col Brubaker]

One other issue with vortex lattice methods is that they are generally assuming attached flow to the airfoil or body being studied at all angles of attack. There are some crude approximate methods to modify these models to mimic leading edge separation, but they are rather empirical in nature. Depending on how it was implemented in the code, it is possible that you would get physically incorrect lift and drag behavior above say 15-20 degrees angle of attack.

Yeah, and then we need a red blink-light, huge noise master-alert sound and a stall-warning from tape.

 

[Thunder Chicken]

Yeah, and then we need a red blink-light, huge noise master-alert sound and a stall-warning from tape.

And a stick-shaker. Don't forget the stick-shaker.

https://gifdb.com/images/high/airplane-movie-robert-hardly-flying-31xystskio4a2ng0.webp

 

[Col Brubaker]

And a stick-shaker. Don't forget the stick-shaker.

OK, but with a box for the hook to turn the joystick-vibration on, which is unhooked after installation.

In SSU is also a more complicated version of that, using external data files.

Does SSU have a other flight behavior at landing then Atlantis?

I think that's just what I need to do. Thank you!

How to put a .mesh model into my vortex lattice solver?

 

[Urwumpe]

Does SSU have another flight behavior at landing then Atlantis?

Yes.