Implementation of proper air breathing engines (ABEs)

DaveS

Space Shuttle Ultra Project co-developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,235
Reaction score
511
Points
203
Exactly. Why keep reinventing the wheel why can invent it once and share the know-how?
 

Thunder Chicken

Fine Threads since 2008
Donator
Joined
Mar 22, 2008
Messages
2,894
Reaction score
1,202
Points
113
Location
Massachusetts
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

Space Shuttle Ultra Project co-developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,235
Reaction score
511
Points
203
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

Fine Threads since 2008
Donator
Joined
Mar 22, 2008
Messages
2,894
Reaction score
1,202
Points
113
Location
Massachusetts
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

Space Shuttle Ultra Project co-developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,235
Reaction score
511
Points
203
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

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
4,874
Reaction score
1,447
Points
138
How about an aquatic simulation for submarines in Europa or Enceladus (or Earth)?
 

Thunder Chicken

Fine Threads since 2008
Donator
Joined
Mar 22, 2008
Messages
2,894
Reaction score
1,202
Points
113
Location
Massachusetts
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

99 40
Addon Developer
Joined
Jul 5, 2021
Messages
367
Reaction score
487
Points
78
Location
Cislunar Space
Website
www.orbithangar.com
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

Fine Threads since 2008
Donator
Joined
Mar 22, 2008
Messages
2,894
Reaction score
1,202
Points
113
Location
Massachusetts
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. :p

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. :ROFLMAO:

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

99 40
Addon Developer
Joined
Jul 5, 2021
Messages
367
Reaction score
487
Points
78
Location
Cislunar Space
Website
www.orbithangar.com
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. :ROFLMAO:
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

Addon Developer
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,259
Reaction score
787
Points
128
Location
Biddeford ME
Website
mwhume.space
Preferred Pronouns
he/him
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

Fine Threads since 2008
Donator
Joined
Mar 22, 2008
Messages
2,894
Reaction score
1,202
Points
113
Location
Massachusetts
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

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
36,825
Reaction score
1,487
Points
203
Location
Langendernbach
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

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,238
Reaction score
1,405
Points
203
Location
between the planets
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

Fine Threads since 2008
Donator
Joined
Mar 22, 2008
Messages
2,894
Reaction score
1,202
Points
113
Location
Massachusetts
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

Fine Threads since 2008
Donator
Joined
Mar 22, 2008
Messages
2,894
Reaction score
1,202
Points
113
Location
Massachusetts
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.


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.
 
Last edited:

Sword7

Member
Joined
Mar 23, 2008
Messages
94
Reaction score
7
Points
8
Location
Gaithersburg, MD
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

Member
Joined
Mar 23, 2008
Messages
94
Reaction score
7
Points
8
Location
Gaithersburg, MD
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.
 
Top