Mass-optimal engine type vs delta-V, payload, and min TWR

[tavert]

I decided Julia lacked enough language features

I highly doubt that. It's quite a bit more sophisticated and higher-performance as a language than Python is (consider how much of the core language and standard library is implemented in Julia, as opposed to Python being largely implemented in C - sure there's PyPy but that still doesn't support numpy or much else), but of course the syntax is different so if you're more used to Python then use whatever you want.

[taio]

I highly doubt that. It's quite a bit more sophisticated and higher-performance as a language than Python is (consider how much of the core language and standard library is implemented in Julia, as opposed to Python being largely implemented in C - sure there's PyPy but that still doesn't support numpy or much else), but of course the syntax is different so if you're more used to Python then use whatever you want.

I don’t remember 100%, but trying to remember reasons why I switched to Python: familiarity & my love for the comprehension syntax, more flexible exceptions, and the wider availability of libraries. Especially there was a parser combinator library in Python that I liked and wanted to use, and I figured if it runs slow when I’m done I’ll just learn how to Cython and whatever else people do to make their Python fast.

Edited February 21, 2015 by taio

[tavert]

That's fair. The comprehensions in Julia don't support filters yet (hard to make that high-performance if you don't know the size of the output array ahead of time). Exceptions, well, I'll leave that topic alone.

Don't know whether you saw, but there is a Julia package called PyCall.jl that lets you call arbitrary Python code from Julia. There's a pyjulia project for doing the reverse as well.

[chicknblender]

Anybody want to resurrect this project with 1.0 parameters? I will buy you cookies.

[tavert]

Max thrust changes with atmospheric pressure now, right? Is it a linear relationship, or are people still testing and working that out?

[Red Iron Crown]

tavert! Good to see you back here.

A fair bit has changed in 1.0, thrust changes as Isp changes with pressure, and pressures >1atm are modeled, too. In each engine's .cfg file some points are defined for Isp vs. pressure, and as I understand it a cubic Bezier curve is used between defined points. The relationship of thrust to Isp is linear. For calculating at 1 atm or vacuum you could just use the defined values (these are shown in the editor).

Thanks for looking at this, I have found your charts very useful in the past and would be interested to see how they would look now.

[tavert]

Just dropping by for my couple-times-a-year visit, I don't actually plan on updating KSP or have much time to modify the code. If it's just that rocket engines now have more than 2 points in their atmosphereCurve, then it's a piecewise cubic interpolation like we figured out for the jets some time ago. Either the incoming and outgoing slopes at each interpolation point are given if there are 4 numbers, or the average slope for the 2 neighboring segments is used when there are only 2 numbers IIRC.

[Arrowstar]

Just dropping by for my couple-times-a-year visit, I don't actually plan on updating KSP or have much time to modify the code.

Hey tavert, I know you're busy, but if you have a moment, go check out KSPTOT. Version v1.3.0 has nice additions since you were last here.

[NathanKell]

Tangents aren't given for atmocurve curves for stock engines in 1.0.x.

[chicknblender]

Apparently somebody has already revived these curves for vacuum.

Javascript is disabled. View full album

Not my work and would be happy to give credit where it is due.

[Meithan]

Apparently somebody has already revived these curves for vacuum.

And for Kerbin sealevel atmospheric conditions too . See the main thread here:

http://forum.kerbalspaceprogram.com/threads/121565-Optimal-engine-charts-for-1-0-2

But this will soon be (or already is) obsolete since I'm creating a webapp to generate the charts on demand. It's still not finished, but you can take a look here:

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

The caveat is that the analytic results assume fuel and tanks are infinitely divisible, and not discrete like they are in the game. In this respect tavert's work is still superior.

[tavert]

The caveat is that the analytic results assume fuel and tanks are infinitely divisible, and not discrete like they are in the game.

You need to fix that. Otherwise your results are flat-out wrong for small craft.

[Meithan]

You need to fix that. Otherwise your results are flat-out wrong for small craft.

Can't, really, since I'm just solving for the total ship mass analytically. I'm not doing an optimization problem.

Why is it such a bad problem? The smallest LFO tank is the Oscar-B, which holds 0.2 t of fuel. Doesn't this mean that the analysis will be wrong at most by 0.2 t of fuel, since it's always possible to reproduce any fuel value up to 0.2 t?

Sure, there will be cases where, for small payloads, this discreteness makes the top solution actually not the best one, but I think that solution will still be very close, and the difference won't be big; it'll probably remain atop the top 3. Things like adding structural elements to connect the propulsion to the payload will probably have a larger impact in deviating from these analytic solutions than the discreteness of the propellant.

But I could be missing something so I'm interested in knowing what you have to say about this.

[tavert]

For small payloads and small delta-v's, that dry-mass discretization would be a substantial fraction of the differences you're trying to show.

You don't have to solve the full mixed integer problem unless you also want to impose part count or cost constraints, or factor those into the objective function. For a single engine type and ignoring part count and cost restrictions, you can take all combinations of different size tanks (ignoring the larger ones assuming they're still just integer multiples within the same family), sort by dry mass, then remove any combinations where the fuel mass is non-increasing. That gives you the actual discontinuous line for minimum dry mass for any given value of fuel mass. At a given delta-v you know what mass fraction you need, the continuous-tanks result gives you an optimistic guess for where to start looking, then you can check the actual combinations nearby to find the lightest one that can meet the required mass fraction.

Edited May 29, 2015 by tavert

[Meithan]

For small payloads and small delta-v's, that dry-mass discretization would be a substantial fraction of the differences you're trying to show.

Agreed, but then wouldn't the difference between the computed optimal masses be on the order of the discretization error? That means that even if my program does not find the actual optimal solution, it can find a solution within a small margin of the optimal one. That's good enough for me, and I could add a disclaimer to warn about this.

The webapp is not meant to be a full solution of the design problem anyway. If you're looking for that, I'm sure you've seen GaryCourt's Optimal Rocket Calculator. The engine charts are meant to be provide approximate guidelines of the regions where a specific engine might be a good choice. I still want to leave the player the fun of designing the ship.

You don't have to solve the full mixed integer problem unless you also want to impose part count or cost constraints, or factor those into the objective function. For a single engine type and ignoring part count and cost restrictions, you can take all combinations of different size tanks (ignoring the larger ones assuming they're still just integer multiples within the same family), sort by dry mass, then remove any combinations where the fuel mass is non-increasing. That gives you the actual discontinuous line for minimum dry mass for any given value of fuel mass. At a given delta-v you know what mass fraction you need, the continuous-tanks result gives you an optimistic guess for where to start looking, then you can check the actual combinations nearby to find the lightest one that can meet the required mass fraction.

I'm not sure I fully understand the procedure you describe, but I wanted to avoid exploratory solutions due to computation time concerns. I want the app to be running on JavaScript on the user's browser. Currently I'm simply evaluating a couple of formulas for a 500x500 (payload,delta-v) grid of points, and it already takes on the order of 500 ms. I do admit however that my current implementation is slow because I'm repeating the costly (I presume) exponential function.

As a point of reference, how long did your original engine charts take to generate?

[tavert]

Depends on the image resolution and what language they're implemented in. The calculation procedure was different when I originally had it in Matlab, but you can still read the Julia code which does things in a cleaner and more efficient way. It lays out the calculation, along with SRB's and other engine types. The part stats, list of small-tank combinations, and handling of atmospheric numbers would have to be updated for 1.0 of course, but the main part of the algorithm still applies. As long as you run things in a language with a JIT compiler that can do loops quickly, it's not that much slower than the analytical continuously-divisible-tanks approximation. Once in a while you may have to add an extra engine and re-try at the same point due to the tank discretization effects interacting with the TWR constraint.

[Meithan]

Depends on the image resolution and what language they're implemented in. The calculation procedure was different when I originally had it in Matlab, but you can still read the Julia code which does things in a cleaner and more efficient way. It lays out the calculation, along with SRB's and other engine types. The part stats, list of small-tank combinations, and handling of atmospheric numbers would have to be updated for 1.0 of course, but the main part of the algorithm still applies. As long as you run things in a language with a JIT compiler that can do loops quickly, it's not that much slower than the analytical continuously-divisible-tanks approximation. Once in a while you may have to add an extra engine and re-try at the same point due to the tank discretization effects interacting with the TWR constraint.

Well 500x500 seemed like a good target point, and I like the results so far. I've also added a low-resolution (200x200) option for slower computers (the map gets scaled to 500x500 to fit the same space). Interactvitiy means that the chart itself doesn't have to be that precise or information-rich (which is part of the reason I decided to use linear scale for the axes; there's no point squeezing the full conceivable payload range in one graph if the user can simply key in the specific range he wants).

What could be done at some point down the road is port your Julia code to JavaScript and use it on my webapp. The user interface and plotting routines are what's consumed the majority of development time anyway; the actual computation is straightforward enough. But I've never laid down my eyes on a line of Julia, so I guess that'll have to wait (good learning opportunity, though; I've heard high praise from Julia).

Right now I'm directing my efforts towards polishing the web interface and adding extra functionality. Some enthusiastic users have been recommending some interesting things and I do intend to indulge them wherever possible.

[tavert]

If you've seen one block-structured imperative dynamic language, it's not that hard to learn a new one or switch between them. Julia's closest to Lua or Matlab in syntax, and my code's not doing anything especially complicated with macros or multiple dispatch that wouldn't translate as well into other languages. JavaScript should be fine, and is the most convenient thing to work in for a web app (though maybe TypeScript, CoffeeScript, or Dart would be a little nicer once the total code size gets beyond a certain point). You can go to juliabox.org and get a shell and notebook interface to run Julia code without having to install it locally, if you just want to play around a little.

I suspect if you rearrange the loops properly so you can hoist certain calculations out of the innermost loops, you'll see noticeably better performance. The exponential's constant along a given delta-V line for a single type of engine, for example, so you could re-use the mass fraction across all payload points for the same dV.

[Meithan]

If you've seen one block-structured imperative dynamic language, it's not that hard to learn a new one or switch between them. Julia's closest to Lua or Matlab in syntax, and my code's not doing anything especially complicated with macros or multiple dispatch that wouldn't translate as well into other languages. JavaScript should be fine, and is the most convenient thing to work in for a web app (though maybe TypeScript, CoffeeScript, or Dart would be a little nicer once the total code size gets beyond a certain point). You can go to juliabox.org and get a shell and notebook interface to run Julia code without having to install it locally, if you just want to play around a little.

I quite agree: when the basic paradigm is the same it's just a matter of picking up the new syntax. Thanks for the link to juliabox, I'll toy around with it.

I suspect if you rearrange the loops properly so you can hoist certain calculations out of the innermost loops, you'll see noticeably better performance. The exponential's constant along a given delta-V line for a single type of engine, for example, so you could re-use the mass fraction across all payload points for the same dV.

Yes, that's the obvious place to optimize. It's currently done in this inefficient way because the code comes from a Python program that was initially used to compute total mass for single combination of parameters, and I simply adapted the plotting routines to it. It'll be interesting to see how much performance is gained by this change (I don't have much experience with JavaScript so I don't know how smart the JIT compiler optimization is).

[cy-one]

Could we get an up-to-date variant of these charts?