Project Air Breathing Turbojet Engine Model for Orbiter

[Thunder Chicken]

You can also use DBL_MIN for defining the thrust value then: Its the smallest positive number an IEEE 64bit floating point number can still display. 1.0 does still produce a small thrust.

Actually, setting the dummy thruster with infinite Isp connected to the main tank and setting a maximum thrust of 1.0 N means that the Orbiter status indicators will properly show main engine propellant level and will show the thruster level on a 0 to 1 range, which isn't perfect but it gives a visual indication of the throttle position (not actually the thrust). Pushing on a jet with the extra force of the weight of a single apple in the direction of flight when the actual engine can develop 65,000 to 95,000 apples' worth of thrust just means it is an extremely fuel efficient but not particularly helpful afterburner.

Not the worst hack ever. We're well within an order of magnitude of the correct answer, and even the factor is close to 1.0. I'm doing more horrible things in the engine model itself.

 

[Thunder Chicken]

First flight on the air breathing jet engine!





So far, so good. The code seems to work. Now what I need to do is get the flight model to actually behave like a fighter jet and not a fuel-laden brick. Using the force vectors there is some really wonky stuff going on:


Thrust is good, weight is good (heavy, but correct at full fuel). For some reason there are HUGE drag forces on the contact points, overall aerodynamic drag is way too high. Can't get airspeed above 80 m/s unless I reduce the fuel load to 10%.

Fuel consumption rates seem about right. You can't linger on afterburner or even just full throttle for too long.

Now to get the aerodynamic model banged into some semblance of a Mirage2000 and check out ceilings, loiter times, etc...

 

[Thunder Chicken]

I slapped the DG flight model in just to get something to behave and took it to 12 km. The code isn't updating thrust or Isp with altitude or airspeed, though I believe they are being calculated correctly. Something is wrong in this bit:

    //Use inputs and flight conditions to calculate jet engine thrust and Isp

    thrust = GetJetEngineThrust(throttle, afterburner, M_0, T_0, P_0, rho);

    //Calculate Isp

    Isp = GetJetEngineIsp(throttle, thrust);

    //Update Isp and thrust of user-defined main engine

    SetThrusterIsp(th_main, Isp);

    SetThrusterGroupLevel(thg_main, abs(thrust)/max_thrust);

 

[Thunder Chicken]

It's always the mundane details...

SetThrusterGroupLevel(thg_main, abs(thrust)/max_thrust);

should be...

SetThrusterGroupLevel(thg_main, abs(thrust)/(max_thrust*1000));

because max_thrust is passed in kN.

Now it seems to be working!

At sea level, nominal full thrust should be 65 kN from the SNECMA M 53 P2 spec sheet:



Decreases with speed (still at full throttle):





8.8 km (~29,000 ft) and Mach 0.53 is about all I can get out of the DG aerodynamics with this engine. Thrust at full throttle reduced from 65 kN down to 34 kN due to altitude and airspeed. Need to see if I can get back to KSC as I burned up almost all of the fuel (full throttle for better part of 20 minutes will do that).



Squeaked her in, shut down with 380 kg of fuel left.

I'm declaring victory! Still a lot of implementation details to sort out, but the model is behaving very nicely.

 

[Thunder Chicken]

I'm wondering how to implement the afterburner. Is it possible to have some code that basically does something like this?:

if (throttle == 1.0) and (user still pressing + key):
    afterburner = true;
else
    afterburner = false;

 

[hagiasophia420]

I'm wondering how to implement the afterburner. Is it possible to have some code that basically does something like this?:

if (throttle == 1.0) and (user still pressing + key):
    afterburner = true;
else
    afterburner = false;

DGIII/DGIV I believe used backspace to engage afterburner which imo is cool. I believe you can handle backspace by using constant OAPI_KEY_BACK

 

[N_Molson]

Hello, I think the rather large DG generates much more drag than the dart-shaped Mirage 2000.

For afterburner you have several choices. You can use hover, scram or (inverted) retro thrusters, as the 2000 has none of those. Now in simulators like DCS A/B engages once the thottle is close from full, like the last 10% of the throttle range manages A/B ; and it's not all-or-nothing. You can throttle the A/B, even though that throttle in my DCS experience works in "steps" like 20% of AB, 60%, and full.

 

[Thunder Chicken]

Hello, I think the rather large DG generates much more drag than the dart-shaped Mirage 2000.

Indeed it does. The Mirage 2000 has a service ceiling of something like 56,000 ft and Mach 2.2 on afterburner. I'll have to dive into the specs for the Mirage 2000 and try to get some more sensible numbers for sectional areas, drag coefficients, etc.. All of Kev's models had the flight performance of the ShuttlePB, strangely enough.

The idea is that, this model, in conjunction with an accurate aerodynamic model, should yield ceiling, Mach number, and general jet engine performance similar to a real aircraft.

For afterburner you have several choices. You can use hover, scram or (inverted) retro thrusters, as the 2000 has none of those. Now in simulators like DCS A/B engages once the thottle is close from full, like the last 10% of the throttle range manages A/B ; and it's not all-or-nothing. You can throttle the A/B, even though that throttle in my DCS experience works in "steps" like 20% of AB, 60%, and full.

The afterburner is an integral part of the engine, and its performance depends on the turbine exit temperature of the main engine. Most tables of engine data give thrust for both afterburning and non-afterburning with specific fuel consumption values for both. Carving it out as a separate thruster would require even more hacks to get it to function. Right now it is simply an additional fuel stream that enters the jet engine model calculations.

I am simply not going to be able to get down into the level of detail of detents, at what throttle position does the AB kick in, spool up/down, etc.. as that is aircraft-specific. The hope is that maybe this engine code would be a good starting backbone for an add-on developer who then could flesh out all of those specific details. The fuel flow to the afterburner could be customized any way the add-on developer pleases.

 

[Thunder Chicken]

Another way to think about this model is to think of how meshes and textures come together to make a good visual model. You can have a reasonably low-poly mesh, but with a nice texture that covers the sins it can be pretty good looking. You can also throw all the polys at it and leave nothing for a texture to do.

My model is the equivalent of a low poly model of the basic function of a jet engine. An abstraction layer can be implemented between this model and the user to tweak input and output performance to deliver a more faithful representation of a real engine. It should be generalizable to a number of different engines, and give you a very good starting point for general performance, as I demonstrated here:

Project - Air Breathing Turbojet Engine Model for Orbiter

There was some discussion in the Orbiter Development forum about development of air-breathing engine models in addition to the scramjet for use within Orbiter in this thread: https://www.orbiter-forum.com/threads/implementation-of-proper-air-breathing-engines-abes.40501/ To that end, I've been...

www.orbiter-forum.com

 

[Thunder Chicken]

FYI Inkscape is really useful in taking 3-view aircraft drawings and getting dimensions and areas that you can scale to use for add-on development. This took all of 2 minutes:



Scaling with the wingspan yields:

​

 

[kuddel]

Is that inches ? Seems a bit small to me.

Edit: Ah, you wrote about scaling Makes more sense now!

 

[Urwumpe]

FYI Inkscape is really useful in taking 3-view aircraft drawings and getting dimensions and areas that you can scale to use for add-on development. This took all of 2 minutes:

View attachment 29576

Scaling with the wingspan yields:

View attachment 29579​

Which tool did you use there for producing the three-view?

 

[Thunder Chicken]

Which tool did you use there for producing the three-view?

I grabbed it off of Wikipedia.

In Inkscape: Extensions/Visualize Path/Measure Path. If you have a closed filled path it can give you the area, centroid, and bounding box length and height. I believe it can also determine lengths along a particular path even if curved, but I haven't tried that.

 

[Urwumpe]

I grabbed it off of Wikipedia.

In Inkscape: Extensions/Visualize Path/Measure Path. If you have a closed filled path it can give you the area, centroid, and bounding box length and height. I believe it can also determine lengths along a particular path even if curved, but I haven't tried that.

You made me believe, there is a plugin for rendering a OBJ file as three-view.

Well, luckily, Blender can do something similar by rendering to SVG.

 

[Thunder Chicken]

You made me believe, there is a plugin for rendering a OBJ file as three-view.

Well, luckily, Blender can do something similar by rendering to SVG.

I wrote a script that will take an OBJ file and convert it to an Orbiter mesh. If you have an OBJ file, you can use FreeCAD to make three-views.

 

[Urwumpe]

I wrote a script that will take an OBJ file and convert it to an Orbiter mesh. If you have an OBJ file, you can use FreeCAD to make three-views.

Same if you just have an Orbiter mesh and Blender... and some tools.

 

[Thunder Chicken]

I'm going to have to get more familiar with the new aerodynamic model. There is a mountain of legacy stuff that seems to be ignored now.

 

[Urwumpe]

I'm going to have to get more familiar with the new aerodynamic model. There is a mountain of legacy stuff that seems to be ignored now.

Yeah, might be useful. The new function signatures are really helpful for implementing more advanced behaviour, like CoP shifts

 

[Thunder Chicken]

So I need some input from the professional programmers and experienced Orbiter add-on developers about where to go next.

My ultimate objective is to get this jet engine model cleaned up and distributed to the community in some useful way so others may use it in their add-ons, hopefully in some easy "plug and play" fashion. At the present I have it in a very basic configuration, and while I am a logical, methodical engineer, I don't do programming regularly and some of my code may be functional and well-commented but less than optimal. So, my questions:

1. What are potential "good" ways for this to be presented to the Orbiter community?
2. Is this something that, with the review and blessing of the keepers of the Orbiter code, that might be something that can be offered like Martin's scramjet implementation in future iterations of Orbiter?
3. Would these folks be willing to do a review of my code to get it up to a proper standard? This might actually need to be the first thing done, to properly answer Questions 1 and 2.
4. I am less than familiar with open source licensing terms, etc.. that might be relevant, especially if it is associated with Orbiter. Personally I'm happy if I just get attribution for the engine model and nobody sues me for trying to use this to make a real jet with it, and I would like to see lots of people use it happily without too much bother. Thoughts?

I am basically fiddling with this code in the context of Kev33's Mirage2000 add-on simply because I happened to analyze a SNEMCA engine that was appropriate for that aircraft and I needed to somehow actually fly the jet engine model to see how it worked. If I can get some word from Kev about the propriety of re-releasing an updated module for his Mirage2000 for Orbiter 2016 I'd like to do that at some point, but my real motivation is getting my jet engine code out.

I also have a good start on a document summarizing this model, similar to Martin's presentation of the scramjet in the Orbiter docs. I'm happy to run with that and can submit it for editorial comment and ultimate bundling with this code.

 

[Thunder Chicken]

I'd vote for inclusion in Orbiter or as a co-distributed library.

I'm thinking code modules or a library might be the least complicated way. I don't know enough (or anything, really) about libraries to determine the merits of that idea. Any pointers where I can get a entry-level understanding of them? I presume that the idea would be something akin to how OrbiterSound could be utilized by add-on developers?