# DiscussionCould we build realistic-air-dynamics with FLZ-Vortex into Orbiter?

#### Col Brubaker

##### Hoax Developer
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.

Last edited:

#### Thunder Chicken

Donator
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

##### Hoax Developer
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

##### Not funny anymore
Donator
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

Donator
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

Donator
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:

C++:
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 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

##### I don't know if it is a bug or a feature
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:

C++:
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 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

##### Not funny anymore
Donator
In SSU is also a more complicated version of that, using external data files.

#### Col Brubaker

##### Hoax Developer
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

Donator
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.

#### Col Brubaker

##### Hoax Developer
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?

Last edited:

#### Urwumpe

##### Not funny anymore
Donator
Does SSU have another flight behavior at landing then Atlantis?

Yes.

Replies
7
Views
574
Replies
26
Views
2K
Replies
24
Views
917
Replies
5
Views
516
Replies
1
Views
466