Optimal engine charts for 1.0.2

[mueslo]

I was wondering if it would be useful for the sake of comparison to include some electricity-generating mass in the calculations for the Dawn.

If the numbers in the Wiki are accurate, the best mass efficiency to power a single Dawn at Kerbin would require 105 kg of solar panels (OXSTAT-4L's or OXSTAT-4W's). This is significant, considering that the Dawn only masses 250 kg.

Happy landings!

Did you happen to limit the maximum number of engines? I'm getting rather different results for example for the TWR >= 1 example

compared to yours:

Yours is usually how my plots look when I limit the maximum number of engines.

Edit: ah, just looked through your physics part, it seems you are respecting that the fuel tanks have mass. I'm not.

Edited May 29, 2015 by mueslo
revelation

[Meithan]

After trying the app can I ask for the engines in the legend that appears next to the chart to have the "LTV-30" part of the name as well as the nickname please?

I have no idea what a rhino or a terrier is. I barely know a swivel and I use it daily. If the name could follow the format of the engine selector that would be great eg : LV-909 "Terrier". It's good to have the legacy names as an option but I don't know them very well either.

Sure thing, I'm just worried about fitting some of the longer names. Let me try to squeeze things together.

Radial engines tend to be a bit worse than the in-line ones, this is compensated in that its easy to add more of them and that the rear of the rocket is free for other uses,

Makes sense. But I wonder why is the atmospheric performance so different?

I was wondering if it would be useful for the sake of comparison to include some electricity-generating mass in the calculations for the Dawn.

If the numbers in the Wiki are accurate, the best mass efficiency to power a single Dawn at Kerbin would require 105 kg of solar panels (OXSTAT-4L's or OXSTAT-4W's). This is significant, considering that the Dawn only masses 250 kg.

Happy landings!

One of the charts in the OP did include the Dawn engine with the weight of panels included (I simply added 100 kg; it's the one named ION-SPs). Back then I decided not the include the Dawn in the analysis because the electrical demand issue is complex enough (there are now three ways to deal with it: panels, RTG, fuel cells) that it deserves its own separate analysis. However, I can add this solar-panels-at-Kerbin version of the Dawn for now.

- - - Updated - - -

Did you happen to limit the maximum number of engines? I'm getting rather different results for example for the TWR >= 1 example

Yours is usually how my plots look when I limit the maximum number of engines.

Edit: ah, just looked through your physics part, it seems you are respecting that the fuel tanks have mass. I'm not.

Yes, the original charts limit the number of engines to 50 (in the webapp I'm developing, the limits is configurable). And yes, I'm considering the dry mass of the tanks in the calculations. This imposes another restriction on the maximum ÃŽâ€v of a ship (the first one being the TWR of the engines, if a TWR restriction is imposed on the ship).

[cephalo]

I'm a little confused by the atmospheric chart. This tells me that if I want a rocket with 3000 dv, at 5 tons I want the LVT-30, for 8 tons I want the skipper, but then for 10 tons I want to go back to the LVT-30? If this chart is made by a function, how is this possible?

EDIT: said LV909 instead of LVT30

[Red Iron Crown]

I'm a little confused by the atmospheric chart. This tells me that if I want a rocket with 3000 dv, at 5 tons I want the LV-909, for 8 tons I want the skipper, but then for 10 tons I want to go back to the LV-909? If this chart is made by a function, how is this possible?

Because it's a discrete function, you can only add Skippers in 3 ton increments. At 8 tons the Skipper is a good deal, at 10 tons one is not enough but two is too many.

[Starhawk]

One of the charts in the OP did include the Dawn engine with the weight of panels included (I simply added 100 kg; it's the one named ION-SPs). Back then I decided not the include the Dawn in the analysis because the electrical demand issue is complex enough (there are now three ways to deal with it: panels, RTG, fuel cells) that it deserves its own separate analysis. However, I can add this solar-panels-at-Kerbin version of the Dawn for now.

Thanks Meithan! I had missed the fact that that chart had SP mass added. I think adding 100 kg mass is a very good way to set a baseline for comparison with other engines for small-mass payloads in vacuum.

Happy landings!

[cephalo]

I have one more dumb question, when we talk about TWR in a vacuum, usually in orbit I guess where things are functionally weightless, how is that measured on these charts?

Sometimes I'm frustrated with the sluggishness of the LV-N and would rather have a Poodle for more thrust, but I don't know how to quantify what my desired thrust is. I was thinking of using dV per minute, enough to avoid 8 minute burns to Minmus I guess.

[Concentric]

I have one more dumb question, when we talk about TWR in a vacuum, usually in orbit I guess where things are functionally weightless, how is that measured on these charts?

Sometimes I'm frustrated with the sluggishness of the LV-N and would rather have a Poodle for more thrust, but I don't know how to quantify what my desired thrust is. I was thinking of using dV per minute, enough to avoid 8 minute burns to Minmus I guess.

That's what people have brought up an "acceleration ms^-2" option for. Just divide the delta-v by the acceleration and you get roughly the length in seconds of the burn. I recently went about doing this manually for a ship: I calculated the post-burn mass from the delta-v, ISP and initial mass, then took the (geometric) mean of the initial and final masses, multiplied by delta-v and divided by total thrust, and ended up with a closer estimate for the burn length than the manuever node gave (once I began to fire). I think those might just use the initial mass, rather than the mean of the masses.

[Meithan]

I have one more dumb question, when we talk about TWR in a vacuum, usually in orbit I guess where things are functionally weightless, how is that measured on these charts?

A TWR of 1 basically means the acceleration produced by the engines is equal to 1 g, or about 9.8 m/s². You can thus think of TWR as a measure of the acceleration that the engines can impart on the ship.

The standard reference for g is Kerbin's surface gravity of course, which is what is implied when we just say "the TWR is 2". But it's also possible to re-define TWR relative to the gravity on any other body. Thus, an "Eve-relative TWR of 2" means an acceleration of twice the gravitational acceleration on Eve's surface, which is 16.7 m/s².

Sometimes I'm frustrated with the sluggishness of the LV-N and would rather have a Poodle for more thrust, but I don't know how to quantify what my desired thrust is. I was thinking of using dV per minute, enough to avoid 8 minute burns to Minmus I guess.

Since "minimum TWR" is basically equivalent to "minimum acceleration", you can use this information to compute approximate burn times. Say I have a ship with a (Kerbin-relative) TWR of 2.0. That means the engines can yield an acceleration of about 2 * 9.8 m/s² = 19.6 m/s².

How long will a 1000 m/s burn take? If the acceleration remained constant, then you could use the formula burn_time = delta-v / acceleration, which would yield

burn_time = (1000 m/s) / (19.6 m/s²) = 51 seconds

On the other hand, the LV-N is too heavy to efficiently provide large TWRs. Say I have an LV-N based ship with a TWR of 0.3. Then the burn time for the same 1000 m/s maneuver would be:

burn_time = (1000 m/s) / (0.3*9.8 m/s²) = (1000 m/s) / (2.94 m/s²) = 340 seconds = 5 minutes 40 seconds

Note that these are approximations only because the acceleration is not constant: as you burn fuel, your mass diminishes but the engines still produce the same thrust, so the acceleration will increase. The real burn times will actually be lower than this, but it's a simple way to get an idea.

Edit: ninja'd by Concentric . By the way, I will add burn time data to the "details" panel.

Edited May 29, 2015 by Meithan

[Meithan]

OK people, I just uploaded the latest updated version:

http://meithan.x10.mx/KSP/engines/

I haven't tested it much so please do try it out and report any errors / weird behavior.

Changelog:

• Zoom capability:
  
  • (1) you can click and drag to draw a selection box, and the chart will be recalculated for that region
    
  • (2) you can also click the + and - zoom buttons in the chart's corner, which will widen or shrink the ranges by 2x
    

  [*] Expanded details area on chart mouseover, showing some provisional details for each of the solutions.

  [*] "Full" engine names (and got rid of "show old names" checkox)

  [*] Added a version of the "Dawn" engines with 100 kg of "solar panel mass".

What do you think? I've considered changing the click-and-drag behaviour to instead let the user pan the chart, and reserve zoom for the buttons. Also: what details of those currently shown do you think are useful? Which would you eliminate? What other details could be displayed there?

The buttons are lacking some form of feedback when you "click" them, but I'm working on it.

The burntimes shown assume starting the burn with the tanks full, when acceleration is smallest.

I'm thinking that with some more polishing this is could be mature enough for release. Additional big features like selecting which variables are plotted or total masss line plots could then be added post-release.

[Teilnehmer]

Fascinating!

I've considered changing the click-and-drag behaviour to instead let the user pan the chart, and reserve zoom for the buttons.

That’s because of the realization difficulties?

The click-and-drag frame is nice, but the [+]/[−] buttons are sort of useless. I’d rather have a ‘zoom back’ button that sets the previous range values.

Also: what details of those currently shown do you think are useful? Which would you eliminate? What other details could be displayed there?

The details area is just great! Now it has everything I thought about to suggest. And even more.

Great!

- - - Updated - - -

My suggestion is the ability to freeze the details (e.g. by clicking a point in the graph) so one could move the mouse having the details unchanged.

[Teilnehmer]

T-1 Aerospike doesn’t work for some reason.

UPD:

The reason found.

<input id="chkAerospike" type="checkbox" checked="" name="mediumengines">...</input>

The input id should be '#chk'+allEngines.name, i.e. 'chkT-1' instead of ‘chkAerospike’.

Edited June 3, 2015 by Teilnehmer

[Starhawk]

Meithan, there isn't enough rep on this entire forum (or even the whole internet) to give to you.

I only looked at the new version for a few minutes. It's wonderful. This has already become an essential tool for me.

Thank you.

Happy landings!

[LittleBlueGaming]

OK people, I just uploaded the latest updated version:

http://meithan.x10.mx/KSP/engines/

Amazing. I love it more and more.

I second the suggestion to freeze the details on clicking a point in the chart. Problem would be how to revert to the original behavior. Maybe it would be better to use the second details window for that purpose instead of a runner-up. One updates as the mouse moves, the other updates when you click(preferably with a marker on the chart showing where that saved point is). After all, if I don't want to use the 4 LV-N's that are the best choice for what I want, I can just uncheck that engine to see what's the next-best option. That gives me a much better visualization of my other options in that area than scrolling around looking at the #2 box, not being able to see all the crossovers underneath.

For the zooming, perhaps a third 'reset' button that restores the original viewpoint. Especially useful after a click-n-drag zoom, and especially when that zoom isn't even close to a 1:1 aspect ratio.

Trying to picture what it would be like zooming with the buttons and click-n-drag panning, and I'm thinking that would be even better. You'll keep the same aspect ratio as you zoom in, and being able to pan would just be really nice in general. It would take a little more work to zoom into a specific area, but I think it's still better than not being able to pan and needing to manually change the chart properties up top.

[Meithan]

That’s because of the realization difficulties?

The click-and-drag frame is nice, but the [+]/[−] buttons are sort of useless. I’d rather have a ‘zoom back’ button that sets the previous range values.

So you'd get rid of the zoom buttons? A "go back" button is completely doable. It could even remember all settings since the last time the ranges were manually set (or, heck, even since page load -- it's just remembering four numbers per view).

For the zooming, perhaps a third 'reset' button that restores the original viewpoint. Especially useful after a click-n-drag zoom, and especially when that zoom isn't even close to a 1:1 aspect ratio.

Trying to picture what it would be like zooming with the buttons and click-n-drag panning, and I'm thinking that would be even better. You'll keep the same aspect ratio as you zoom in, and being able to pan would just be really nice in general. It would take a little more work to zoom into a specific area, but I think it's still better than not being able to pan and needing to manually change the chart properties up top.

For the click-and-drag panning I'm thinking something similar to what alexmoon did in his Launch Window Planner. Take a look (much of my UI was inspired by his). It's not trivial to implement, but I think I can pull it off. Of course, this would mean getting rid of the selection-box zooming.

What do others feel about this zoom functionality? What method do you prefer?

My suggestion is the ability to freeze the details (e.g. by clicking a point in the graph) so one could move the mouse having the details unchanged.

Amazing. I love it more and more.

I second the suggestion to freeze the details on clicking a point in the chart. Problem would be how to revert to the original behavior. Maybe it would be better to use the second details window for that purpose instead of a runner-up. One updates as the mouse moves, the other updates when you click(preferably with a marker on the chart showing where that saved point is). After all, if I don't want to use the 4 LV-N's that are the best choice for what I want, I can just uncheck that engine to see what's the next-best option. That gives me a much better visualization of my other options in that area than scrolling around looking at the #2 box, not being able to see all the crossovers underneath.

Freezing the details is a great idea. I could rig the right-click to "unfreeze" the details. A crosshair on the chart would indicate what point is currently "frozen in", and right-clicking would let go of that selection.

LittleBlueGaming's idea of only freezing one of the details panels is also good, but I'm not sure about some of the aspects of this. I like the idea of being able to see both the optimal and runner-up engines because it quickly gives you an idea of how close the top solutions are to each other. And unselecting an engine to see the other solutions requires recomputation of the whole chart, so I'd rather this be a sort of "last-resort" channel to get the information you want. But I'm thinking of ways to make this idea (freeze only one panel) work.

T-1 Aerospike doesn’t work for some reason.

UPD:

The reason found.

<input id="chkAerospike" type="checkbox" checked="" name="mediumengines">...</input>

The input id should be '#chk'+allEngines.name, i.e. 'chkT-1' instead of ‘chkAerospike’.

Great catch, Teilnehmer! Must've missed that checkbox id when I changed the names of the engines. It's fixed now.

Meithan, there isn't enough rep on this entire forum (or even the whole internet) to give to you.

I only looked at the new version for a few minutes. It's wonderful. This has already become an essential tool for me.

Thanks, Starhawk!

tavert (the author of the original charts posted before 1.0) still feels that what I'm doing isn't valid for the very low mass payloads, due to tanks being discrete in reality, but I still feel the tool is generally useful in giving an idea of which engine is likely to be optimal for a (payload,dv) combination. I'll add a disclaimer about this to the final version. I've also been discussing with him the possibility of porting his original code to JavaScript and using it instead of mine to drive the calculations behind the webapp. My main concern with this is speed: at some point his code does a bit of trial-and-error exploration, and that could take some time. We'd have to find ways to optimize it.

[LittleBlueGaming]

For the click-and-drag panning I'm thinking something similar to what alexmoon did in his Launch Window Planner. Take a look (much of my UI was inspired by his). It's not trivial to implement, but I think I can pull it off. Of course, this would mean getting rid of the selection-box zooming.

I would personally prefer that to the selection box zooming. I didn't even know you could pan that launch window graph

Freezing the details is a great idea. I could rig the right-click to "unfreeze" the details. A crosshair on the chart would indicate what point is currently "frozen in", and right-clicking would let go of that selection.

LittleBlueGaming's idea of only freezing one of the details panels is also good, but I'm not sure about some of the aspects of this. I like the idea of being able to see both the optimal and runner-up engines because it quickly gives you an idea of how close the top solutions are to each other. And unselecting an engine to see the other solutions requires recomputation of the whole chart, so I'd rather this be a sort of "last-resort" channel to get the information you want. But I'm thinking of ways to make this idea (freeze only one panel) work.

One option could be to use the second panel to show the frozen point while it's set, and when it's not set it shows the runner-up.

[tavert]

tavert (the author of the original charts posted before 1.0) still feels that what I'm doing isn't valid for the very low mass payloads, due to tanks being discrete in reality, but I still feel the tool is generally useful in giving an idea of which engine is likely to be optimal for a (payload,dv) combination. I'll add a disclaimer about this to the final version. I've also been discussing with him the possibility of porting his original code to JavaScript and using it instead of mine to drive the calculations behind the webapp. My main concern with this is speed: at some point his code does a bit of trial-and-error exploration, and that could take some time. We'd have to find ways to optimize it.

I'm glad you took up the mantle of keeping this maintained, even if the calculations here so far are simplified. Porting it to JavaScript so it can be a web app is another thing I never felt like doing, but obviously makes it easier to use interactively for everyone.

JavaScript JIT compilers are pretty impressively fast and clever these days thanks to constant Chrome-vs-everyone-else competition in web browsers. I don't think you need to worry too much about speed. If you want to implement the more accurate discrete-tanks version then you can always put the new code behind a checkbox to switch back and forth between discrete and continuous tank results, then we'll know for sure how much difference it makes in both results and speed. If you put the code up on github I might even send a pull request or two. Feel free to PM me on reddit /u/tavert if I'm offline for a while here, I might not check back all that often.

[Teilnehmer]

Problem would be how to revert to the original behavior. Maybe it would be better to use the second details window for that purpose instead of a runner-up.

Second click in the graph unfreezes the details. That’s how I imagine it. I don’t think one more details area is a good idea.

[Meithan]

Hey guys, sorry for being absent, work has been absorbing. I've been progressing with the app and it's almost ready for the next revision. I think you'll be pleased with the changes . Hopefully I'll be able to finish the remaining details and post an update during the weekend.

JavaScript JIT compilers are pretty impressively fast and clever these days thanks to constant Chrome-vs-everyone-else competition in web browsers. I don't think you need to worry too much about speed. If you want to implement the more accurate discrete-tanks version then you can always put the new code behind a checkbox to switch back and forth between discrete and continuous tank results, then we'll know for sure how much difference it makes in both results and speed. If you put the code up on github I might even send a pull request or two. Feel free to PM me on reddit /u/tavert if I'm offline for a while here, I might not check back all that often.

I'm realizing the JS JIT compilers are indeed pretty fast. The JavaScript port of the calculation definitely outperforms the original Python implementation (granted, that's not saying too much since Python isn't fast by any measure, but it's still an interesting observation). Uploading the code to GitHub so other people can work on it is a great idea. I'll find you on reddit.

[Meithan]

Alright, people, it's here!

http://meithan.x10.mx/KSP/engines/

Changelist:

• New toolbar
  
  • Shrink or expand the payload or dv ranges (separately) with the zoom buttons (got rid of the old on-chart buttons).
    
  • Recall previous views with the arrows (only remembers payload/dv ranges for now; might consider remembering all settings).
    

  [*]New chart interactivity

  • Click-and-drag to pan the view! It will limit the pan to prevent negative values.
    
  • Alternatively, hold the control key while click-and-dragging to draw a zoom box, as before.
    
  • Click on the chart to freeze the details panel on that point; click again to unfreeze.
    

  [*]Performance upgrade: I optimized the calculation, it should run 2x-3x faster than before.

  [*]Changed how the Dawn is handled: instead of two engines (one with, one without the panel mass), it's now a modifier on the engine.

I hope you like it, and I'll be waiting for your bug reports. The panning was kinda acting weird at times, and I'm not sure I've completely fixed it. Any suggestions to improve intuitiveness of the controls are greatly appreciated (for instance: do you think the behavior of the +/- signs is intuitive, or are they backwards?)

I think I'm happy with the current set of features and would say the app is ready for release feature-wise (pending more testing to iron out bugs). The only thing left to do is adding some tooltips/instructions/help.

[LittleBlueGaming]

I definitely notice how much faster it is.

Small little thing, not sure if there's even anything you can do about it, but if you drag the chart until the cursor is off the canvas, it won't receive the mouseup event. Clicking on the canvas will restore the chart to the point it was at when the canvas lost focus. This is most annoying if you start dragging from an edge of the chart.

Chart saving works great, zoom/recall work fine, control-zooming works fine, freezing/unfreezing works fine.

[Meithan]

Yeah, it seems if the mouse is moving too fast it doesn't catch the canvas exit event (since there's nothing outside the canvas to register it). I can work it out.

What should the expected behavior be in your opinion? Cancel the current pan when the mouse exits the chart area instead of the canvas? Should the current pan be executed instead of cancelled?

[LittleBlueGaming]

It happens as well when the mouse is moving slowly. I haven't worked with the canvas element at all, so I haven't the slightest of its workings. If there is a canvas exit event, it doesn't appear to be working at all while the mouse button is down.

Probably be better to execute the pan at the moment the mouse exits the chart if you can't get it to execute when exiting the canvas. Cancelling it would probably be frustrating.

In that case, it would be nice to also change the cursor when it exits the chart area.

- - - Updated - - -

Do you perhaps need to manually trigger a mouseup event in the canvas exit event?

[Meithan]

You're right, the onMouseLeave event is disabled. Working on it. I think I can make it execute the last action on canvas leave (catching the event on the html document instead of the canvas object).

[Meithan]

Alright, take two:

http://meithan.x10.mx/KSP/engines/

After trying several options I found that the simplest was the best: simply have the document, instead of the chart/canvas, catch the MouseUp event. Pan or zoom selection can only be started by clicking inside the chart area, but the mouse can then wander outside it while holding the button and releasing it anywhere will trigger the pan/zoom. It seems to be working on my end.

What do you think?

[LittleBlueGaming]

Works perfectly for me, I think it's ready for release.