[1.12.3] Kerbal Wind Tunnel 1.3.1.1

[Booots]

I present to you fine spaceplane enthusiasts... the Kerbal Wind Tunnel mod!

We all build spaceplanes to fly faster and higher, but how do you know how fast or how high your current design can go?

In the real world of aircraft design, engineers calculate the flight envelope for their aircraft before the first test flight rolls out.

This mod runs your spaceplane through a virtual wind tunnel while still in the SPH and predicts its engine and flight performance at every speed and altitude.

It also gives you a readout of various performance curves, plotting against angle of attack:

... and velocity:

Try it out and start building even better spaceplanes today!

You can even output the data to a CSV file to incorporate knowledge of the performance data into a KOS script or the like!

Check out this Imgur album for more details on these images and more:

Album a/aEUYR6Z will appear when post is submitted

https://imgur.com/a/D2i4Fge

Album a/D2i4Fge will appear when post is submitted

Download it from GitHub: https://github.com/DBooots/KerbalWindTunnel/releases

Or SpaceDock: https://spacedock.info/mod/1927/Kerbal Wind Tunnel

Source: https://github.com/DBooots/KerbalWindTunnel

Released under the MIT License (with sub-components under their own license).

 

P.S. This mod incorporates a pretty sweet graph-drawing library I made. If anyone's interested in super-simple graphing of data, hit me up.

Edited April 23, 2022 by Booots

[Booots]

Because I forgot my schooling and didn't label the axes yet, here they are:

On the flight envelope graphs, the horizontal axis is speed [m/s] and the vertical axis is altitude [m]. The color axis reflects the variable being plotted. Hover your mouse over the graph to get the units.

On the AoA graphs, the horizontal axis is angle of attack [degrees] and the vertical axis is the option selected below the graph. Mouseover the graph and it will tell you the units.

On the Velocity graphs, the horizontal axis is speed [m/s] and, again, the vertical axis is the option selected below the graph. Mousing over the graph will again show you the units.

Edited August 4, 2018 by Booots
Pinning axis descriptions

[Daniel Prates]

Gigantic thumbs up!

[DStaal]

Nice!

One request, as someone who can't build spaceplanes and might use this to learn - could you label your axis in the graphs?  I'm sure they're the standard axis - but I have no idea what the standard axis are for these types of graphs.

[Daniel Prates]

26 minutes ago, DStaal said:

Nice!

One request, as someone who can't build spaceplanes and might use this to learn - could you label your axis in the graphs?  I'm sure they're the standard axis - but I have no idea what the standard axis are for these types of graphs.

I was going to say the same thing. I am checking the lift and drag forces,  but I cant tell what are the factors in the XY graph!

Also:  cant there be a button or place in the GUI where you can gauge the absolute stall speed at sea level?

Edited August 4, 2018 by Daniel Prates

[neistridlar]

Awesome work! Very useful for saving time in exploring the flight envelope, and also in discovering some interesting traits like this one: 

Apparently my airliner can make it to mach 1.5, but only by entering at 4,3km altitude, and at mach 1, followed by a shallow climb to 7km. How on earth would one discover that without a tool like this?

I have a suggestion though. Not everyone cares about spaceplanes. Sometimes it is fun to just fly about on kerbin at subsonic speeds and medium altitudes. So, it would be very nice if it was possible to change the range on each axis. Maybe there could even be some kind of auto fit for the axis?

[Jesusthebird]

26 minutes ago, neistridlar said:

Awesome work! Very useful for saving time in exploring the flight envelope, and also in discovering some interesting traits like this one: 

Apparently my airliner can make it to mach 1.5, but only by entering at 4,3km altitude, and at mach 1, followed by a shallow climb to 7km. How on earth would one discover that without a tool like this?

I have a suggestion though. Not everyone cares about spaceplanes. Sometimes it is fun to just fly about on kerbin at subsonic speeds and medium altitudes. So, it would be very nice if it was possible to change the range on each axis. Maybe there could even be some kind of auto fit for the axis?

This is something ive been praying for for a long time, thinking FAR would evolve in such a way given their own kind of graphing. But Ima have so much fun with this! That 'anomaly' is the kind of stuff i crave. 

 

I agree axis labeling would be good. Im not super smart 

[Booots]

2 hours ago, DStaal said:

Nice!

One request, as someone who can't build spaceplanes and might use this to learn - could you label your axis in the graphs?  I'm sure they're the standard axis - but I have no idea what the standard axis are for these types of graphs.

Oh yes! My bad. My old professors would be so disappointed with me. Adding axis labels somehow fell off my to-do list. The tricky part for that will be figuring out how to rotate the vertical axis label. I'm going to the lake for the weekend, but I'll do that when I get back.

For now, I'll list the axes here.

On the flight envelope graphs, the horizontal axis is speed [m/s] and the vertical axis is altitude [m]. The color axis reflects the variable being plotted. Hover your mouse over the graph to get the units.

On the AoA graphs, the horizontal axis is angle of attack [degrees] and the vertical axis is the option selected below the graph. Mouseover the graph and it will tell you the units.

On the Velocity graphs, the horizontal axis is speed [m/s] and, again, the vertical axis is the option selected below the graph. Mousing over the graph will again show you the units.

Thanks for the feedback!

1 hour ago, neistridlar said:

Awesome work! Very useful for saving time in exploring the flight envelope, and also in discovering some interesting traits like this one:

Apparently my airliner can make it to mach 1.5, but only by entering at 4,3km altitude, and at mach 1, followed by a shallow climb to 7km. How on earth would one discover that without a tool like this?

I have a suggestion though. Not everyone cares about spaceplanes. Sometimes it is fun to just fly about on kerbin at subsonic speeds and medium altitudes. So, it would be very nice if it was possible to change the range on each axis. Maybe there could even be some kind of auto fit for the axis?

That's why I made this mod - I had a spaceplane that should have been able to go fast enough but only rarely did I happen upon the flight profile to make that happen. I needed to see what altitude/speed profile I had to fly to get supersonic. In future versions, I'll be able to have it draw the line of maximum excess thrust to show the most efficient climb-acceleration profile to fly to minimize fuel use (and calculate how much fuel is needed).

Oh yeah, and auto-adjusting axes are in the works. The challenge is having the program efficiently find upper bounds on the fly. Same with the AoA charts where only the middle is viable flight.

1 hour ago, Jesusthebird said:

This is something ive been praying for for a long time, thinking FAR would evolve in such a way given their own kind of graphing. But Ima have so much fun with this! That 'anomaly' is the kind of stuff i crave.

Speaking of FAR... It's not currently compatible, but I would like to add that. The challenge is multithreading the FAR calculations. I scratched together enough open-source info on the stock aero stuff to make a threadsafe aero calculator, but FAR's methods are not threadsafe. So I could add it now, but it would take a few minutes to generate a flight envelope (instead of a few seconds). I'm hoping to work with the FAR devs to find a way forward.

[Daniel Prates]

I'll go ahead and ask: @Booots what would be the easiest way to check the stall speed at sea level? I tried to take the Kn generated by lift, compare it to the airplane's takeoff weight, and see in what speed in the graph they cross... but I am not sure I am understanding exactly how to use the GUI. Could you explain a little better? 

[Booots]

On 8/4/2018 at 12:01 PM, Daniel Prates said:

I'll go ahead and ask: @Booots what would be the easiest way to check the stall speed at sea level? I tried to take the Kn generated by lift, compare it to the airplane's takeoff weight, and see in what speed in the graph they cross... but I am not sure I am understanding exactly how to use the GUI. Could you explain a little better? 

Good call! Your way will get you the number you're looking for, but is a bit trickier than the way I would do it. If I were you, I'd pull that from the flight envelope page, like this:

The colored region represents the conditions where your aircraft can maintain steady level flight. The horizontal axis is speed and the vertical axis is altitude.

The white line shows your stall speed - the slowest you can fly without falling out of the sky.

The black line shows your maximum speed - the fastest your engines can push you.

The green line shows your maximum excess power speed - the conditions where your engines have the strongest advantage over drag, allowing you to use that excess power to climb or accelerate.

So, the red arrow points out your stall speed at sea level - the speed you need to get up to before you can take off.

Edited August 6, 2018 by Booots

[vossiewulf]

This is extremely cool and the graph is very nice, but it's hard to pull exact speeds from it - any chance a table could be added to the side that shows stall, best cruise, and maximum speeds in numeric values at SL/5k/10k/15k etc.? Or maybe make that a separate chart button to go along with the 6 you already have.

 

[Daniel Prates]

Allright! Thanks @Booots. Its this kind of mod that makes ksp really shine!

[Booots]

Updated to version 1.0.1! This version adds axis labels and auto-adjusting axes. Thanks for the feedback everyone!

Download links at the top will get you the new version.

[neistridlar]

So I have been playing around with this tool quite a bit now, trying to use it for finding the optimum cruising conditions for my airliners. In doing so I have found it to be both useful, and not quite accurate. In the bellow pictures I have marked the location on the graph where the aircraft cruises. Note how it is outside the excess thrust line. Also, both aircraft cruises at AoA of >0.15 degrees. Both aircraft use Airplane plus parts, but I don't think that should be an issue. I've also found the pitch input/AoA graph to be inaccurate.

\

And a question on how to use this. What is the significance of the Lift Slope graph? Also, I am mostly interesting in maximizing fuel economy, that is, minimizing fuel used per distance traveled. Is there currently a clever way to read these graphs to find that point? In general I have found that the best thing is to go for max speed first, then choose the altitude which maximizes L/D, but that is not always correct, especially when max speed is close to mach 1. I think maybe a Velocity*Lift/Drag would be more useful for finding optimum fuel economy.

Now off to find all the bugs in the new release .

 

[Booots]

6 hours ago, neistridlar said:

So I have been playing around with this tool quite a bit now, trying to use it for finding the optimum cruising conditions for my airliners. In doing so I have found it to be both useful, and not quite accurate. In the bellow pictures I have marked the location on the graph where the aircraft cruises. Note how it is outside the excess thrust line. Also, both aircraft cruises at AoA of >0.15 degrees. Both aircraft use Airplane plus parts, but I don't think that should be an issue. I've also found the pitch input/AoA graph to be inaccurate.

And a question on how to use this. What is the significance of the Lift Slope graph? Also, I am mostly interesting in maximizing fuel economy, that is, minimizing fuel used per distance traveled. Is there currently a clever way to read these graphs to find that point? In general I have found that the best thing is to go for max speed first, then choose the altitude which maximizes L/D, but that is not always correct, especially when max speed is close to mach 1. I think maybe a Velocity*Lift/Drag would be more useful for finding optimum fuel economy.

Now off to find all the bugs in the new release .

Alright, time to acknowledge the limitations of this mod. There are some assumptions that my model has to make in order to calculate the flight envelope in a reasonable time (it is crunching over 400 data points during which it has to solve for the AoA that'll offset the weight of the vessel, after all).

• Assumes no control deflection (the AoA graphs do, but the flight envelope doesn't).
• Assumes no structural deformation (if your wings fold upwards any, this won't model that).
• Assumes the landing gear don't rotate (what I mean is, I activate the retracted drag cube but if the drag cubes rotate somehow in the retraction, this won't quite catch that. The safest bet is to retract them yourself if you want a possibly-more-accurate simulation.).
• Assumes no thrust gimballing.
• Assumes no torque provided by RCS or reaction wheels.
• Graphs assume linear interpolation between data points.

What this means is that the level flight AoA and/or drag force may vary slightly from what is predicted based on the actual control surface deflection and wing positioning. The pictures you posted look pretty close (within a few pixels) which could be within the the simulation error or graphing error.

The pitch input graph, on the other hand could very well be inaccurate. I'm not very happy with my method of predicting control surface force (I'm basically trying to recreate stock methods as best I can with what's in the API description and may be wrong).

To answer your last two questions, the lift slope graph isn't a terribly important design chart, but does offer some insight. It shows the change of (Lift Force)/(Dynamic Pressure) with angle of attack. As for best fuel efficiency, I think that, based on the way KSP engines work, your best conditions for fuel efficiency are where you have maximum excess thrust so you can throttle down the furthest. Does that make sense? I thought wrong. Best endurance is at max L/D (within the flight envelope) and best range is best V*L/D, which is not currently plotted or calculated anywhere in this mod yet.

Edited August 5, 2018 by Booots

[Booots]

21 hours ago, vossiewulf said:

This is extremely cool and the graph is very nice, but it's hard to pull exact speeds from it - any chance a table could be added to the side that shows stall, best cruise, and maximum speeds in numeric values at SL/5k/10k/15k etc.? Or maybe make that a separate chart button to go along with the 6 you already have.

I don't know how well a table would fit in the UI. What about adding a new set of graphs plotted against altitude? Then we could plot various speeds for that altitude.The other challenge is that there can be more than one stall and max speed or local maxima of best cruise (like in the picture @neistridlar posted). I could easily take the lowest stall and fastest max, but which local maxima of best cruise should I use?

Edited August 5, 2018 by Booots

[neistridlar]

Thanks. So, about the two craft that I posted, both have close to 0 control deflection, and the big one at least does not use reactions wheels, gimbals or RCS. Structural deformation will of course be there, but I would think that would be fairly insignificant in this case. Probably just errors due to linear interpolation then. Good to know the assumptions though.

5 minutes ago, Booots said:

As for best fuel efficiency, I think that, based on the way KSP engines work, your best conditions for fuel efficiency are where you have maximum excess thrust so you can throttle down the furthest. Does that make sense?

I'm pretty sure this is entirely wrong, just based on my experience so far. The thing is engine throttle =/= fuel burn rate, you need to factor in the thrust curves as well (AFAIK. fuel burn rate in KSP as of the current version is proportional to the actual thrust that they are providing.). Also, going faster with the same fuel burn rate is more efficient. In general I have found that going mach 0.7-0.8 for subsonic (altitude does not seem to be important), or as fast and high as possible for supersonic. And for the subsonic case, designing the aircraft to have just enough thrust to reach optimum cruising speed is the best, simply because it is going to have less drag and weight.

[Booots]

12 minutes ago, neistridlar said:

I'm pretty sure this is entirely wrong, just based on my experience so far. The thing is engine throttle =/= fuel burn rate, you need to factor in the thrust curves as well (AFAIK. fuel burn rate in KSP as of the current version is proportional to the actual thrust that they are providing.). Also, going faster with the same fuel burn rate is more efficient. In general I have found that going mach 0.7-0.8 for subsonic (altitude does not seem to be important), or as fast and high as possible for supersonic. And for the subsonic case, designing the aircraft to have just enough thrust to reach optimum cruising speed is the best, simply because it is going to have less drag and weight.

Oh you're totally right. Fuel burn rate is proportional to actual thrust (not excess thrust like I was thinking). I'm going to edit my post so I don't lead others astray (but let the record show I was incorrect and @neistridlar was right). Since fuel burn rate is proportional to actual thrust, and actual thrust = drag for Steady, Level Flight (SLF), your least fuel burn rate is a point of max L/D (within the flight envelope, of course). But fuel burn rate only determines your endurance, not range. You're entirely correct that the point of max V*L/D is your best range and is something not currently plotted. I think I may drop the lift slope envelope chart and replace it with a fuel economy chart (in kg/km, since the thrust available chart is already proportional to fuel burn rate in kg/hr).

[neistridlar]

22 minutes ago, Booots said:

Oh you're totally right. Fuel burn rate is proportional to actual thrust (not excess thrust like I was thinking). I'm going to edit my post so I don't lead others astray (but let the record show I was incorrect and @neistridlar was right). Since fuel burn rate is proportional to actual thrust, and actual thrust = drag for Steady, Level Flight (SLF), your least fuel burn rate is a point of max L/D (within the flight envelope, of course). But fuel burn rate only determines your endurance, not range. You're entirely correct that the point of max V*L/D is your best range and is something not currently plotted. I think I may drop the lift slope envelope chart and replace it with a fuel economy chart (in kg/km, since the thrust available chart is already proportional to fuel burn rate in kg/hr).

Great! So, I did test at max excess thrust, and fuel burn rate was slightly lower, but fuel economy was more than 3 times worse, since it was going way slower. Also, I have been doing a lot of thinking, what would actually be the best indicator of fuel economy. V*L/D is good, but it fails to consider that a design might increase in weight to increase V*L/D, so V*L/D is not actually telling the whole story either. Really fuel burned/distance traveled is the most useful value.

Also, an other suggestion: allow plotting an arbitrary curve, the same way you plot the excess thrust = 0 curve. So, for instance I might be interested in plotting AoA = 0 degrees, since that tends to offer the lowest drag, assuming you are using positive angle of incidence on your wings. And by playing around with its value, it can probably help figuring out the "corridor of max excess thrust" as well, to find the optimum ascent profile. I'm sure there are other use cases as well.

And, I just had a bit of an epiphany. Don't know if your code will allow this, of course, but say you could set both the start and end point for each of the axis manually. Then redo the calculations for only that specific area, that should enable more accurate results of the areas of interest, since your calculation points can now be closer together.

[Rocket In My Pocket]

Just wanted to add that I loaded it up in 1.4.5 and it seems to work fine for all intents and purposes.

Didn't test it exhaustively or anything but, everything seemed to work on the few planes I checked out.

Great mod btw, will definitely be using it from now on!

[vossiewulf]

4 hours ago, Booots said:

I don't know how well a table would fit in the UI. What about adding a new set of graphs plotted against altitude? Then we could plot various speeds for that altitude.The other challenge is that there can be more than one stall and max speed or local maxima of best cruise (like in the picture @neistridlar posted). I could easily take the lowest stall and fastest max, but which local maxima of best cruise should I use?

The graph sounds like a good idea. I at one time spent lots of time in the NASM archives and Wright Patt archives researching flight performance of various military aircraft, and the standard was to break the envelope chart into pieces with charts for top speed vs. altitude, roll rate vs. speed (most were fighter aircraft where this is quite important) and rate of climb vs. altitude. Stall speed is consistent in IAS and they'd provide clean/landing configuration stall speeds.

Is it not possible to take the best of the two cruise maxima, or are you saying that sometimes they're equivalent?

Edited August 5, 2018 by vossiewulf

[Booots]

5 hours ago, neistridlar said:

Also, an other suggestion: allow plotting an arbitrary curve, the same way you plot the excess thrust = 0 curve. So, for instance I might be interested in plotting AoA = 0 degrees, since that tends to offer the lowest drag, assuming you are using positive angle of incidence on your wings. And by playing around with its value, it can probably help figuring out the "corridor of max excess thrust" as well, to find the optimum ascent profile. I'm sure there are other use cases as well.

And, I just had a bit of an epiphany. Don't know if your code will allow this, of course, but say you could set both the start and end point for each of the axis manually. Then redo the calculations for only that specific area, that should enable more accurate results of the areas of interest, since your calculation points can now be closer together.

Other people have suggested plotting an arbitrary curve or an arbitrary set of variables too, but I'm hesitant to add that feature because I feel like it would be overly difficult to code in a text-to-math parser. My graphing library and linq extensions could easily handle extracting and plotting any function but the challenge is interpreting what the user wants. I'm not sure how to a) integrate that into the UI, and b) have a robust math interpreter. For now, I think that arbitrary plots will have to stay on the wishlist. For super-users like yourself, I might recommend using the export-to-csv button and using Excel or Matlab to play with the data.

My code will definitely allow for resetting the range for the axes and recomputing for higher fidelity. Again, the hard part is fitting it into the UI. In case it's not already apparent, my background is in engineering, physics, and back-end programming. The hardest part of this mod was coding in all the buttons and labels. 

What I might do is have it put out a regular-detail graph first, and then work in the background on a higher-detail one (based on the bounds of the first-round data) and update the visible one once it finishes.

2 hours ago, vossiewulf said:

The graph sounds like a good idea. I at one time spent lots of time in the NASM archives and Wright Patt archives researching flight performance of various military aircraft, and the standard was to break the envelope chart into pieces with charts for top speed vs. altitude, roll rate vs. speed (most were fighter aircraft where this is quite important) and rate of climb vs. altitude. Stall speed is consistent in IAS and they'd provide clean/landing configuration stall speeds.

Is it not possible to take the best of the two cruise maxima, or are you saying that sometimes they're equivalent?

Oh hey! That sounds super cool! I think I will go the route of adding a few *-vs-altitude graphs. That'll take me a little while to do, so don't expect as fast a turnaround as we got for the axis labels and auto-axes. One challenge is that all the good altitude graphs are gonna be minima and maxima which is hard for the code to solve efficiently. Instead of the quick functions of the AoA and velocity graphs, the altitude graphs will probably have to just pull slices from the envelope, but that comes with the drawback of fidelity (ie. it's easy to pull the local max from the envelope data matrix, but you can't say if that local max is truly the local max or just the nearest data point to the real local max). Or I'd have to implement a minimization algorithm, but that comes with the drawback of being computationally expensive.

For the cruise maxima, you're right that I could take the better of the two, but that could cause a discontinuity in the line, which my graphing code will interpolate between, potentially causing weirdness.

[Daniel Prates]

@Booots does your mod recognize lifting parts from other mods, such as airplane plus, stryker, procedural wings, sxt etc? Or does it only work with stock parts? I am getting some weird results when using parts from these mods. Mostly, the envelope is shown in the GUI allright, but there are no 'blank' areas around the envelope! Instead, the envelope is surrounded all over by a dark blue color, and in many places it's impossible to say where the 'surrounding blue' ends and the actual envelope graphic starts. 

[Johould]

Very useful. The envelope view helped me greatly improve a design that turned out to just need some tiny adjustments to wing pitch.

Something is definitely a bit strange with the pitch input graph - the AoA stable with zero input changed after adjusting only the authority limiter slider on the only pair of control surfaces active for pitch. (this was at the upper-right of the flight envelope, where pitch had gone unstable and the pitch input graph was a sawtooth, something like 0.4 up to say just below 0 AoA, large input down to say just above 0 AoA).

For the ranges on the flight envelope graph, it would be nice to have the option to focus on a small area without increasing detail, for faster updates when trying to fine-tune a part. Computing the whole graph only takes a second or two, which is usually pretty nice, but adds up when trying tenth of a degree changes.

Allowing a higher maximum speed would be useful to see more of performance with rockets on, and also to see the full air-breathing performance range of some mod parts like Mk2 Expansion's scramjet. I accidentally left the rockets enabled on one spaceplane before checking the flight envelope, and there was actually a relatively narrow corridor of altitudes with excess thrust as the speed went up to 2000m/s. Designs with nukes might need attention to aerodynamics for an especially long time after rockets are on.

I'm not really sure how to use the lift and drag highlighting to improve a design. It seems like the most drag usually comes from the lifting surfaces, making it a bit hard to tell if a change is good from looking at the modes separately. Maybe a few more modes could usefully combine the information? Lift/Drag would probably be good for adjusting wings, some other formula could probably help pick out disproportionately draggy parts (drag/lift wouldn't help with lift-free parts. Maybe a straight offset to drag like subtracting lift divided by the airplane's overall L/D ratio).

[Speedbird52]

I was just thinking about something like this a few days ago!