Implementation of proper air breathing engines (ABEs)

[DaveS]

Exactly. Why keep reinventing the wheel why can invent it once and share the know-how?

 

[Thunder Chicken]

Which is EXACTLY why we need this stuff in the orbiter core! You can't expect every addon dev who wants to do something with non-rocket engines to code all this complicated mess...

• One person who knows what they are doing should add this into the core so anyone can use it! It doesn't even need to be extremely complicated, a simplified model would work (even though my engineering mind screams "NO" about simplifying stuff).
• And not just for planes, what about Ingenuity on mars or the mission to Titan that is in the works?
• Every flight sim in existence has dealt with this; there are even some open-source ones out there. FlightGear, for example. It's free and open source (GPL), maybe we could borrow some code from there or at least see how it is done?

You are both pushing for a complicated mess to go into the core, but then say it doesn't have to be complicated?

Flight sims worth flying have very detailed individual performance models, and they don't use generic propulsion libraries because even common engine types like reciprocating or turboshaft engines have parameters that vary engine-to-engine. Heck, just put a different propeller on the same engine on the same aircraft and you can get wildly different performance.

Do you want a good, detailed, and accurate model, or an cheap, simple, and inaccurate one? Pick one. If you want a detailed model to go into the core, it would still require a lengthy list of parameters that the add-on developer would have to select and tailor for a given aircraft, and so they would need to know quite a lot about the engine. If it is a simple, inaccurate model, the add-on developer won't have control of it and if it doesn't work as desired, they're going to be forced to roll their own anyway.

In Orbiter, in order to do all the torques and such for a propeller-driven aircraft, I couldn't really use the Orbiter propulsion model at all. I had to make a dummy engine to consume propellant to mimic fuel consumption based on throttle setting, but the thrust and torques had to be implemented using AddForces.

Exactly. Why keep reinventing the wheel why can invent it once and share the know-how?

Because it has already been invented, the know-how exists, but it's very complicated?

 

[DaveS]

In Orbiter, in order to do all the torques and such for a propeller-driven aircraft, I couldn't really use the Orbiter propulsion model at all. I had to make a dummy engine to consume propellant to mimic fuel consumption based on throttle setting, but the thrust and torques had to be implemented using AddForces.

That was because you had to deal with Orbiter's currently limited implementation. Now that Orbiter is open source, you can get this done right from the beginning. Orbiter should really have different propellant tanks for the fuel and oxidizer. This would enable the simulation from the ground up of proper mixture ratios. It isn't just ABEs that have to worry about mixture ratios, rocket engines do as well. Getting the MR wrong can be catastrophic for a rocket engine and result in vehicle destruction, not really something you see in ABEs.

Currently the Orbiter implementation of engines is very simplistic, it assumes a steady thrust level at all times, when it should be varying, even producing more than 100% indicated. This was seen all the time with the shuttle OMEs when they were burning, it was never steady at 100%.

 

[Thunder Chicken]

That was because you had to deal with Orbiter's currently limited implementation. Now that Orbiter is open source, you can get this done right from the beginning. Orbiter should really have different propellant tanks for the fuel and oxidizer. This would enable the simulation from the ground up of proper mixture ratios. It isn't just ABEs that have to worry about mixture ratios, rocket engines do as well. Getting the MR wrong can be catastrophic for a rocket engine and result in vehicle destruction, not really something you see in ABEs.

The problem with the thruster implementation in Orbiter wasn't due to the fuel, it was that an engine with a propeller applies torques as well as linear thrust. The fuel consumption hack was trivial. Unless you want a hellishly complex "generic" engine model that can implement torques, this would still require an add-on.

Currently the Orbiter implementation of engines is very simplistic, it assumes a steady thrust level at all times, when it should be varying, even producing more than 100% indicated. This was seen all the time with the shuttle OMEs when they were burning, it was never steady at 100%.

This is not at all correct. Thrust can be varied according to throttle setting. The SSME/RS-25s could go to 109% because that was the thrust level relative to their original rating. The SSMEs were not exceeding their maximum thrust capacity, but due to performance upgrades they needed the engine performance indicators to go to 11 (or 10.9, anyway).

 

[DaveS]

The problem with the thruster implementation in Orbiter wasn't due to the fuel, it was that an engine with a propeller applies torques as well as linear thrust. The fuel consumption hack was trivial. Unless you want a hellishly complex "generic" engine model that can implement torques, this would still require an add-on.

This is not at all correct. Thrust can be varied according to throttle setting. The SSME/RS-25s could go to 109% because that was the thrust level relative to their original rating. The SSMEs were not exceeding their maximum thrust capacity, but due to performance upgrades they needed the engine performance indicators to go to 11 (or 10.9, anyway).

I'm talking about the Orbital Maneuvering System engines (OMEs, OMS was the entire system). But the SSMEs could also be affected by upstream propellant issues (like the E3 nozzle H2 leak during the launch of STS-93, which caused the system to increase the LOX usage to maintain the proper MR, which is 6:1 (6 LH2 to 1 LOX). Was also an issue in this STS-135 Ascent Sim run. It is mentioned by the BOOSTER officer around the 24:40 point in the video. Getting the MRs wrong could in this case lead to LOV situation by way of not having the propellant to make it to a TAL site and forcing the crew to bail out.

 

[GLS]

How about an aquatic simulation for submarines in Europa or Enceladus (or Earth)?

 

[Thunder Chicken]

I'm talking about the Orbital Maneuvering System engines (OMEs, OMS was the entire system). But the SSMEs could also be affected by upstream propellant issues (like the E3 nozzle H2 leak during the launch of STS-93, which caused the system to increase the LOX usage to maintain the proper MR, which is 6:1 (6 LH2 to 1 LOX). Was also an issue in this STS-135 Ascent Sim run. It is mentioned by the BOOSTER officer around the 24:40 point in the video. Getting the MRs wrong could in this case lead to LOV situation by way of not having the propellant to make it to a TAL site and forcing the crew to bail out.

I'd argue that this would be trivial to model in existing Orbiter as an add-on or as an upgrade to the propellant handling in the core, but it's not really the major problem for air-breathing engine modeling.

How about an aquatic simulation for submarines in Europa or Enceladus (or Earth)?

You can do this now in Orbiter if you make the oceans a part of the atmosphere and establish the fluid properties correctly. You might have to make your own versions of those planets to do this, but it is possible with config files.

Also, everyone needs to think about scope. This is Orbiter, and it wasn't intended to be a dedicated atmospheric flight simulator. It works very well dealing with aerodynamics of re-entry, spaceplanes, and such, but was never meant to offer a comprehensive representation of low Mach flight in an atmosphere. That fact that we can make and fly very credible aircraft in Orbiter is a testament to Martin and the physics he enabled. MS Flight Sim couldn't do spaceflight at all.

 

[Max-Q]

Flight sims worth flying have very detailed individual performance models, and they don't use generic propulsion libraries because even common engine types like reciprocating or turboshaft engines have parameters that vary engine-to-engine. Heck, just put a different propeller on the same engine on the same aircraft and you can get wildly different performance.

Do you want a good, detailed, and accurate model, or an cheap, simple, and inaccurate one? Pick one. If you want a detailed model to go into the core, it would still require a lengthy list of parameters that the add-on developer would have to select and tailor for a given aircraft, and so they would need to know quite a lot about the engine. If it is a simple, inaccurate model, the add-on developer won't have control of it and if it doesn't work as desired, they're going to be forced to roll their own anyway.

So let's see if I've got this right. For a simplified model in the core:

• Casual addon devs win, because they can at least get closer to realisim then right now.
• Serious addon devs with advanced coding skills are no worse off then before.

So who is at a disadvantage versus the way it is now?

MS Flight Sim couldn't do spaceflight at all.

X-Plane can, and pretty darn well at that.

 

[Thunder Chicken]

So let's see if I've got this right. For a simplified model in the core:

• Casual addon devs win, because they can at least get closer to realisim then right now.
• Serious addon devs with advanced coding skills are no worse off then before.

So who is at a disadvantage versus the way it is now?

Anyone who wants a super-duper magically realistic atmospheric flight model for their Blender add-on but who does not want to code it.

X-Plane can, and pretty darn well at that.

Yeah, but that's not MS Flight Simulator? Trying to rewrite Orbiter to allow super hi-fidelity atmospheric flight models would be like trying to take MS Flight Sim and turn it into X-Plane, which would be painful and would break more things than it would fix. Heck, in old MS Flight sim Earth was a cylindrical map and there was a ghost of Chicago at 100,000 ft AGL.

In seriousness, I could see making add-on module "templates" for basic reciprocating and gas turbine engines that add-on developers could use as a starting point for parameter setting and tweaking, but not something that could or should be baked permanently into the Orbiter core.

 

[Max-Q]

Yeah, but that's not MS Flight Simulator? Trying to rewrite Orbiter to allow super hi-fidelity atmospheric flight models would be like trying to take MS Flight Sim and turn it into X-Plane, which would be painful and would break more things than it would fix. Heck, in old MS Flight sim Earth was a cylindrical map and there was a ghost of Chicago at 100,000 ft AGL.

All true points. It is all about what the code is originally designed to do. All I was saying is that propellers and jets have a place in a space sim. (and that MSFS sucks).

In seriousness, I could see making add-on module "templates" for basic reciprocating and gas turbine engines that add-on developers could use as a starting point for parameter setting and tweaking, but not something that could or should be baked permanently into the Orbiter core.

I think that sounds like a good compromise. Also allows addon dev to tweak whatever stuff they want… SR-71 engine is a lot different then the turbofans on a 747.

 

[n72.75]

There is no reason that you couldn't package this jet engine API with an Orbiter release, but I don't think it should be part of OrbiterSDK.

Best of both worlds option. You get an "official" version, with the same license, but you keep the vessel API from becoming bloated.

 

[Thunder Chicken]

I think that sounds like a good compromise. Also allows addon dev to tweak whatever stuff they want… SR-71 engine is a lot different then the turbofans on a 747.

There is no reason that you couldn't package this jet engine API with an Orbiter release, but I don't think it should be part of OrbiterSDK.

Best of both worlds option. You get an "official" version, with the same license, but you keep the vessel API from becoming bloated.

I guess the first thing to clarify would be the goal. If all we're interested in is developing some basic air breathing engine templates and developing thrust models for them, I think the existing thruster management in the Orbiter SDK is more than adequate. Martin actually shows how the scramjet implementation was developed in the OrbiterSDK docs. Let's not break Orbiter unless we have to

I think making thrust models for Brayton cycle engines (turbojets, turbofans, etc..) could be implemented in a common code module. Reciprocating engines and turboshafts with a propeller would probably need to be a separate module. If torque effects were desired (shiver) that would be another battle for another time.

I teach power engineering and am pretty comfortable with the physics and thermodynamics involved in these engines, and while I am not a developer I think I could write up a generic code module for a turbojet engine that could be used. I did make some dlls back in the day but I would probably need one of the active Orbiter developers here to take it and clean it up for efficient execution and application in today's modern world.

 

[Urwumpe]

I teach power engineering and am pretty comfortable with the physics and thermodynamics involved in these engines, and while I am not a developer I think I could write up a generic code module for a turbojet engine that could be used. I did make some dlls back in the day but I would probably need one of the active Orbiter developers here to take it and clean it up for efficient execution and application in today's modern world.

Contributions can also be in the shape of math.

I once implemented the formulas of engineers into software for money, I am sure I can help there, if I again have some more time. But I know only the basic stuff about pumps and turbines, so any more professional aid would really be great. Especially getting the ODEs turned into something with less model errors would be helpful - this kind of math isn't my strength, I can only look for rounding errors in the implementation.

 

[jedidia]

I have been thinking about this a little more, and what I think would be nice to have in the core is an abstract thruster that separates the program-specific aspects of a thruster (placing it and applying the force vector and exhaust, and their automated re-placement during CoG shifts, as well as membership in a logical thruster group) from the physical aspects (propellant source and consumption, etc).

This would make any sort of middleware attempting to implement specific engine models a lot more comfortable. The main problem is that either you use the currently existing thruster, in which case you need ugly workarounds to deal with its single propellant source and fixed relation between propellant consumption and total mass flow, or you start from scratch and have none of the above conveniences (which is not just an issue of having a lot of additional work, it's also essentially code duplication and extremely bug-prone).

 

[Thunder Chicken]

Contributions can also be in the shape of math.

I once implemented the formulas of engineers into software for money, I am sure I can help there, if I again have some more time. But I know only the basic stuff about pumps and turbines, so any more professional aid would really be great. Especially getting the ODEs turned into something with less model errors would be helpful - this kind of math isn't my strength, I can only look for rounding errors in the implementation.

Ah, you have people skills and can work with engineers. Excellent!

I'm a thermodynamics professor on summer vacation so I guess I have no excuse to not do this.

I have to pull out some paper and think a bit about implementation. A quasi-steady model similar to the existing scramjet implementation should be easily doable, but it wouldn't have transient terms like turbine lag, etc.. Putting some flameout cut-offs based on air/fuel mixture should be easily doable too. It would basically be something that behaves like a nominal jet engine with a FADEC but can't fly into orbit due to air starvation.

I have been thinking about this a little more, and what I think would be nice to have in the core is an abstract thruster that separates the program-specific aspects of a thruster (placing it and applying the force vector and exhaust, and their automated re-placement during CoG shifts, as well as membership in a logical thruster group) from the physical aspects (propellant source and consumption, etc).

This would make any sort of middleware attempting to implement specific engine models a lot more comfortable. The main problem is that either you use the currently existing thruster, in which case you need ugly workarounds to deal with its single propellant source and fixed relation between propellant consumption and total mass flow, or you start from scratch and have none of the above conveniences (which is not just an issue of having a lot of additional work, it's also essentially code duplication and extremely bug-prone).

This is something of a separate issue as for air-breathing engines the majority of the reaction mass is the air, so the propellant flow simply is the fuel flow. I would think that it would be easy enough to modify the engine code to accommodate a version change within Orbiter that alters how propellant is handled.

 

[Thunder Chicken]

This looks potentially useful for a turbojet engine model. I'll need to examine it in detail but it seems to have quasi-steady and fully transient models implemented, and validation against data, which is nice.

https://www.icas.org/ICAS_ARCHIVE/ICAS2012/PAPERS/537.PDF

EDIT: Of course the data is non-dimensionalized to the point of uselessness and many of the inputs are not provided. So much for that.

 

[Sword7]

Yeah. Great idea for air-breathing engines like turbofan and propellors. Challenging aerodynamics on varying planets with different atomspheres like in Avatar, Star Wars, Star Trek and others. Remember Mars helicopter on Mars?

 

[Sword7]

I'd argue that this would be trivial to model in existing Orbiter as an add-on or as an upgrade to the propellant handling in the core, but it's not really the major problem for air-breathing engine modeling.

You can do this now in Orbiter if you make the oceans a part of the atmosphere and establish the fluid properties correctly. You might have to make your own versions of those planets to do this, but it is possible with config files.

Also, everyone needs to think about scope. This is Orbiter, and it wasn't intended to be a dedicated atmospheric flight simulator. It works very well dealing with aerodynamics of re-entry, spaceplanes, and such, but was never meant to offer a comprehensive representation of low Mach flight in an atmosphere. That fact that we can make and fly very credible aircraft in Orbiter is a testament to Martin and the physics he enabled. MS Flight Sim couldn't do spaceflight at all.

It is possible to do both space and atomspheric flight simulator in same software.

 

[Thunder Chicken]

I'll just leave this here:

https://www.orbiter-forum.com/resources/jet-engine-model-library-for-orbiter-2016.5463/