Project Air Breathing Turbojet Engine Model for Orbiter

[Thunder Chicken]

I'm not sure what to make of this. I am at full throttle level on the deck, thrust force looks fine and is apparently much greater than the drag force...



But I'm hardly accelerating?



I'd expect a linear acceleration of about 0.4 g with a 45 kN thrust imbalance and a 10,660 kg aircraft + fuel load. The gravity force is correct for the specified aircraft mass and fuel load in the addon. But the linear acceleration is right about 0.

 

[Face]

Do you apply additional forces in the code with AddForce()?

 

[Thunder Chicken]

Do you apply additional forces in the code with AddForce()?

No. I very deliberately did not want to use AddForce() in this implementation. The specified thrust is correct for what should be applied by the model through the thruster definitions.

There is a drag expression for cd in VLiftCoeff, that is called using CreateAirfoil3.

    double eaoa = aoa + wing_pitch; //effective angle of attack of wing
    *cl = Kp * sin(eaoa)*cos(eaoa)*cos(eaoa) + Kv * cos(eaoa)*sin(eaoa)*sin(eaoa); //Polhamus model for delta wings
    double pd = 0.003  // profile drag
    *cd = pd + oapiGetInducedDrag(*cl, wing_aspect_ratio, wing_effectiveness) + oapiGetWaveDrag(M, 0.75, 1.0, 1.1, 0.001);

CreateAirfoil3(LIFT_VERTICAL, _V(0.0, 4.0, 0.0), VLiftCoeff, 0, mean_chord_length, wing_area, wing_aspect_ratio);

and projected area and wind coefficients in SetClassCaps:

SetCW(0.09, 0.09, 2, 1.4);
SetCrossSections(_V(24.33, 47.70, 5.07)); //Scaled projected areas of Mirage2000 [sq. m]

Reading the API reference, SetCW is from the legacy model and are supposedly ignored when airfoils are defined, so they shouldn't be doing anything. But at this flight condition, if they were used, it should deliver about 32 kN of drag, which would be a big chunk of the discrepancy. I'll comment this out and see if it changes anything.

EDIT: I did this and it made no difference to the drag. Interestingly enough, I also commented out the SetCrossSections and THAT made no difference. All of the drag seems to be defined by the airfoil.

The drag coefficients in the airfoil definition should be pretty low at low angle of attack.

Acceleration is absolutely zero here (about 200m altitude, Ma 0.9) with 30 kN excess thrust.

 

[Thunder Chicken]

OK, this is deeply weird. I set cd = 0 in all the airfoil definitions, and indicated drag is now 0 (as it should be), and here I am not accelerating at all at full throttle with NO drag, tops out at Mach 1.3:

 

[n72.75]

Do you have any addforce calls?

 

[Thunder Chicken]

Do you have any addforce calls?

No.

I've also rolled the airfoils back to CreateAirfoil instead of CreateAirfoil3, get exactly the same behavior.

 

[Face]

Well, at this point I'm afraid I can't really help without trying to debug the code myself. Do you have the code up somewhere to review?

 

[Thunder Chicken]

Well, at this point I'm afraid I can't really help without trying to debug the code myself. Do you have the code up somewhere to review?

I can PM my solution to you if you'd like to take a look at it.

 

[Thunder Chicken]

Acceleration seems to be correct at low speed (takeoff roll) where drag should be small anyway. But there is definitely some drag behavior. Do flight control surfaces contribute to drag? I don't see anything in the API reference indicating so.

 

[Thunder Chicken]

Hmmm.... I wonder if it is something to do with the ground contact model. There are force vectors at the contact points while rolling, and strangely enough the velocity tops out exactly at the same Mach number when I am rolling along the ground at full thrust:



If I comment out SetTouchDownPoints, apparently there are "default" points still created based on the mesh, which apply forces?



If I additionally comment out all the airfoils, flight control surfaces, and contact points, and let it accelerate to speed, it now displays a drag force in addition to the contact forces?



EDIT: If I explicitly put in SetSurfaceFrictionCoeff(0.0, 0.0) that gets rid of the contact friction forces, but there is still some drag force cropping up?


What the heck is going on?

 

[Thunder Chicken]

OK, I might have found the issue, and I think it's in Orbiter.

When I remove all of the aerodynamic surfaces and use the legacy drag model, and explicitly set all the wind coefficients to 0:

SetCW(0.0, 0.0, 0.0, 0.0);

the mystery drag force disappears in the force vectors and I accelerate ad infinitum according to the thrust produced by the engine, which is correct.

If I restore the aerodynamic surfaces, and set cd to zero for all of them, SetCW is ignored, the mystery drag force seems to re-appear but it doesn't show up in the force vectors.

 

[Thunder Chicken]

Another discovery - setting the drag coefficient cd in the airfoil definition to a negative number (*cd = -1) actually does produce negative drag i.e. thrust in Orbiter. The faster you go, the faster you go! Nudge the throttle and you're at light speed in no time!

It's clearly incorrect but some error handling might be in order.

 

[n72.75]

I'm not sure that's strictly an error though. Obviously it doesn't physically make sense, but the alternative would be something checking the drag coëfficient every time step which adds some overhead.

 

[n72.75]

It's probably worth taking a close look at the visual helper code in the Orbiter core (for Orbiter developers). I know the moments are wrong for example. They actually show mass-normalized moments, probably because that's what Orbiter uses in its angular state propagators.

 

[Thunder Chicken]

It's probably worth taking a close look at the visual helper code in the Orbiter core (for Orbiter developers). I know the moments are wrong for example. They actually show mass-normalized moments, probably because that's what Orbiter uses in its angular state propagators.

Yes, but there is also some mystery drag force behavior independent of the visual helpers that can only be over-ridden by setting the wind coefficients to zero using only the legacy model. If I try to put airfoils on my aircraft the mystery drag force is back since SetCW is ignored in that instance, so it can't be shut off, and doesn't show up in the visual helpers.

 

[Thunder Chicken]

I'm not sure that's strictly an error though. Obviously it doesn't physically make sense, but the alternative would be something checking the drag coëfficient every time step which adds some overhead.

Well, the lift and drag coefficients in the airfoils are generally functions of Reynolds and Mach numbers and angle of attack, so these coefficients must be updated continuously anyway. Bounding them to remain non-negative shouldn't be a big stretch.

 

[Thunder Chicken]

Now that Orbiter is open source, is there any way to provide a useful bug report?

 

[Thunder Chicken]

Just for laughs, since I can shut off all the drag and make the aircraft car frictionless, I did that to see what the maximum top speed was. It tops out at just over Mach 4 at sea level.


This is when the momentum of the exhaust gas matches the momentum of the incoming air and so thrust goes to zero, so you can't fly any faster than this even if you have a greasy slippery low drag jet. This is a real effect.

 

[Thunder Chicken]

Another weird finding - if I disable the vertical and horizontal airfoil definitions, none of the supposedly unrelated flight controls (ailerons, rudder, elevators) work. The animations showing the inputs still work, but no forces are applied. If I enable just one of them, all of the flight controls apply forces.

What. The. Heck...?

 

[Max-Q]

I've gone back to my Python code to sort out the issues with the model. One of my assumptions on the maximum volume flow rate of air through the engine was a little too quick and dirty, and I have a better model for variation of air density at the engine inlet. This will require the user to supply the inlet diameter of the engine in addition to the other required engine parameters, but I think that isn't unreasonable. It should now model ram compression/expansion in the inlet appropriately accounting for the difference in air velocity from freestream to the inlet. If the inlet velocity is less than flight velocity, inlet air density increases due to ram compression; if it is greater, inlet density decreases.

I've also updated the handling of the afterburner to account for available air for combustion accounting for the oxygen consumed in the combustor. This will reduce afterburning thrust with altitude which I believe was the cause of the "runaway" behavior I was seeing.

What do we do about variable geometry inlets, like on the XB-70 or SR-71?
XB-70 has movable ramps to change the inlet area, SR-71 does the same thing with a movable inlet spike.

In the case of the XB-70 specifically: