[1.12.x] CorrectCoL - Stock Aerodynamics Design Aid Continued

[Apaseall]

I am not sure if this has been asked about this mod previously but here I go.

At the moment we pick a speed and an altitude. In return we get two very nice graphs. On one graph we see a blue graph ( blue graph - pitch L/D ratio (wet) ) and a blue vertical line ( blue vertical line - level flight AoA (wet) ). The vertical line I believe to represent a balance between L/D such that the craft with that AoA will fly level. In that belief I am using that AoA as a guide, a target to aim for when I change the craft pitch. The thought being I will get vertical acceleration and horizontal acceleration at an optimum ratio, that is to say I am not gaining vertical speed at a high rate at a larger penalty to the horizontal acceleration. I know there are some assumptions with this, but as a guide I think it is not too far off the mark. When we pick a new combination of speed and altitude the graphs are recalculated. This may or may not result in a differing AoA for the vertical blue line.

So here is my request. Some way of representing how AoA (blue vertical line) changed with speed and altitude.

After some thinking, this might be tricky as really it is a surface depicted in three axis. X as speed, Y as altitude and Z as optimal AoA ( the AoA we would see in the first graph as the blue vertical line intersecting the X axis). I though about rate of climb for Y axis but that would depend on altitude.

Perhaps a simple X,Y graph with selected AoA plots. For example say a plot for AoA=5 degrees would show us that we can be at Y=5000m altitude going at X=500m/s speed. In another colour AoA=10 degrees would show us that at speed X=500m/s we would need to be at Y=1000m altitude. The number used in the previous sentence as merely plucked out of thin air for want of need for some numbers to use as an example.

Or maybe X as AoA and Y as altitude with selected speeds, say 200, 500, 1000, 1500. We could then read the graph as for a given altitude Y, using plot for 500m/s we can see an optimal AoA of X.

What I am trying to get is, if I start out with a given pitch value, for a supposedly optimal AoA which might be a good trade of lift for drag, then as my altitude and speed change, what new AoA should I change my pitch to aim for?

I hope I have outlined clearly what it is that I seek. I think I have provided a couple of useful ways of depicting a solution. I believe that the data is already calculated. It would not be of interest to every one, so it could be an option defaulting to off, with its own update request button. Probably not a great idea for any ability to auto update, as the current graphs cause a noticeable delay whilst they are calculated. Might be an idea to give visual completion progress like say processing 0% - 25% etc.

I believe that I would find this useful and it would bring something extra to this mod. However I do understand that it might not be a priority or even within the design concept of this mod.

Worth asking about though I thought.

Edited February 6, 2018 by Apaseall

[linuxgurugamer]

This mod is in a maintenance mode, meaning that I will keep it working, but not going to be enhancing it.

sorry

[Booots]

20 hours ago, Apaseall said:

So here is my request. Some way of representing how AoA (blue vertical line) changed with speed and altitude.

After some thinking, this might be tricky as really it is a surface depicted in three axis. X as speed, Y as altitude and Z as optimal AoA ( the AoA we would see in the first graph as the blue vertical line intersecting the X axis). I though about rate of climb for Y axis but that would depend on altitude.

Perhaps a simple X,Y graph with selected AoA plots. For example say a plot for AoA=5 degrees would show us that we can be at Y=5000m altitude going at X=500m/s speed. In another colour AoA=10 degrees would show us that at speed X=500m/s we would need to be at Y=1000m altitude. The number used in the previous sentence as merely plucked out of thin air for want of need for some numbers to use as an example.

Or maybe X as AoA and Y as altitude with selected speeds, say 200, 500, 1000, 1500. We could then read the graph as for a given altitude Y, using plot for 500m/s we can see an optimal AoA of X.

What I am trying to get is, if I start out with a given pitch value, for a supposedly optimal AoA which might be a good trade of lift for drag, then as my altitude and speed change, what new AoA should I change my pitch to aim for?

I hope I have outlined clearly what it is that I seek. I think I have provided a couple of useful ways of depicting a solution. I believe that the data is already calculated. It would not be of interest to every one, so it could be an option defaulting to off, with its own update request button. Probably not a great idea for any ability to auto update, as the current graphs cause a noticeable delay whilst they are calculated. Might be an idea to give visual completion progress like say processing 0% - 25% etc.

I'm working on a mod right now that calculates the flight envelope of a spaceplane (mostly to assist myself with having enough thrust to get past the Mach drag rise). As a side effect, I'm calculating the required AoA for level flight throughout the flight envelope. So, yes, it's possible to make something do what you're looking for, but I think @linuxgurugamer is right in saying no to adding it to this mod because it's a completely new feature and would reuse hardly any code. 

Another issue that you've correctly identified is the time to calculate it all. Instead of doing a couple dozen angles of attack at a set speed and altitude and then looking at which AoA creates the right amount of lift, you're looking to analyze the whole thing at several hundred altitude and speed points for some tens of thousand data points overall. For testing the mod I'm writing, I'm doing a very coarse graph and it still takes on the order of a minute to analyze a spaceplane's flight envelope. So certainly not auto-updating.

[Apaseall]

On 2/7/2018 at 3:09 PM, linuxgurugamer said:

This mod is in a maintenance mode, meaning that I will keep it working, but not going to be enhancing it.

sorry

That is quite understandable, thank you for the information.

[Apaseall]

On 2/7/2018 at 3:51 PM, Booots said:

I'm working on a mod right now that calculates the flight envelope of a spaceplane (mostly to assist myself with having enough thrust to get past the Mach drag rise). As a side effect, I'm calculating the required AoA for level flight throughout the flight envelope. So, yes, it's possible to make something do what you're looking for, but I think @linuxgurugamer is right in saying no to adding it to this mod because it's a completely new feature and would reuse hardly any code. 

Another issue that you've correctly identified is the time to calculate it all. Instead of doing a couple dozen angles of attack at a set speed and altitude and then looking at which AoA creates the right amount of lift, you're looking to analyze the whole thing at several hundred altitude and speed points for some tens of thousand data points overall. For testing the mod I'm writing, I'm doing a very coarse graph and it still takes on the order of a minute to analyze a spaceplane's flight envelope. So certainly not auto-updating.

Regarding time taken to produce a graph. Between 0-2300m/s and 0-75kM there are a huge number of data points. Clearly the way to tackle producing plots will involve sampling. By that I mean rather than working out AoA vs speed then AoA vs speed +1m/s it would be simpler to workout using speed increments of 500m/s. If those could be thrown into the unity curve thing (like the ones used for engine performance) KSP could spit back a nice curve from a minimal set to calculated points. Failing that merely reduce the sampling increment until a reasonable line can be produced.

One thing that I am curious about is how a AoA is calculated. Is it possible to build a model once? I mean f(x) = ax2 + bx etc. Then simply plug in x. Or is the calculation iterated over all the craft parts every time?

[Boris-Barboris]

4 minutes ago, Apaseall said:

Or is the calculation iterated over all the craft parts every time?

^^

and, btw, level flight AoA is accurate only for statically neutral crafts, for stable crafts it will always be a bit larger.

Edited February 8, 2018 by Boris-Barboris

[Booots]

2 hours ago, Apaseall said:

Regarding time taken to produce a graph. Between 0-2300m/s and 0-75kM there are a huge number of data points. Clearly the way to tackle producing plots will involve sampling. By that I mean rather than working out AoA vs speed then AoA vs speed +1m/s it would be simpler to workout using speed increments of 500m/s. If those could be thrown into the unity curve thing (like the ones used for engine performance) KSP could spit back a nice curve from a minimal set to calculated points. Failing that merely reduce the sampling increment until a reasonable line can be produced.

One thing that I am curious about is how a AoA is calculated. Is it possible to build a model once? I mean f(x) = ax2 + bx etc. Then simply plug in x. Or is the calculation iterated over all the craft parts every time?

Sorry @linuxgurugamer if we're hijacking your thread. We could go elsewhere if you want.

Right, 1m/s is obviously much too fine. I do 30 m/s by 750m steps and still get minute-long calculations for a moderately-sized mk 3 spaceplane. There are optimizations I can do and that I'm working on that might cut that time in half. Still, it's not just a line, but a surface and that means the number of calculations is squared.

One of the major time sinks is calculating AoA. While in the real world, there is an approximately linear relationship between AoA and lift(until you near the stall region), this relationship would only be approximately accurate for a small range of Mach numbers and altitudes before the effect of those variables throws it too far off. I've been using Newton's method of root finding to locate the AoA where lift offsets weight. Unfortunately this means I have to iterate over all of the parts and calculate their lift at each AoA guess until it converges (about 8-10 times per speed/altitude pair).

@Boris-Barboris is right. Any deflection of control surfaces to hold that AoA changes the amount of lift produced and thus the AoA required. Fortunately, this should? be minor and so I've just been assuming no deflection. (I think would be hard to simulate deflections)

[linuxgurugamer]

Anything can be simulated,  but remember  that they use super computers for real plane and rocket design

[Boris-Barboris]

6 hours ago, Booots said:

Fortunately, this should be minor and so I've just been assuming no deflection

Not really, it's completely inadequate for control in my experience. If you're optimizing, you should do everything right.

[Fraktal]

I'm experiencing the following problem.

When I try to attach a nuclear engine to any bi/tri/quadcoupler part in the SPH using symmetry mode, at the point where the ghosted engine would snap to the hardpoints, it instead starts rapidly snapping and unsnapping about 20-30 times a second, dropping the framerate to around 8 FPS and making actually attaching the part an exercise in tedium of clicking at the right split second. This only happens with nuclear engines, only with symmetry on and - which is why I'm posting here - only when the CoL is displayed. If I turn off the CoL indicator, everything's fine.

If I may hazard a guess, could the CoL recalculation possibly be throwing an exception, causing the game to endlessly try recalculating the result until it detects that the engine is no longer in the try-to-attach position? I do remember that while I had Exception Detector on, it displayed this particular mod as particularly exception-happy, throwing several per second every time I started working on something, but threw it away and consequently had no root part but hadn't exited the VAB/SPH yet.

[linuxgurugamer]

17 hours ago, Fraktal said:

I'm experiencing the following problem.

When I try to attach a nuclear engine to any bi/tri/quadcoupler part in the SPH using symmetry mode, at the point where the ghosted engine would snap to the hardpoints, it instead starts rapidly snapping and unsnapping about 20-30 times a second, dropping the framerate to around 8 FPS and making actually attaching the part an exercise in tedium of clicking at the right split second. This only happens with nuclear engines, only with symmetry on and - which is why I'm posting here - only when the CoL is displayed. If I turn off the CoL indicator, everything's fine.

If I may hazard a guess, could the CoL recalculation possibly be throwing an exception, causing the game to endlessly try recalculating the result until it detects that the engine is no longer in the try-to-attach position? I do remember that while I had Exception Detector on, it displayed this particular mod as particularly exception-happy, throwing several per second every time I started working on something, but threw it away and consequently had no root part but hadn't exited the VAB/SPH yet.

Seeing your log file would be helpful, see my sig for info on how to get it

[katateochi]

Wow, another useful mod, restored by @linuxgurugamer, you're awesome dude!

I am getting an issue though which sounds related to @Fraktal's issue to do with nuclear engines; On craft without nuclear engines everything seems ok, on craft with nuke the frame rate drops right down (to like 8-10, from 120).  Lots of calculating drag cube messages ("DragCubeSystem: Rendering procedural drag for nuclearEngine") going past in the debug console. 
The other issue (which happens with any craft) is if you open the GUI the frame rate drops if you mouse over the window (with lots of the wonderfully helpful "NullReferenceException: Object reference not set to an instance of an object" error in the logs).
here's my log file; I was trying several craft out, switching between stock COL and correctCOL marker so it might be a bit long. If you want me to just do a specific test and get the logs for that let me know - https://drive.google.com/open?id=13KS1z7h5HXcxCPEd64ZLyuf7rYohVzZm

Edited June 16, 2018 by katateochi
accidentally posted before finishing writing post

[Nicky21]

I'm not exactly sure what this mod does.

 

I noticed that if i use tweakscale to scale down some wings the COL stays in the same place as before, even though is should definitely be moved. I thought this mod solves that issue. Does it not ?

[JH4C]

22 hours ago, Nicky21 said:

I'm not exactly sure what this mod does.

 

I noticed that if i use tweakscale to scale down some wings the COL stays in the same place as before, even though is should definitely be moved. I thought this mod solves that issue. Does it not ?

Depending on where the wings are positioned, rescaling the wings may change the amount of lift generated but not move the centre of lift. I don't use Tweakscale, but it's possible that you'll need to force an update on the graphing even if it's set to automatic; did you try that?

[Rocket In My Pocket]

On 6/16/2018 at 4:41 PM, katateochi said:

Wow, another useful mod, restored by @linuxgurugamer, you're awesome dude!

I am getting an issue though which sounds related to @Fraktal's issue to do with nuclear engines; On craft without nuclear engines everything seems ok, on craft with nuke the frame rate drops right down (to like 8-10, from 120).  Lots of calculating drag cube messages ("DragCubeSystem: Rendering procedural drag for nuclearEngine") going past in the debug console. 
The other issue (which happens with any craft) is if you open the GUI the frame rate drops if you mouse over the window (with lots of the wonderfully helpful "NullReferenceException: Object reference not set to an instance of an object" error in the logs).
here's my log file; I was trying several craft out, switching between stock COL and correctCOL marker so it might be a bit long. If you want me to just do a specific test and get the logs for that let me know - https://drive.google.com/open?id=13KS1z7h5HXcxCPEd64ZLyuf7rYohVzZm

I've noticed the same issue with the Goliath engine when the COL marker is displayed, when it's off everything is fine FPS wise.

Wasn't sure if CorrectCOL was the culprit but your observation about the Nuke makes me think so.

[Nicky21]

On 9/14/2018 at 8:27 PM, JH4C said:

Depending on where the wings are positioned, rescaling the wings may change the amount of lift generated but not move the centre of lift. I don't use Tweakscale, but it's possible that you'll need to force an update on the graphing even if it's set to automatic; did you try that?

Eventualy i figures it's the way the wings are configured in a certain mod, so teh problem it's not this mod.

[Nicky21]

Yeah, i guess ts the OPT mod that's outdated.

[MaverickSawyer]

Anyone else having issues getting this to activate in the VAB in 1.4.5? It worked before in 1.4.4, and I found it to be much more accurate than the stock CoL marker to check for vehicle stability during atmospheric ascent, or during descent for a lander.

[linuxgurugamer]

21 hours ago, MaverickSawyer said:

Anyone else having issues getting this to activate in the VAB in 1.4.5? It worked before in 1.4.4, and I found it to be much more accurate than the stock CoL marker to check for vehicle stability during atmospheric ascent, or during descent for a lander.

It works, did you install the dependencies?

[MaverickSawyer]

39 minutes ago, linuxgurugamer said:

It works, did you install the dependencies?

I did. And I found out what I did wrong. Currently, the only way to enable that is during the time when you first set up the save. Otherwise, there isn't any way to allow it to work in the VAB, which I swear you used to be able to change that after initializing a save for the first time.

[linuxgurugamer]

19 minutes ago, MaverickSawyer said:

I did. And I found out what I did wrong. Currently, the only way to enable that is during the time when you first set up the save. Otherwise, there isn't any way to allow it to work in the VAB, which I swear you used to be able to change that after initializing a save for the first time.

Sorry, you are incorrect .

It is a standalone mod, doesnt need to be there at the start of the save.

[JH4C]

1 hour ago, MaverickSawyer said:

I did. And I found out what I did wrong. Currently, the only way to enable that is during the time when you first set up the save. Otherwise, there isn't any way to allow it to work in the VAB, which I swear you used to be able to change that after initializing a save for the first time.

Those settings are not only available at save creation, they're always available. To access myriad settings pages for mods, open the pause menu and select Settings, then click the button at the top marked Difficulty Level: {Easy/Normal/Moderate/Hard/Custom}. The button will forever say Custom after this, but you can personalise whatever the heck you want for all kinds of things.

[AeroGav]

On 2/16/2018 at 8:39 PM, Fraktal said:

I'm experiencing the following problem.

When I try to attach a nuclear engine to any bi/tri/quadcoupler part in the SPH using symmetry mode, at the point where the ghosted engine would snap to the hardpoints, it instead starts rapidly snapping and unsnapping about 20-30 times a second, dropping the framerate to around 8 FPS and making actually attaching the part an exercise in tedium of clicking at the right split second. This only happens with nuclear engines, only with symmetry on and - which is why I'm posting here - only when the CoL is displayed. If I turn off the CoL indicator, everything's fine.

If I may hazard a guess, could the CoL recalculation possibly be throwing an exception, causing the game to endlessly try recalculating the result until it detects that the engine is no longer in the try-to-attach position? I do remember that while I had Exception Detector on, it displayed this particular mod as particularly exception-happy, throwing several per second every time I started working on something, but threw it away and consequently had no root part but hadn't exited the VAB/SPH yet.

I encountered this,  I found that if you attach the nuclear engine early in the craft's construction it doesn't happen,  I wondered if it was affected by frame rate in some way, if the colliders don't finish their calculations in time the part fails to attach to the node.  So if i'm building a craft with NERVs i attach the NERV nacelle very early on eg. to the root part,  then move and copy this nacelle later on as needed (eg. if you've mounted the nerv to an engine precooler,  you can alt click and copy or move that part with its attached nerv no issues).   I think i've seen this problem when  after deleting the CorrectCoL folder so it isn't necessarily this mod at fault .

As regards low frame rate,  the frame rate tanks after i open the static stability display for the first time,  I can work around that by checking the checkbox "use stock centre of lift marker" in the top left corner of the static analysis GUI.   The stock CoL marker is good enough for roughly planning the layout of the craft,  i update the static analysis plot when fine tuning.

Edited November 2, 2018 by AeroGav

[DownHereInChile]

Sorry if this has been asked before, but does it work along FAR?

[AVaughan]

24 minutes ago, DownHereInChile said:

Sorry if this has been asked before, but does it work along FAR?

From the first post.

On 5/6/2017 at 2:16 AM, linuxgurugamer said:

Stockalike CoL indicator for stock Aerodynamics, accounts not only for ILiftProviders. Please, don't try it with FAR (mod disables itself if FAR is found).