[1.3.1] Ferram Aerospace Research: v0.15.9.1 "Liepmann" 4/2/18

[Taverius]

@feram4: There's a bug in the config file for the aero engines here: You're using 'key' in the thrust curve, but you should be using '@key,index'.

Specifically, you're doing:

@PART[turboFanEngine]
{
	@MODULE[ModuleEngines]
	{
		@maxThrust = 140
		@velocityCurve
		{
			key = 0 1 0 0
			key = 300 0.7 0 0
			key = 1400 0.8 0 0
			key = 1800 0 0 0
		}
	}
}
@PART[JetEngine]
{
	@MODULE[ModuleEngines]
	{
		@maxThrust = 140
		@velocityCurve
		{
			key = 350 0 0 0
			key = 300 0.2 0 0
			key = 0 1 0 0
		}
	}
}

The result is that instead of modifying the thrust curve, you're adding to it:

Instead, do this:

@PART[turboFanEngine]
{
	@MODULE[ModuleEngines]
	{
		@maxThrust = 140
		@velocityCurve
		{
			@key,0 = 0 1 0 0
			@key,1 = 300 0.7 0 0
			@key,2 = 1400 0.8 0 0
			@key,3 = 1800 0 0 0
		}
	}
}
@PART[JetEngine]
{
	@MODULE[ModuleEngines]
	{
		@maxThrust = 140
		@velocityCurve
		{
			@key,0 = 350 0 0 0
			@key,1 = 300 0.2 0 0
		}
	}
}

Also, tell me who makes these magical turbojets that give 100% thrust on the runway, the us air force would like to know ;D

[Tiron]

@tiron: The DSI Intake is a 100% stock intake with perfectly normal values ... nothing weird there, check yourself. Not sure what could be wrong with it, though I'll check.

That's the part that confuses me more than anything. The DSIs are most definitely the cause of the problems I'm having, I'm just not sure WHY or how to clear it. Despite having solved it once already.

That's a screenshot of the last flight I had on that plane before I fixed it. The spiral of sparks is because I'm in the midst of a very slow spin caused by the left engine basically constantly flaming out and immediately re-igniting. It only did that on that flight, where I'd replaced the Sabre S intakes with the cone intakes from your very own mod, because the turbojet version of the plane didn't have that problem and I thought it might be the Sabre intakes.

Prior to that, it had been just flat flaming out, and then reigniting after it had yawed off axis a ways (?!). I was subsequently able to determine that closing both DSIs stopped it. With both of the DSIs closed, Mechjeb was able to correctly compensate for the intakeair dropping with altitude and prevent a flameout. I then stripped the DSIs off and replaced them with new ones, in approximately the same position, and the problem went away. And stayed gone even after I put the Sabre S intakes back on it.

I'm now having the same problem on my Valkyrie rover carrier SSTO:

Same symptomology: one engine flames out at altitude, with FAR saying I still have plenty of air and Mechjeb not cutting the throttle to prevent it like it's supposed to. Just like the first time, it started after making some adjustments to the plane that didn't involve the DSIs, after having successfully flown it clear to orbit without issues(Or in this case, not just a single flight to orbit, but also to the Mun and back.) Just like the first time, closing the DSIs causes Mechjeb to correctly compensate for the intakeair drop and prevent the flameout, and FAR to correctly indicate that I just barely have enough intakeair as it's doing so.

The difference being that this time, replacing the intakes isn't helping. I've swapped ALL of the intakes out multiple times, to no avail.

[ferram4]

@Tiron: It might be some oddity in the model that causes FAR to have problems with the inlet's area calculation. I would suspect that the strange air intake problems are due to the angle of the model transform being used for the "intake forward" direction. Try angling the DSIs off by the amount that the plane yawed off axis and see if that "fixes" the problem. If it does, try reproducing the problem without FAR installed (I see know reason why FAR should affect the air intake behavior, but who knows, I could have messed up somewhere) and tell bac9 about the problem.

@Taverius: Ah, yes, finding my screw ups; I've missed you doing that. The ModuleManager config has been fixed on my end. My reasoning for having the thrust maxed at 0 airspeed was that in that situation the engines would be running at Maximum Static Thrust, and that after take off they should naturally back off to Normal Rated / Maximum Continuous / Maximum Climb Thrust for the rest of the flight. I also know that engines do lose some thrust once they start gaining speed, but I guess that once you get into supersonic flight the numbers can change a lot (I haven't found any numbers for this stuff, really). If you happen to know of a better curve to use, point me towards it and I'll make the change.

I suppose the best way to explain "assembly-based" is to start off with FAR's current "part-centric" modelling. FAR currently attempts to figure out the aerodynamics of each part individually, with some simple changes for wings that are near each other, parts that are connected to each other, and known cargo bays / payload fairings. What this ends up meaning is that the drag of a part isn't affected by where it is in a stack, what's ahead of it / behind it. It also means that wings aren't modeled as one aggregate piece, but as a bunch of arbitrarily-shaped lifting chunks. Calculating induced velocities is almost impossible (so FAR doesn't bother currently) and each part needs to to run its own aerodynamic calculations. This is not only computationally wasteful, but the physics are (technically) wrong, even though they follow general trends and come close to being correct in most cases. In other cases (such as people using structural panels to build stock fairings) FAR simply fails completely.

The "assembly-based" approach is to group the parts into collection of fuselage / nacelle shapes and wings; each of these fuselage and wing assemblies can then be analyzed to figure out the proper aerodynamics (and with probably no more than ~10 assemblies per craft, this means fewer calculations to run) and they can then apply the proper forces to each part. For a fuselage, if you surround an ugly assembly of parts with structural panels to make a fairing, it will act as a fairing under this scheme. If you build a hollow cargo bay, as long as it is closed it should naturally shield the cargo inside from the incoming airflow. Depending on how things go, I should be able to add support for induced velocities, some area ruling and some amount of multithreading, further reducing the computational load. So better performance and better aerodynamics, ideally.

Of course, right now I'm sitting here trying to work out an algorithm to get the cross-sectional area of a group of meshes on a particular plane that intersects some of those meshes.

[NathanKell]

ferram, I am drooling beyond belief at that smorgasbord of update features!

[Taverius]

@tiron: When you have engines in symmetry one will always flame out first - that's just a KSP bug. When bac9 is around I'll get the Unity files for the DSI and double-check the intake vector, in case something screwy is going on there.

@ferram4: They lose net thrust because of ram drag, but all turbine engines (and ramjets etc) produce thrust as a function of airflow, so gross thrust always goes up (quadratically).

Now, as you start moving you do indeed go from 0 ram drag to >0, so to start with net thrust goes down. But gross thrust is always increasing, and given enough speed it will overtake the ram drag.

If the net thrust eventually goes back up above your zero-airspeed value before you overspeed depends on various design parameters but is most strongly affected by the bypass ratio, as that directly affects the thrust/cross section ratio and thus the gross thrust/ram drag ratio:

The best tool to see this is NASA EngineSim. Unfortunately due to govt shutdown the NASA site is not available, so here's a link to my own copy of the downloadable version, if you want to have a play with. Its a java applet and its a little buggy, but it is useful to see general engine performance trends and such.

But, when I was doing a velocity curve for the TJet I used the values I got from the 2 turbojets already present in EngineSim (you can make your own) and came out with:

velocityCurve {
    // Based on Fnet data from NASA EngineSim, curve fitted with MuMech CurveEd
    key = 0    0.56 0      -0.0005
    key = 200  0.52 0      0
    key = 600  0.7  0.0013 0.0013
    key = 900  1    0      0
    key = 1100 0.5  -0.005 -0.005
    key = 1250 0    0      0
}

There's some fudging on the end, obviously, and the final velocities are somewhat arbitrary based on my desire to stick to realism - the fastest pure turbojet was in the MiG-25 and it would overspeed and melt if pushed above mach 3.05 for more than 5 minutes, but that gives you a rough idea.

You can get CurveEd, so you can play with with floatCurves interactively and see a display of the exact formula used by KSP, here. Its an extremely useful little tool r4m0n made for me

So, anyway, while thrust = 1 at speed = 0 is appropriate for the basic jet, its not for the turbojet.

Can't remember where I found the data as it was nearly a year ago, and of course most of it was NASA/NACA images and thus not available atm, but from I found most turbojets (that I could get gross thrust/airspeed curves for) have a takeoff net thrust fraction (of the peak supersonic thrust) in the 0.5-0.6 range, while more modern low-bypass turbofans tend to be in the 0.7-0.8 range.

Higher takeoff thrust, along with fuel efficiency and lower operating temperatures, was one of the main reasons why few things use turbojets right now.

Notable exceptions are when you need to prioritize the compactness of the installation, or the ease of mainteinance, which is why the GE J85 is still widely used - its small, has a lot of thrust for its size, and since its a 40 year old design its extremely reliable.

.........

The assembly-based version sounds very interesting, though I foresee the same problems with the hiccups when parts fall off (and thus you need to recalculate the assemblies) like you have in the raycast experiment.

[a.g.]

It's not the only thing weird with the B9 inlets. The Diverterless Supersonic Intake (the smallish radial one) has a habit of causing me to have flameouts. FAR reports having more than 100% of intakeair requirement. On one of my planes, it would flame out pretty reliably at around 107% of intakeair requirement. It's also throwing Mechjeb off, because the 'Prevent Flameouts' isn't catching it at all, either.

On one of my planes I fixed it by swapping out the DSIs for new instances of the same intake, like it was something intermittent that was tied to that particular instance of them. Now It's recurring on one of my other planes, even after swapping the DSIs out multiple times.

Could it be the resource bug that was causing Kethane to have infinite conversion problems? Basically, it seems that if you request an amount of resource that is within the total amount available, but greater than any of the tanks, it may fail to return any. Kethane fixed its problems by changing to request no more than max of the amounts in all tanks, instead of sum. This issue seems to be worse if the amount in the tanks is uneven, and I noticed earlier that if you have intakes with different amount of air production on a craft, once the flow drops below a certain level, the smaller intakes seem to stop to affect anything.

[ferram4]

@Taverius: Ah, so my mistakes with net thrust are entirely due to looking at turbofans with decent bypass ratios. I'll see if I can model the stock turbojet as some kind of turbojet-ramjet-SCRAMjet hybrid, and I guess the basic jet is close enough as it is. Thanks for the data and the links.

The raycast experiment basically just showed how inefficient raycasting was and how badly wings were modeled with that system. For this system, whenever a chunk of parts separates from the vessel I can simply have the original parent assembly remove those parts from its list, recalculate a geometry of the assembly only in the region that changed (the rest of the geometry staying the same) and create a new assembly for each new chunk of parts. I might have to require it to update the aerodynamic properties very quickly, but I suspect that I can make that run quite fast (at least as fast as it does now in FAR, and most people don't notice it).

[Tiron]

@tiron: When you have engines in symmetry one will always flame out first - that's just a KSP bug. When bac9 is around I'll get the Unity files for the DSI and double-check the intake vector, in case something screwy is going on there.

I know that! Sheesh. But Mechjeb's supposed to keep them from flaming out at all by managing the throttle to prevent it, and when this happens it fails to do so. Normally it's quite good at it.

I think when I put the DSIs back on the Ravenspear they might've gone on at a slightly different angle, so it could be something dumb like that, yeah. They're mounted on a tapered nose on the Ravenspear and that could be masking it. The Valkyrie has them mounted perfectly straight, so far as I can tell anyway.

Edited October 9, 2013 by Tiron

[NathanKell]

A turbo-ramjet is the only thing that makes sense for engine performance like that.

[Senshi]

Thank you for taking a look at the bug. As I said I wouldn't give it a too big priority, as the super-drag only occurs when quicksaving in-atmosphere, which is only possible under rare circumstances anyway.

Are you certain this bug is unique to the B9 parts or is it worth conducting tests with other (stock?) intakes as well? The vessel from the bug report only used several DSI and a single SABRE intake.

[Taverius]

@ferram4: How many months has it been since the last time I asked for a basic heading holder? In any case, I'm asking again

[Frederf]

The UI needs not to spawn unminimized and to save its position. It acts like it's the most important UI element in history. I spend an inordinate amount of clicks having to minimize it every time I load.

[ferram4]

@Taverius: That's a slightly complicated system, mostly because of how I would need to control pitch and roll to make major adjustments for it. I can look into it.

@Frederf: It does save its position and it should spawn minimized if you left it minimized. It only takes one click to minimize it if it's open; the main button above the main window minimizes it all and can be taken care of while the scene is still loading.

[Tiron]

@Frederf: It does save its position and it should spawn minimized if you left it minimized. It only takes one click to minimize it if it's open; the main button above the main window minimizes it all and can be taken care of while the scene is still loading.

@Ferram: It most definitely does not spawn minimized if it was left minimized. Every time I load a craft, the FAR Flight Systems window is open again. Even if it's a Rover. On the Mun. That I just switched away from a bit ago.

It stays closed if you switch between craft that are in range of each other, I'm pretty sure. I think it re-opens if you go through a loading transition though, like using the Map/Tracking Station to go out and switch craft. It DEFINITELY re-opens if it's your first flight after starting the game up again, even if it was a flight in progress.

There's no reason for it to open at all if you're in orbit or on a body with no atmosphere, and in theory it shouldn't be too hard to set it up to check if you're in an atmosphere and stay closed if you're not. Equally, you could set it up so that if you're not in an atmosphere and enter one, it automatically opens; or if you're in an atmosphere and exit it, it automatically closes. (Although you'd probably want a checkbox toggle option for that.)

If you wanted to be a little more fancy about it you could probably have it check to see if your current orbit is going to take you into an atmosphere or not, and base the behavior on that, but I suspect the only way to do that would be to code in the atmospheric limits for each body, so much more of a pain in the butt (especially if the limits change at some point.)

[ferram4]

@Tiron: Ah, okay, I see what's happening now. That should be easy to fix.

[a.g.]

The VAB window is a lot more anoying in this respect - I actually don't mind the in-flight window at all since it's quite small, but the VAB one is a hassle. Before windows started clipping themselves to the screen I used to drag it almost off-screen to hide, instead of using the button, since it at least remembers the position.

[ZobrAA]

The VAB window is a lot more anoying in this respect - I actually don't mind the in-flight window at all since it's quite small, but the VAB one is a hassle. Before windows started clipping themselves to the screen I used to drag it almost off-screen to hide, instead of using the button, since it at least remembers the position.

I totally agree with that!!

[Sparker]

Could you please tell me how the Cd for air intakes is calculated?

I think that I've found a bug with Rockomax Brand 02 adapters. They create huge drag even when installed behind a nosecone.

On the pictures you can see a simple 'plane' with and without that adapter. Note how Cd chages:

[How2FoldSoup]

I've got a question regarding FAR. I'm attempting to make a VTOL but every time I try to 0 my horizontal velocity(Im not looking to get it perfect but just close enough like 10-20 m/s) FAR recognizes this as going to slow and stalls my plane ultimately ending in explosions. Are there any ways of getting around this or is this something I will just have to deal with and just use my vtols as a short landing tool. The takeoff now works flawlessly.

[ferram4]

@a.g: Ok, ok. I'll fix that for the next version.

@Sparker: The drag for intakes is the new FAR drag + the stock dynamic drag for open intakes.

I'll look into the adapter, since making that much drag is qrong, but it should still make quite a bit of drag; it is a very sudden change in diameter, which does produce quite a bit of drag.

@How2FoldSoup: Velocity doesn't have much to do with stalling; it's the angle of attack that matters. If you're going 5 m/s but the wings are at 0 degree angle of attack, they won't be stalled, but if you're going at 70 m/s, but the wings are at 45 degrees angle of attack they will. You want to figure out a way to zero your horizontal velocity without increasing the angle of attack too much; try messing with the angle of the vertical thrusters to see if that helps.

Edited October 11, 2013 by ferram4

[Camacha]

@a.g: I'll look into the adapter, since making that much drag is qrong, but it should still make quite a bit of drag; it is a very sudden change in diameter, which does produce quite a bit of drag.

Even when it is on the back end of a craft? I do not really understand how it changes drag in a big way back there.

[How2FoldSoup]

Awesome!! thank you so much!

I was pitching up to help slow down but I will attempt pitching back down to 0 when I get around 35m/s I did have the thrusters angled but I did not know stalling was with regard to AoA.

Thank you again!

P.s. I love your mod! One of my planes wouldn't fly nicely in stock for whatever reason but after I installed FAR they all fly much better. Thank you for creating such a great mod and answering questions on your free time!

[ferram4]

@Camacha: I meant that the adapter would still produce quite a bit of drag due to the sudden drop in pressure behind it; the fuel tank alone also suffers from this. I mean that the drag shouldn't decrease a huge amount with that part attached. Sorry, I guess I need to be clearer.

[Tiron]

@Camacha: I meant that the adapter would still produce quite a bit of drag due to the sudden drop in pressure behind it; the fuel tank alone also suffers from this. I mean that the drag shouldn't decrease a huge amount with that part attached. Sorry, I guess I need to be clearer.

I've noticed that the drag in the statics is affected by parts which are completely clipped inside other parts: When I added a multiwheels engine to my plane, I discovered that it lowered the cd on the graph and improved the L/D if it was turned end-on rather than side-on, even though it's buried inside the nosecone. My similarly buried Mechjeb, ISA Mapsat GPS, and Vanguard ejection modules all show the same behavior. I turn them all end-on, even though I suspect that in flight they don't actually add any drag.

Could be something similar, where it's calculating the drag like the flat end of the adapter was directly exposed to the airstream?

[Guest]

Does Far take into account the planar shape of rocket fins as contrast to the hunched curvature of airplane wings?