[1.4.+] Kerbal Wind Tunnel Development Thread

[AeroGav]

 

@Booots   Awesome,  the game really needs something like this.  Sorry for not seeing the thread earlier but i haven't played KSP in a couple months.

Anyway, I decided to see what it made of my last ship,   Andromeda .   In many ways, this is throwing your mod a curveball,  it has two Rapiers and two Panthers, and the wings are angled up with 5 degrees incidence wrt to fuselage.   Part count is quite high (look at all them strakes!) too.

https://kerbalx.com/AeroGav/Andromeda

 

According to the flight envelope it cannot bridge the gap to supersonic flight, though i think you can see the two sweet spot islands of excess thrust thanks to the two engine types..   In fact, if you care to download the craft,  it  goes supersonic at 8km in level flight with 2x as much thrust as drag = and that's without using its nukes.

Lift drag ratio also seems a little off.    The actual value depends on how close to prograde you can keep, since the wings are angled.    However, at mach 6 and 30km+, on nuke power, it holds only about 0.25 degrees above prograde when sas is set to prograde lock (when empty..  payload distribution can effect this).  At that AoA,  I was getting over 3.7 to 1 lift:drag ratio in hypersonic flight.

Also, does the flight envelope take account orbital freefall ?  At the sort of velocities people are going closed cycle, over half the weight is being cancelled out by this, which reduces the amount of lift needed.

With a payload onboard, it doesn't hold prograde as accurately..  but still getting decent hypersonic L/D/

[Booots]

2 hours ago, AeroGav said:

Awesome,  the game really needs something like this.  Sorry for not seeing the thread earlier but i haven't played KSP in a couple months.

Anyway, I decided to see what it made of my last ship,   Andromeda .   In many ways, this is throwing your mod a curveball,  it has two Rapiers and two Panthers, and the wings are angled up with 5 degrees incidence wrt to fuselage.   Part count is quite high (look at all them strakes!) too.

According to the flight envelope it cannot bridge the gap to supersonic flight, though i think you can see the two sweet spot islands of excess thrust thanks to the two engine types..   In fact, if you care to download the craft,  it  goes supersonic at 8km in level flight with 2x as much thrust as drag = and that's without using its nukes.

Lift drag ratio also seems a little off.    The actual value depends on how close to prograde you can keep, since the wings are angled.    However, at mach 6 and 30km+, on nuke power, it holds only about 0.25 degrees above prograde when sas is set to prograde lock (when empty..  payload distribution can effect this).  At that AoA,  I was getting over 3.7 to 1 lift:drag ratio in hypersonic flight.

Also, does the flight envelope take account orbital freefall ?  At the sort of velocities people are going closed cycle, over half the weight is being cancelled out by this, which reduces the amount of lift needed.

With a payload onboard, it doesn't hold prograde as accurately..  but still getting decent hypersonic L/D/

Oh interesting! Thanks for trying this with a complicated spaceplane! I made this to show things like those sweet spot islands. I had a Mk3-based spaceplane that I suspected had a situation like that where I needed rockets to push through but then could turn them off and keep accelerating. I'll have to download your ship and add it to my testing regimen.

I'm surprised it's not accurately predicting your flight envelope, I thought I had all the prediction stuff nailed... Maybe the fact that they're multi-mode is throwing it off. The wind tunnel calculates using whichever mode they're set to start as, are you changing modes before going supersonic? It also only uses the engines in the lowest stage that has engines in it (though I think yo' stagin' is alright for this ).

The lift/drag ratio it's showing is calculated using the actual force results from the simulation, so I'm also baffled why that wouldn't match up. My first instinct is to claim that the native KSP L/D display might not be accurate (normalizing the drag value by something), but I'll do some digging. It might even be resolved by the next point you raised.

And no, orbital freefall isn't accounted for yet (it's on the to-do list). That can be simplified to a vertical force with magnitude m*v^2/(a+R), right? That'll actually help reduce drag because the AoA can drop since the wings don't need to lift the whole vessel. Thanks for reminding me!

[AeroGav]

2 hours ago, Booots said:

I'm surprised it's not accurately predicting your flight envelope, I thought I had all the prediction stuff nailed... Maybe the fact that they're multi-mode is throwing it off. The wind tunnel calculates using whichever mode they're set to start as, are you changing modes before going supersonic? It also only uses the engines in the lowest stage that has engines in it (though I think yo' stagin' is alright for this ).

It is a liquid fuel only cargo ssto.     First stage starts both panther and both rapier together.    Second stage starts the nukes.   The rapiers are only ever used in air breathing mode and the oxidizer tank at the front is empty.   But it can still put a full orange tank in LKO  :-)

I suspect the drag values are far too high - is it getting confused about whether the cargo bay is open or shut ,   or does the wing incidence upset things?

[Booots]

28 minutes ago, AeroGav said:

It is a liquid fuel only cargo ssto.     First stage starts both panther and both rapier together.    Second stage starts the nukes.   The rapiers are only ever used in air breathing mode and the oxidizer tank at the front is empty.   But it can still put a full orange tank in LKO  :-)

I suspect the drag values are far too high - is it getting confused about whether the cargo bay is open or shut ,   or does the wing incidence upset things?

I found it. Your landing gear are extended. If you retract them and click 'update vessel' I think you'll see values more in-line with what you see in flight. So yes, the drag values are far too high because landing gear have high drag when extended.

[AeroGav]

18 minutes ago, Booots said:

I found it. Your landing gear are extended. If you retract them and click 'update vessel' I think you'll see values more in-line with what you see in flight. So yes, the drag values are far too high because landing gear have high drag when extended.

Yes,  that describes things :-)

Kick ass mod, first time i've seen a flight envelope in KSP.   

Do try adding that orbital freefall thing though.    You wrote this mainly to deal with the problem of getting supersonic , at such low speeds its not a factor and in any case,  lift does not have to = weight when crossing mach 1,  you can always go prograde for that bit of the flight even if it sends you arcing into a dive.       During the speedrun,  most of my planes,  Andromeda included , have a bit too much wing,  and especially when empty,  trying to maintain 20km for the speedrun is like trying to hold a polystyrene block underwater.    The graph doesn't really show this.

Once you are done with airbreathing,  i go prograde for best L/D ratio  and the excess lift results in a positive rate of climb.   It starts to run out of lift by 35km, but you're over 2000 m/s at that point which causes the climb rate to start increasing again.

 

[AeroGav]

OFF-TOPIC but someone really needs to come up with a replacement for @Boris-Barboris  's  CorrectCoL mod.

Andromeda has the noob error of insufficient pitch stability, especially when empty I'm ashamed to say.

For me,  we need something that takes account of drag from non-wing parts,  and was also a big fan of the static stability graph.    You could see at what AoA the airplane has neither a pitch up or pitch down moment,  by where the line crossed the X axis.    I was aiming for a very small positive AoA, being the one it would fly at with no hand on the controls.   You can see whether the plane's nose down tendency gets stronger as the node continues to rise, or if it reverses and goes flip happy because the front wing stalls first.

 

I've had to manually correct Andromeda by making countless test flights

1.  move engines forward a bit , move fuel tanks aft a bit so that hopefully CoM doesn't shift when fuel burns off (have as much fuel behind CoM as in front of it)

2. Now make flight after flight , shifting the wings around so it's stable with the new CoM position, then dialling in the right amount of built in angle on the surfaces so it holds a small positive aoa with no input

3. tweak trim flap deployment angles so you get about 5 degrees +- with SAS off and +- 1.5 degrees with it on

I've now got it so the plane flies at +1 AoA  with SAS off and trim neutral, with trim up action group, it's 5 degrees nose up with SAS off and 1.5 with it on,  -5 with nose down set and -1 AOA with nose down set on prograde hold.

Full back stick gives about 15 degree nose up.

That took 2 hours, would have been 5 minutes without test flights if i still had correct CoL.

That's just the testing with full tanks.   To do empty, i need to manually empty all those strakes by the same amount,  or leave the nervs running with parking brake set on the runway for 20 minutes.

I've updated the craft file just now and might do it again if i get time for more ksp next week.

[linuxgurugamer]

19 minutes ago, AeroGav said:

TOPIC but someone really needs to come up with a replacement for @Boris-Barboris  's  CorrectCoL mod.

Whats wrong with the current version of CorrectCoL?

 

[Booots]

On 6/22/2018 at 5:18 PM, linuxgurugamer said:

Whats wrong with the current version of CorrectCoL?

Absolutely nothing! I love CorrectCoL and it was a large part of the inspiration for this. Speaking of CorrectCoL, @linuxgurugamer, how would you feel about merging it into this? If KWT is having CL/CD-alpha curves, why not have moment curves as well and sort of have all the aero predictions in one place? CorrectCoL would then be the lightweight cousin that makes the blue CoL marker be in the right place.

 

On the development side, how is everyone finding the calculation time for the flight envelope? Is the multithreading I'm doing keeping it at an acceptable level across different hardware setups? My dev computer has 6 cores and so it's always been super fast for me - is anyone trying this on a laptop or something lightweight?

And how about the UI? Are the different tab-like things working out? Would anyone be interested in the ability to layer different curves on the line graphs (i.e. have both lift and drag showing at the same time? That would require a bit of reworking things behind the scenes, but could definitely be doable.

[linuxgurugamer]

I was referring to @AeroGav‘s comment.

I dont have time to merge these, but feel free to do so.  I thing it would be a great thing to do

[AeroGav]

2 hours ago, Booots said:

On the development side, how is everyone finding the calculation time for the flight envelope? Is the multithreading I'm doing keeping it at an acceptable level across different hardware setups? My dev computer has 6 cores and so it's always been super fast for me - is anyone trying this on a laptop or something lightweight?

Perfectly acceptable on my Ivy Bridge Desktop I5,   though I've been watching the World Cup on my second monitor and the calculations make that stutter (thread priority?).   Despite which I seem to do a better job spotting fouls than the V.A.R.,  but that's another topic.

@linuxgurugamer very glad to see you're continuing the work,  I thought it was a dead project because Google only brings up the old thread.   You must have fallen out of favor with the Illuminati

 

[linuxgurugamer]

4 minutes ago, AeroGav said:

Perfectly acceptable on my Ivy Bridge Desktop I5,   though I've been watching the World Cup on my second monitor and the calculations make that stutter (thread priority?).   Despite which I seem to do a better job spotting fouls than the V.A.R.,  but that's another topic.

@linuxgurugamer very glad to see you're continuing the work,  I thought it was a dead project because Google only brings up the old thread.   You must have fallen out of favor with the Illuminati

 

If you looked at the thread, you would see it referring to my new thread

[Tahvohck]

On 6/24/2018 at 1:05 PM, Booots said:

On the development side, how is everyone finding the calculation time for the flight envelope? Is the multithreading I'm doing keeping it at an acceptable level across different hardware setups? My dev computer has 6 cores and so it's always been super fast for me - is anyone trying this on a laptop or something lightweight?

And how about the UI? Are the different tab-like things working out? Would anyone be interested in the ability to layer different curves on the line graphs (i.e. have both lift and drag showing at the same time? That would require a bit of reworking things behind the scenes, but could definitely be doable.

Running well on my old i5-4570 with 16GB of RAM, though the ships I've tested it on are pretty simple so far (early in a career save). This is always a dangerous question, but is it possible to offload any of the processing to the GPU? This sort of thing is what GPU architecture excels at, isn't it?

[Booots]

On 6/24/2018 at 12:34 PM, linuxgurugamer said:

I dont have time to merge these, but feel free to do so.  I thing it would be a great thing to do

That's okay. I wasn't going to ask much of you besides your blessing. Thanks!

15 hours ago, Tahvohck said:

Running well on my old i5-4570 with 16GB of RAM, though the ships I've tested it on are pretty simple so far (early in a career save). This is always a dangerous question, but is it possible to offload any of the processing to the GPU? This sort of thing is what GPU architecture excels at, isn't it?

I don't think so. Keep in mind that this isn't doing real CFD or anything. People use GPUs for hard-core CFD because they're good at solving linear algebra like finite methods use. This mod isn't doing any of that because KSP doesn't do that. This mod is just running KSP's native lift and drag functions a bunch of times which amounts to evaluating baked curves and combining the results.

[Mathrilord]

J-404 turbojet isn't support by the mod.

[Booots]

On 7/9/2018 at 12:02 PM, Mathrilord said:

J-404 turbojet isn't support by the mod.

Isn't it?  Can you provide a bit more detail? Does it cause it to crash or something?

[Booots]

I've put out a new pre-release on GitHub: 0.9a. As you can guess from the numbering, I'm getting really close to a proper release. There's just a few to-do items left - icons being the main one. If anyone wants to offer their services, I'd be most grateful. (@Rodger, any chance I could rope you into doing another icon for me?)

Wish list items like calculating best periapsis and fuel burn along the best-time-to-climb profile will be post 1.0.

[Booots]

In case anyone is unaware, I've put out a full release over in this thread:

@neistridlar, since you've proven yourself as an assumption-checker can I verify one more thing with you?

People have asked for a readout of fuel needed to climb-accelerate as well as the "best profile". I'm interpreting best as best time and/or least fuel burn.

Am I correct in believing that the best time-to-climb/accelerate is the path of maximum excess thrust from zero/zero up and to the right?

The best fuel-burn-to-climb/accelerate, then, would it be the same? I'm thinking not. Is it the path of best L/D up and to the right? Is there any proof the two paths will converge at the top right-hand corner of the envelope?

Edited August 5, 2018 by Booots

[Apaseall]

Here is a log: https://www.dropbox.com/s/ag6nf7tb54iizzk/saves for WindTunnel.2.output_log.rar?dl=0

Inside of which I see this:

Spoiler

ADDON BINDER: Cannot resolve assembly: System.ComponentModel.DataAnnotations, Culture=neutral, PublicKeyToken=31bf3856ad364e35
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

ADDON BINDER: Cannot resolve assembly: System.ComponentModel.DataAnnotations, Culture=neutral, PublicKeyToken=31bf3856ad364e35
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

AssemblyLoader: Exception loading 'Accord': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded.
  at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool)
  at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0
  at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0

Additional information about this exception:

 System.IO.FileNotFoundException: Could not load file or assembly 'System.ComponentModel.DataAnnotations, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies.
File name: 'System.ComponentModel.DataAnnotations, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'

 System.TypeLoadException: Could not load type 'Accord.RealAttribute' from assembly 'Accord, Version=3.8.0.0, Culture=neutral, PublicKeyToken=fa1a88e29555ccf7'.

 System.TypeLoadException: Could not load type 'Accord.RealAttribute' from assembly 'Accord, Version=3.8.0.0, Culture=neutral, PublicKeyToken=fa1a88e29555ccf7'.

 System.IO.FileNotFoundException: Could not load file or assembly 'System.ComponentModel.DataAnnotations, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies.
File name: 'System.ComponentModel.DataAnnotations, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'

 System.TypeLoadException: Could not load type 'Accord.RealAttribute' from assembly 'Accord, Version=3.8.0.0, Culture=neutral, PublicKeyToken=fa1a88e29555ccf7'.

 System.IO.FileNotFoundException: Could not load file or assembly 'System.ComponentModel.DataAnnotations, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies.
File name: 'System.ComponentModel.DataAnnotations, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'

 System.IO.FileNotFoundException: Could not load file or assembly 'System.ComponentModel.DataAnnotations, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies.
File name: 'System.ComponentModel.DataAnnotations, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'

 System.TypeLoadException: Could not load type 'Accord.IntegerAttribute' from assembly 'Accord, Version=3.8.0.0, Culture=neutral, PublicKeyToken=fa1a88e29555ccf7'.

 System.TypeLoadException: Could not load type 'Accord.IntegerAttribute' from assembly 'Accord, Version=3.8.0.0, Culture=neutral, PublicKeyToken=fa1a88e29555ccf7'.

 System.TypeLoadException: Could not load type 'Accord.IntegerAttribute' from assembly 'Accord, Version=3.8.0.0, Culture=neutral, PublicKeyToken=fa1a88e29555ccf7'.

 System.TypeLoadException: Could not load type 'Accord.IntegerAttribute' from assembly 'Accord, Version=3.8.0.0, Culture=neutral, PublicKeyToken=fa1a88e29555ccf7'.
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

 

Now I am unsure if this is fatal but I am surprised to see this. I am having CTD's but I am not all sure the above is in anyway related. However as we know, KSP is not very fault tolerant and I wonder if you might be able to look into this to resolve what appears to be some sort of naming issue.

 

Now on a more serious note, same log file but later on:

Spoiler

[ModuleManager] Post run call threw an exception in loading Accord, Version=3.8.0.0, Culture=neutral, PublicKeyToken=fa1a88e29555ccf7
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

ReflectionTypeLoadException: The classes in the module cannot be loaded.
  at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool)
  at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0
  at ModuleManager.MMPatchLoader+<ProcessPatch>d__33.MoveNext () [0x00000] in <filename unknown>:0
UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object)
UnityEngine.DebugLogHandler:LogException(Exception, Object)
UnityEngine.Logger:LogException(Exception)
ModuleManager.Logging.UnityLogger:Exception(String, Exception)
ModuleManager.Logging.ModLogger:Exception(String, Exception)
ModuleManager.<ProcessPatch>d__33:MoveNext()
UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr)

I take it that Accord is part of this mod?

Oh and this:

Spoiler

[MechJeb2] Starting the Dispatcher
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51)

MechJeb moduleRegistry creation threw an exception in LoadComputerModules loading Accord, Version=3.8.0.0, Culture=neutral, PublicKeyToken=fa1a88e29555ccf7: System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded.
  at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool)
  at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0
  at MuMech.MechJebCore.LoadComputerModules () [0x00000] in <filename unknown>:0

 

Edited September 19, 2018 by Apaseall

[Booots]

The newest release has near-optimal ascent path calculating. I'm still not convinced my math is right, so anyone that is so inclined should feel free to check it. Thanks!