[1.0.5] Advanced Jet Engine v2.6.1 - Feb 1

[AdmiralTigerclaw]

backwards air intakes

Found your problem.

Though I do understand what technical problems that can represent. Off-axis drift in VTOLs with a hard cutoff like that, and bam, game over. Though to be fair, 10 m/s is quick. 19 and some change knots. (22 mph) And unless proper suction is simulated, that is enough to kill a turbine. (Turbines cannot even start in a strong tail wind.)

[Virindi]

Starting maybe, but the engine is already running (even with the afterburner lit!) and thrust is zero at 10.1m/s with AoA at 90 degrees. I think arguing that this is realistic behavior is a little beyond reason

It's not like I'm trying to go to orbit at mach 4 with backwards intakes.

[camlost]

That problem is true, the logic behind it is that engines need a certain inlet area, which must be projected to the direction of freestream. At low speed (in the current build 10m/s) the projection is neglected to help takeoff/landing etc.

Surely, you can increase the threshold to maybe 30m/s, or do you have some better model in mind? Note that the NASA code is based on steady-state equations not transient-state equations

[AdmiralTigerclaw]

Well, the obvious problem is that jet engines don't rely entirely on the freestream. A certain percentage of their power runs the intake fan, which produces suction.

Perhaps there needs to be an inlet curve 'suction' value that is based on the power of the combined engines they feed.

I'm sure there's a curve to be found somewhere that essentially points out a certain percentage of the stream is induced airflow.

Like, as a no-reference example, an engine is producing X kN of thrust, 3% of that value translates into active intake. Which means that there should be a certain amount of suction from any intake slaved to that engine, regardless of direction. And it would take some seriously hefty off-axis travel to kill the engine.

In fact, if you think about it. A percentage tie-in to the power makes sense. If the off-axis rate of travel at a poor angle of attack for the intake gets too high. Engine power dips. As engine power dips, suction percentage drops. As that occurs, engine power sags even more, and the cycle gets worse until you have an unstart and/or compressor stall. If you don't correct your AoA and velocity in relation to the intake, your engine will spool down and die completely. (IoW: Not a KSP 'flameout' but an action 'engine switched to off' state. Where you have to actively restart it.)

Edited August 29, 2014 by AdmiralTigerclaw

[camlost]

What you said is not wrong IRL, but keep in mind that AJE is built upon NASA EngineSim, which does not simulate airflow across an inlet, plus some black magic I cooked to give inlets some meaning. Implementing what you said means major revision with the original code, which I don't see much point doing for now.

[AdmiralTigerclaw]

I'd think, if you're going to do a major code revision. Better to do that early. Seems counter-productive to put it off while working smaller code issues out, then finally decide to do the overhaul, and effectively toss out all the little-things work that went into the old version.

Now, just being me and not having seen the engine code, I can't think it TOO difficult to get a modifier for a short term 'tweak'. At least, in my head the algorithm seems simple. Get a per-engine thrust out value, multiply out the percentage to get the power returned to the intake fan based on a per-engine basis. Then collectively add all engines together for a master suction value. Distribute the suction value across the inlets in a manner that modifies the 'effective angle of attack'. (IE: If your AoA with the free stream on an inlet is 90 degrees, the suction modifier would, as a no-reference example, pull it to 75 degrees.)

It's a quick and dirty thought.

Now, when you said this is built upon EngineSim, do you mean you actually threw EngineSim's code into it?

[Virindi]

Perhaps an appropriate hack would be to simply take the greater of two values. One, the result of the existing algorithm, and two, a minimum value based on the current power of the engine minus the projection of velocity in the opposite direction of the intake. Just tune it so that >100m/s with a big engine, you're not going to get any power at >90 degrees AoA. If you want to get fancy, use a time weighted average of recent engine power outputs so that spooling down due to intake starvation is a gradual process (turbine blades do have inertia). When the engine goes from off to on, reset the average to zero.

I know, I know, hax, but it's better than the current behavior in the meantime before any bigger changes fix it. There shouldn't be a velocity 'cliff' beyond which an engine goes from nearly full power to zero instantly, and a powerful already running engine should be able to operate in strong tailwinds, just not backwards at extreme speed.

Unfortunately, this does also impact behavior when you get into a flat spin. Normally, they are unrecoverable with this plugin because you lose all engine power (unless you have a fueled rocket on board). In this case, it isn't just the direction of travel that matters, but also the rate of rotation and the distance of the intake from the center of rotation. For a very long plane with an intake at the end, the 90 degree air speed would be much higher. At the center of rotation, it would be almost zero.

Don't know if it is already done but when calculating the air velocity vector, it should take into account vessel rotation. This would restore some of the difficulty to flat spins if adding a sliding minimum power level to low speed (for hax you could just use the vessel CoM and intake distance from CoM, even though this isn't actually a realistic center of rotation).

Edited August 29, 2014 by Virindi

[camlost]

@AdmiralTiger, we are not doing major revision of the algorithm, in the future we're looking forward to a new transient-state model from ferram

@Virindi, what you suggest is kind of counter-intuitive. A simple hack just involves the projection function, which is cosine currently.

                if (vessel.srfSpeed > 10 && intake.intakeEnabled)
                    cosine = Mathf.Max(0f, Vector3.Dot(vessel.srf_velocity.normalized, part.FindModelTransform(intake.intakeTransformName).forward.normalized));
                else
                    cosine = 1f;

[Virindi]

Yeah, but you would want to maintain loss of thrust when the intake is backwards but give it a smooth curve that decreases without discontinuities until you hit a certain level where the engine would no longer be running.

I'm thinking more about the desired results, really.

I want to fly my VTOL but I also really enjoy the added difficulty this mod creates for SSTOs

Edited August 30, 2014 by Virindi

[Virindi]

Okay, consider a smooth curve like the following:

				if (!intake.intakeEnabled)
				{
					cosine = 1f;
				}
else
{

				float realcos = Mathf.Max(0f, Vector3.Dot(vessel.srf_velocity.normalized, part.FindModelTransform(intake.intakeTransformName).forward.normalized));

				float fakecos = (float)(-0.000123d * vessel.srfSpeed * vessel.srfSpeed + 0.002469d * vessel.srfSpeed + 0.987654d);
				if (fakecos > 1f)
					fakecos = 1f;

				cosine = Mathf.Max (realcos, fakecos);
}

Giving you 100% intake at 10m/s, with a smooth downward curve until it hits 0% at 100m/s.

Sorry for the overly complex suggestion, I didn't realize this was all in the intake module until I looked at the actual code. My experience with KSP modding is limited.

I just tested out my little rolling jet tester (a jet attached to a fuel tank) and this caused the speed to self limit at around 70m/s.

Edited August 30, 2014 by Virindi

[aphenine]

One of the things I'd really like to do is to write some code that would take into account scramjets. At the moment, the NASA EngineSim code doesn't do scramjets and it would be nice if it did. I don't know if it's practically possible for me to do this, but I've already had a bit of fun trying to look into it and, well, scramjets are both more complicated and less complicated than normal engines. They're more complicated than normal engines because they have fuel mixing effects and supersonic shock boundaries. However, they're simpler in that the air-flow further down the engine doesn't influence air-flow up the engine and I've already found a paper that uses a one-dimensional model to model the fuel mixing efficiency.

I know this is really hard, and I'm aware it's unlikely I'll succeed and I'm OK with that. But I'd like to try and basically, I was wondering, does anyone on here actually understand how the NASA EngineSim code works and would they be willing to field stupid questions from me?

[NathanKell]

I, uh, presume camlost does. But I can't speak for her/him.

In my fork I've converted some of the variable names to intelligible things, and I more or less get how it runs; ferram gets the theory behind it much better than I do though. Note that the theory very definitely *does* presume subsonic flow and combustion IIRC.

You can PM us, or drop by #kspmodders some time (easier, realtime); at least one of us will probably be on (although I'm at my parents for the weekend so less available) so ping us (i.e. use our nick in the chat message, or send a query/PM).

[camlost]

Fellows,

If anyone wants to understand how EngineSim works don't dive into the code (too obscure and no comment). There's a paper describing the principle on the NASA site which is not too hard for a layman like myself IMO.

http://www.grc.nasa.gov/WWW/k-12/airplane/EngineTheory.pdf

As you can see, the program is limited for normal combustion, while supersonic combustion is not supported. To make a SCRAMjet you have to 1) find out the right equations , or 2) find out real data for SCRAMJets, so in the future it can be used in BJE. Both tasks should be hard, but the latter one seems a bit easier

[aphenine]

Thank you camlost. I have a feeling it's going to be really useful, but I'm not going to jinx it by saying it will be. However, I've already identified a few equations I know are in the code, and the indices are suddenly very explicable. Thank you.

[aphenine]

Well, I think I am a stupid idiot, because I just realised how hard all this is and how much I don't know. I've worked out that the NASA EngineSIM definitely uses subsonic flow inside the engine itself, because the first equations for the intake works out the stagnation pressure and temperature, both of which assumes the air slows down almost to zero. I was kinda hoping there would be some hints as to dealing with supersonic flow from the equations given with regards to the intakes, or there would be some hints as to handle velocity inside the engine. But no.

Also, the paper I was looking at regarding scramjet fuel flow, I've just realised how they solved things. They used a full set of ODE solvers written in Fortran90 on a set of differential equations I'm still looking at and not understanding. No amount of physical intuition is helping. The whole thing is scary and terrifying and I couldn't think of a way forwards. For one thing, using any kind of ODE solver scares me, since I don't really understand the complexities of all of that, nor do I know how to get one working in C#. However, it also strikes me as severe fail in trying to get something simple to work on limited processors in real-time during the game.

However, having said that, I was lying in the bath after Zumba (why are baths such good places to think?) and I realised that I might be able to do something with solving a scramjet engine if I modelled the interior as a set of discrete volumes. If I assumed that temperature, pressure, velocity, density and volume were all constant over such a volume, and I made the volume small enough to work through, I could maybe achieve something. It also kinda matches the method used in EngineSIM, which merely models the temperature and pressure through discrete parts of the engine (except supersonic flow appears to need way more variables of state). It might also help because different effects occur at different parts of the engine and I might be able to accurately model certain bits with less complex code.

That would require me understanding what the hell was happening in the engine and writing good equations (it seems I might need something like ODEs in terms of points along the engine length) to fully model the engine. But wait, where have I seen ODEs in terms of points along the engine engine length? Yes, in that paper I said scared me and I didn't want to solve. So maybe I could use those equations (or bits of them) and work them out point by point, or something, using the method outlined above? Anyone with numerical analysis experience know why I should not do this (speak now or forever hold your peace)? I know it would be a cludge, but it might give us something slightly more accurate than the default KSP model and right now something has got to be better than that, right?

Anyway, if you followed that, any thoughts? (And if you didn't, well, writing it out helps me think, so thanks for just being there).

Edited September 2, 2014 by aphenine

[camlost]

I think that's very difficult. Firstly I'm not sure what you proposed is correct, secondly, even if the code is implemented, the parameterization is still a problem, as there's only been two unsuccessful tests done by USAF, and the data is undoubtedly classified. The reason for using equations not curves for jet engines and propellers is that we want to model various real-life engines with moderate amount of work, but there's only one Scramjet in the world. For these 'uncommon' things like scramjet, SABRE, PDE etc. it's more sensible to just use curves.

[Taverius]

Other people have done SCRamjet research, but all the data from everyone is classified.

All we know is that if you're the USAF, and have NASA people helping you, and build a craft around the engine, and launch it from very high up going really really fast, if you perform the correct incantations, mars is in cancer, jupiter in taurus and its the 3rd monday of the month on an odd-numbered day, you'll have a ~50% chance of the damned thing igniting.

[aphenine]

*sigh* I get where you are coming from. I even agree with it a little. But not entirely.

I started playing KSP because I wanted to know whether it was possible to create cheap vehicles that would allow people to access orbit. At the moment, it's blindingly obvious that rockets are not the way forwards if we want to do that. I want to know because, since I was young, I've always been a huge fan of sci-fi. I've devoured it and lived in the various future worlds other people have created and its been fun. But, I've always wanted to know things like how likely it is and this is one of the fun ways I have of exploring that. RSS is fun, and a chasing of realism is fun, but I find it limiting. I want to know what the next generation of technologies might do and whether they make any sense. To do that, I want to have some realistic models that would let me play with and figure out how they would work. I don't just want to make something up.

Why scramjets? Well, I started playing KSP and I could design, using the standard KSP and B9 parts, spaceplanes that would fly up into orbit so successfully that it's not a design challenge any more. The designs I have are really simple and, because of the incredible fuel efficiency and the loveliness of Kerbin, they work amazingly. I want to know whether a similar approach will work on the Earth, what I would need for it to work or whether the scaling factors preclude that. There aren't really any designs that would allow that except for hybrid ramjet/scramjet engines paired with SABRE engines and I've been wanting to explore that. I've created some curve-based scramjet engines and I want to go further.

As for the fact that most of the research is classified, this is true, and it is annoying. However, there's still a lot of stuff out there. The paper I have compares its model to real life results in a wind tunnel. That's just one paper I have access to outside a University paywall, not the other stuff that's so tantalisingly out of my reach. There are probably others, and you all seem to have forgotten HySHOT and a couple of other programs that are out there doing stuff, plus the fact that Lockheed Martin wants to build the successor to the SR-71 Blackbird using a ScramJet engine design (it will be called the SR-72), with the engines provided by Rocketdyne, if they secure funding from Congress (which is doubtful, but could happen, and if not now, at some point). I don't understand why you're happy to have modelling for SABREs (which have a similar could happen approach) and not for scramjets.

As for my approach, I have no idea whether its the right one. I think, though, I would like to give it a go, since I think only testing it would see if that's so. I'm asking if anyone has any specialised knowledge that might be useful and might help me, or any useful experience, assuming you want to give it. For example, you all seem to be bright people, so I thought one of you might have done maths numeric work (I'm afraid my numerical analysis work has tended towards analysing parametrisation meshes in n-dimensional spaces), so you might have experience about whether what I'm doing is stupid or not (I was surprised about the number of papers and methods surrounding that one field alone, let alone something as well travelled as the fields of ODEs and PDEs). Or about the aeronautics, which I know nothing about. Still, you've been light on that information and instead told me your opinions about whether what I'm doing is worthwhile in the first place. Of course its worthwhile to me... Grrr....

[NocTempre]

What are the differences and overlap between KIDS and AJE?

[Hodo]

What are the differences and overlap between KIDS and AJE?

AJE does to air breathing jet engines what FAR does to the atmosphere. It makes them behave in a realistic manner not in some fantasy fashion.

KIDS just rescales all the ISPs of everything to be more in line with the scale of Kerbin vs Earth.

[dreadicon]

I likewise support SCRAM engines in KSP, at least when using this mod. From what Ive read, they aren't exactly the most overall useful of engines, given their lower ISP than RAM Jets, but they would fill that much desired 'missing link' between upper atmosphere and low orbit. From what I've read, they would be most appropriate as a single part which takes air in the front, and thrusts out the back. because they don't slow the air down, I dont see how parts which can 'route' the air through the ship in some complex manner would even work. Technically they should only be able to accept air from their own intake. I don't quite have the skills you are looking for with this, but I'd be more than happy to apply my general knowledge of math and engineering with some Google fu and find some answers if someone had the model all set up. It wouldn't be perfect, but it would be a decent approximation of the theoretical behaviors. I've done a fair number of config files in my day, so I could handle that. The Mode/Mesh creation and loading is greek to me though.

[nli2work]

so how do I get the numbers for engines? use nasa's sim program? propeller engine data are derived from the same software as well? I'd like to get my engines AJE friendly in the future.

[Taverius]

I likewise support SCRAM engines in KSP, at least when using this mod. From what Ive read, they aren't exactly the most overall useful of engines, given their lower ISP than RAM Jets, but they would fill that much desired 'missing link' between upper atmosphere and low orbit. From what I've read, they would be most appropriate as a single part which takes air in the front, and thrusts out the back. because they don't slow the air down, I dont see how parts which can 'route' the air through the ship in some complex manner would even work. Technically they should only be able to accept air from their own intake. I don't quite have the skills you are looking for with this, but I'd be more than happy to apply my general knowledge of math and engineering with some Google fu and find some answers if someone had the model all set up. It wouldn't be perfect, but it would be a decent approximation of the theoretical behaviors. I've done a fair number of config files in my day, so I could handle that. The Mode/Mesh creation and loading is greek to me though.

You don't need SCRAMjets for that.

Kerbin's escape velocity is so low by the time you reached the speeds necessary to ignite a SCRAMjet, your apoapsis is already outside the atmosphere.

[camlost]

so how do I get the numbers for engines? use nasa's sim program? propeller engine data are derived from the same software as well? I'd like to get my engines AJE friendly in the future.

Use the programs in \AJE\AJETester that I wrote. Check out the picture and readme. Or, you can tell me or NathanKell or others what kind of engine you're making

[Guest]

You don't need SCRAMjets for that.

Kerbin's escape velocity is so low by the time you reached the speeds necessary to ignite a SCRAMjet, your apoapsis is already outside the atmosphere.

That's assuming you're on Kerbin. RSS is where they'd shine.