Discussion X-Y plane aerofoil?

[BrianJ]

Hello!
I hope this is the right place for ideas about future Orbiter developements.

I just wondered if anyone had thought about adding a 3rd aerofoil option for vessels - an aerofoil in the X-Y plane.
This would be useful for capsules.
It is possible to simulate capsule lift effects with the current vertical/horizontal aerofoil orientations - but the aerofoil profile drag must be wrong (?)
I think it would make sense maths/physics-wise (?).
Just an idea for consideration!
Thanks,
BrianJ

 

[n72.75]

What if you could define them by a normal vector or an alignment matrix?

 

[Thunder Chicken]

This airfoil direction was omitted on purpose. By definition lift is the aerodynamic force perpendicular to the relative wind direction, so defining an airfoil orthogonal to the direction of flight is kind of a weird idea. Could you model a blunt capsule as an airfoil? Sure, I guess, maybe, but it would be a perpetually stalled airfoil with a nearly 90° angle of attack developing hardly any lift in the Z direction with all of the drag expressed as profile drag.

I think most people intuit that drag is the major force acting on the vehicle in that direction, and calculating a single drag force based on relative wind is far simpler than additionally calculating lift coefficients and forces that are always around zero.

As you mention, the current models allow both the drag and lateral lift forces for bodies like capsules, so there would be nothing gained by doing this except adding confusion.

 

[indy91]

With the current system of two airfoils there is the problem of singularities. At 90° angle of attack the slip angle becomes undefined and vice versa. This isn't much of a problem for aircraft, but spacecraft quite often can be at attitudes 90° from the airspeed vector. So what I have done with the CM and CSM in NASSP is to calculate the aerodynamic coefficients as a function of the total angle of attack instead of the "normal" AOA or side slip. And then project the result into the two airfoils axes. This system only works for axis symmetrical vehicles, but it eliminates the singularity problems and, using the correct center of pressure vector for CreateAirfoil, you can get the correct aerodynamic force and moment vectors at any attitude.

I wouldn't use this as a template, but here is how I'm dealing with for the CM in NASSP. I'm using CreateAirfoil3 to get a vessel pointer. Then I have these callback functions:

void CMVertCoeffFunc(VESSEL *v, double aoa, double M, double Re, void *context, double *cl, double *cm, double *cd)
void CMHorizCoeffFunc(VESSEL *v, double beta, double M, double Re, void *context, double *cl, double *cm, double *cd)

Both of them have to do this calculation

//Get unit airspeed vector
    VECTOR3 vec;
    v->GetAirspeedVector(FRAME_LOCAL, vec);
    vec = unit(vec);

 //Calculate total angle of attack (alpha) and roll angle (phi_A)
    cos_alpha = vec.z;
    alpha = acos(cos_alpha);
    sin_alpha = sin(alpha);
    phi_A = atan2(vec.x, -vec.y);
    cos_phi_A = cos(phi_A);

So I am totally ingnoring aoa and beta. Might cause some numerical problems if the callback functions are called more than once per timestep, I'm not quite sure. Then the lift, drag and moment coefficients are calculated as a function of alpha and phi_A. And then at the end the two functions differ again. CMVertCoeffFunc does:

 //Calculate total lift and drag coefficients
    C_L = cos_alpha * C_NY - sin_alpha * C_A;
    C_D = sin_alpha * C_NY + cos_alpha * C_A;

    //Project coefficients into coordinates used by Orbiter
    fact = sqrt(vec.y*vec.y + vec.z*vec.z);
    *cl = C_L * cos_phi_A*fact;
    *cd = C_D;
    *cm = cos_phi_A * C_M_A;

and CMHorizCoeffFunc has to do:

    //Calculate total lift coefficient
    C_L = cos_alpha * C_NY - sin_alpha * C_A;

    //Project coefficients into coordinates used by Orbiter
    fact = sqrt(vec.x*vec.x + vec.z*vec.z);
    *cl = -C_L * sin_phi_A*fact;
    *cd = 0.0;
    *cm = sin_phi_A * C_M_A;

So the drag is only handled in one function, as it doesn't matter where it is applied, the drag vector is always along the airspeed velocity vector.

Maybe this gives some food for thought. So it is possible, for axis symmetrical vehicles, to get accurate, singularity free aerodynamic coeffcients at any attitude. But this is a bit of a workaround. Maybe it would be better to, as an option, to calculate force and moment vectors yourself instead of having to use two airfoils? I'm not sure.

 

[Urwumpe]

Wouldn't it be easier to have a definiton of the possible values at 90° aoa in Orbiter to prevent a singularity taking place?

 

[Thunder Chicken]

Wouldn't it be easier to have a definiton of the possible values at 90° aoa in Orbiter to prevent a singularity taking place?

This. If you read the API docs you can define airfoil properties for any angle of attack through +/- 180°. There is no "singularity" at 90° unless the user forces a divide-by-zero or something in their coefficient definitions.

 

[indy91]

Wouldn't it be easier to have a definiton of the possible values at 90° aoa in Orbiter to prevent a singularity taking place?

That's not the problem. Total drag for example would be a function of both angle of attack and side slip angle, but not independent of each other as the standard airfoil calculations assume. If you are at 90° aoa then the side slip angle becomes random, not very well defined. So any coefficients as a function of the slide slip angle become useless at 90° aoa. The system was clearly meant for aircraft, which usually stay close to 0° AOA and beta, and not spacecraft.

 

[Urwumpe]

That's not the problem. Total drag for example would be a function of both angle of attack and side slip angle, but not independent of each other as the standard airfoil calculations assume. If you are at 90° aoa then the side slip angle becomes random, not very well defined. So any coefficients as a function of the slide slip angle become useless at 90° aoa. The system was clearly meant for aircraft, which usually stay close to 0° AOA and beta, and not spacecraft.

Yes, that is because you don't resolve the singularity. But what be the case at 89° AOA? Where would a limit calculation for certain sideslip values from 0° to 90° AOA end?

 

[Thunder Chicken]

That's not the problem. Total drag for example would be a function of both angle of attack and side slip angle, but not independent of each other as the standard airfoil calculations assume. If you are at 90° aoa then the side slip angle becomes random, not very well defined. So any coefficients as a function of the slide slip angle become undefined at 90° aoa. The system was clearly meant for aircraft, which usually stay close to 0° AOA and beta, and not spacecraft.

Hence why a drag force model is used in those instances. Set the drag using the drag force and leave the profile drag 0 in the airfoil definitions. It's only a "singularity" due to the fact that you're trying to jam a drag model into a lift model.

 

[BrianJ]

Hi,
many thanks for the input. I'm sure many folks here have a much better grasp of aerodynamic simulations than I do!

However, it still seems intuitively right (not always a good guide, I know) that for a capsule where the effective aerodynamic surface is oriented in the XY vessel plane, it should be possible to specifiy a simulated aerofoil in that orientation, and have Orbiter handle the lift and drag calculations in a similar manner to the current aerofoils (thus reducing/eliminating the need for workarounds - see @indy91 post above).

What if you could define them by a normal vector or an alignment matrix?

That would certainly be sufficient, but might be more complex than a simple 3rd option of XY plane, but more flexible from a user point-of-view.

This airfoil direction was omitted on purpose. By definition lift is the aerodynamic force perpendicular to the relative wind direction, so defining an airfoil orthogonal to the direction of flight is kind of a weird idea.

The lift would be perpendicular to relative wind direction, and in the plane of relative wind direction and the normal to the aerofoil surface.
I think its only weird if you're thinking about it terms of Shuttle type vessels.

Could you model a blunt capsule as an airfoil? Sure, I guess, maybe, but it would be a perpetually stalled airfoil with a nearly 90° angle of attack

That sounds about right to me, for a capsule!

developing hardly any lift in the Z direction with all of the drag expressed as profile drag.

I'm not sure why lift would be in the Z direction? (see my definition of lift vector above).
Maybe not much lift - that would depend on how you specify the lift in the LiftCoefficient function, though.

Profile drag is one of my concerns - for current ZX plane aerofoil, profile drag increases as AoA increases from 0.
But for a capsule with an aerofoil in XY plane, profile drag should decrease as AoA increases from 0 (surely?).

I think most people intuit that drag is the major force acting on the vehicle in that direction, and calculating a single drag force based on relative wind is far simpler than additionally calculating lift coefficients and forces that are always around zero.

I naively imagine calculating drag/lift for an XY plane aerofoil is not much more work than for the current orientations?

As you mention, the current models allow both the drag and lateral lift forces for bodies like capsules, so there would be nothing gained by doing this except adding confusion.

Except that folks like Indy91 and myself are having to find workarounds to make things come out right in the sim.
But I can live with that

Well, as I say, I have very little clue as to the optimal simulation of aerodynamics!
I'm very happy to leave it to you folks who generously give your time to develop Orbiter
It was just something that comes to my mind everytime I start making capsule reentry stuff.

Thanks,
BrianJ

 

[indy91]

Hence why a drag force model is used in those instances. Set the drag using the drag force and leave the profile drag 0 in the airfoil definitions. It's only a "singularity" due to the fact that you're trying to jam a drag model into a lift model.

With drag force model you mean using SetCW? If it was only drag then this would be sufficient, even if SetCW has some issues. But I also wanted to simulate correct aerodynamic moments. That's the bigger issue with the airfoils. Like, imagine the Apollo CSM. It had a tendency to get torqued by orbital aerodynamics so that the nose would be pointing towards the airspeed vector. This effect was the strongest at 90° total(!) angle of attack.

Using the airfoils to do this in the normal way, with the angles that are given to the callback functions, at 80° aoa and 0° beta, no problem. 80° beta, 0° aoa, no problem. But close to 90° for aoa or beta the other angle becomes random, jumping around from -180° to 180°. So you can't just calculate the moment around one axis as a function of aoa and in the other airfoil function, independently, as a function of beta. Near the 90° angles you will get unrealistic behavior because one of the angles supplied to the airfoil callback becomes ill defined. It's the same with lift, but lift doesn't matter much to me for the CSM in orbit.

 

[Thunder Chicken]

The lift would be perpendicular to relative wind direction, and in the plane of relative wind direction and the normal to the airfoil surface.
I think its only weird if you're thinking about it terms of Shuttle type vessels.

It may be that I am not clearly understanding your coordinate system. In a capsule on re-entry, with no pitch or yaw, I would assume the relative wind is coming from behind (-Z). This would be effectively an angle of attack of 180, but this can be provided to horizontal or vertical lift functions. You would need to take care that your coefficient at + 180 matches that at -180, and that the signs of the coefficients are sensible, but otherwise you can have a continuous coefficient function at all angles of pitch and yaw.

A 3rd airfoil definition in the X-Y plane really doesn't make sense as by definition you can't have lift in the direction of flight. The proper aerodynamic force in the direction of flight is drag. Like I said, yeah, it's probably possible to code such a thing, but all it would give you is a very complicated means to implement blunt body profile drag.

I think the fundamental problem is how drag is handled currently in Orbiter, which is forcing all of these hacks in the lift models. As it stands now, you have the choice of the legacy drag model SetCW, but that is ignored if you specify an airfoil. The assumption was probably that you were either flying something with wings OR you were flying a capsule on a ballistic trajectory, but the idea of pursuing the accuracy of the lift forces on a blunt capsule wasn't considered. This model is also a problem for aircraft and spacecraft too, as all of the drag must be specified within the lift model, and so your drag coefficients for all the nacelles and fuselages and non-wing bits need to be normalized to the plan area of the wing. On super sleek aircraft it's not so much of a problem, but anything with appreciable pressure drag it's less than ideal.

I don't think making a third airfoil to add more hacks is the answer. I think a better way to do this would be to leave the existing airfoil definitions as they are, and have them calculate ONLY the profile and induced drag terms for well-defined airfoils with wingspans, aspect ratios, and such. ADDITIONAL drag terms for nacelles, fuselages, blunt bodies, etc. should be implemented with a function similar to SetCW but with the ability to vary the drag coefficient with angle like it is done with the airfoils. So if you are modeling a capsule with no wings, you could use the SetCW-like function to establish the drag on the vehicle. You could implement the horizontal and lateral lift forces as usual with the existing airfoil definitions, and just set the profile and induced drag terms to zero and let the appropriate drag model handle that.

Until then, I am wondering if an improved hack that might get something close to this could be implemented with one or more instances of the CreateVariableDragElement method. Just because it is variable doesn't mean you MUST vary it. You could potentially use this to set the drag on the capsule AND still use airfoil definitions for lift. The drag coefficient could be adjusted using the degree of deployment variable d which varies from 0 to 1. With multiple instances you could produce drag moments and torques as well. Just a thought.

 

[BrianJ]

Hi,
here's a pic just to show what I am "intuiting" about aerofoils

The assumption was probably that you were either flying something with wings OR you were flying a capsule on a ballistic trajectory,

There's the thing - capsules don't fly purely ballistically these days.
And in my rather naive mind, I can't really see why one orientation of an aerofoil is more problematic coding wise than any other.
Anyway, if its a silly idea, just ignore me!
Thanks and cheers all,
BrianJ

 

[Thunder Chicken]

Hi,
here's a pic just to show what I am "intuiting" about aerofoils

View attachment 32116

I just don't see anything in this diagram that can't already be accomplished with the existing airfoil definitions. You can set an effective planform area and drag coefficient combination and get any profile drag you need. Just because the "airfoils" are aligned in the horizontal and vertical directions doesn't mean you can't set them to have the drag properties of a brick.

The beauty of computational simulation is that you can program things that can't happen in reality.

The downside of computational simulation is that you can program things that can't happen in reality.

 

[Urwumpe]

Exactly: I think the misunderstanding is in the orientation of the airfoil definition and the resulting output. You need both horizontal and vertical functions to create the full 3D solution. Not more, because vertical lift, horizontal lift and drag are the components of the total aerodynamic force. The only real difference of the XY idea i see is a different reference vector, but that is something our current model already can do.

The only real advantage I see of a third axis being added to the model is having a less surprising way to define rotation moments around the z axis. Currently, we can't do it, we need to use AddForce or fake it with ailerons.

 

[BrianJ]

You can set an effective planform area and drag coefficient combination and get any profile drag you need.

Hmmm. I can see how to set the Drag Coefficient (Cd) to depend on AoA.
But it's what Orbiter does with the Cd to calculate total aerofoil drag, that has me perplexed.

EDIT: After looking at the API_reference guide, apparently Orbiter core calculates total aerofoil drag as:
Drag = Freestream-dynamic-pressure * wing-area * Cd

In which case, yes, it IS possible to simulate an XY plane aerofoil using the current arrangement.
One would just have to specify the Cd in the same manner as Lift Coefficient, yes?

My intuition is surprised that AoA has no bearing on the Drag, once Cd has been set.

OK, good!

Although I still think it would be a nice and elegant thing to have an AIRFOIL_CAPSULE option ;-)

Again, thanks all for your time and input.
BrianJ

 

[Thunder Chicken]

Hmmm. I can see how to set the Drag Coefficient (Cd) to depend on AoA.
But it's what Orbiter does with the Cd to calculate total aerofoil drag, that has me perplexed.

EDIT: After looking at the API_reference guide, apparently Orbiter core calculates total aerofoil drag as:
Drag = Freestream-dynamic-pressure * wing-area * Cd

In which case, yes, it IS possible to simulate an XY plane aerofoil using the current arrangement.
One would just have to specify the Cd in the same manner as Lift Coefficient, yes?

Yes. You simply need to take care that, for airfoils, the drag coefficient data is based on planform area as skin friction is usually the dominant source of drag. For blunt objects, the drag coefficient is referenced on the frontal area, as pressure drag is usually dominant.

So long as the product [math]C_dA[/math] yields the correct drag force, you can specify it how you like.

My intuition is surprised that AoA has no bearing on the Drag, once Cd has been set.

For an airfoil it absolutely does, due to induced drag. That is in the AirfoilCoeffFunc helper function.

It can also vary for blunt objects as well. For example, a cylinder flying lengthwise would have less drag than if it met the incoming wind at an angle.

Although I still think it would be a nice and elegant thing to have an AIRFOIL_CAPSULE option ;-)

There's nothing stopping you from rolling your own code, if you think it is necessary.

Again, thanks all for your time and input.
BrianJ

Cheers!

 

[Thunder Chicken]

The only real advantage I see of a third axis being added to the model is having a less surprising way to define rotation moments around the z axis. Currently, we can't do it, we need to use AddForce or fake it with ailerons.

Can you describe a situation where this is a problem?

 

[Urwumpe]

Can you describe a situation where this is a problem?

Rotation stabilized sounding rockets?

 

[Thunder Chicken]

Rotation stabilized sounding rockets?

Couldn't you define two airfoils in the same plane, with their centers of pressures on opposite sides of the vessel and with equal and opposite lift coefficients at 0 angle of attack? The center of pressure of the airfoil does not need to be on the plane of symmetry of the vessel; it is set with a vector based on vessel coordinates.

This is how things like stabilizers and rudders are established, but those are usually symmetric airfoils with lift coefficients of 0 at 0 angle of attack.