tavert

No, it isn't. There's a bunch of math on this here: http://forum.kerbalspaceprogram.com/threads/39812-Landing-and-Takeoff-Delta-V-vs-TWR-and-specific-impulse It's counterintuitive, but it's more efficient to come in as low as possible and burn slightly off-retrograde to keep your altitude constant as you slow down, rather than burning retrograde and allowing yourself to fall. The difference is more pronounced at lower thrust-to-weight ratio.

I don't know the part count, but this was 1.51 tons last June and the same parts should still work: Removing most of the oxidizer would help a little, but this predated tweakables. Using just a 48-7S and enough small fuel tanks to get 4.4-4.5 km/s dV should beat this by a few hundred kg.

There's a perfectly valid derivation (http://en.wikipedia.org/wiki/Tsiolkovsky_rocket_equation#Derivation) where you can look at it as a stream of propellant leaving the rocket with mass flow rate mdot and effective velocity relative to the rocket of ve. Applying conservation of momentum, you get that the acceleration of the rocket is effective exhaust velocity times mdot divided by the remaining mass of the rocket (subject to your sign convention on mdot). A bit simplistic, but nowhere was impulse or specific impulse absolutely required.

I agree with your intuition that the LFB is the most likely case for partial fuel loads to really make a significant difference. But I'd prefer to run the numbers and see whether it makes any difference on the margins. In case this wasn't posted earlier, here is a somewhat refactored faster version of the code that might be slightly easier to understand, though it depends on another mex file for binary search: https://dl.dropboxusercontent.com/u/8244638/margin_of_victory.m Anyone is welcome to have a go at porting the code to an open-source language - I would recommend Julia for its speed, but if someone would really rather use Python or JavaScript or whatever, go ahead. I'm happy to answer any questions about the calculations or give recommendations for how I think the approach should be updated to account for partial fuel loads. I'm just a bit busy right now to rewrite it myself, and might not check back here all that frequently. Regarding part counts, that requires a more expensive optimization problem to take into account. It's better displayed in spreadsheet form than in charts. I think there's a link to the Wolfram CDF version earlier in this thread, or I also put together an OpenOffice version of the same thing: https://dl.dropboxusercontent.com/u/8244638/KSP%20Design%20Optimizer.ods

"Same in either unit system" is an explanation people like to use here, but it makes no sense. If you're working in metric, there's no physical reason to ever insert an acceleration conversion factor in the equation. Conservation of momentum is expressed in terms of effective exhaust velocity, and "specific impulse" should really mean impulse (= product of force by time) per unit mass of propellant. The acceleration factor is arbitrary (the physics here applies the same on Earth, the moon, deep space, or anywhere else), and comes from the ratio between pounds force and pounds mass. That annoying unit conversion factor is what leads to the common convention of referring to a quantity that should really physically be a velocity, as a time instead. KSP should kill that convention with fire and just specify the engine efficiency in terms of effective exhaust velocity. Converting between meters and feet is much much easier than having to explain every 5 minutes that the conversion factor in the rocket equation doesn't change with local gravity.

I think there's a link to the code somewhere in here, do you have Matlab? I've been thinking of porting the code to Julia (http://julialang.org/) so anyone can run it, but as Pecan helpfully mentioned I have been paying rather little attention to KSP lately. A few things would need to be tweaked to bring the code up-to-date. Obviously the new engines should be added. The new fuel tanks have an inferior mass ratio than the old tanks so you really only want to use the new tanks for part-count reasons, not mass-efficiency. The combination of adding tweakables and the new liquid fuel boosters that combine engine and fuel tank into the same part mean some of the assumptions underlying the code are no longer valid. I would have to refactor things to properly account for the case that a partially-filled fuel tank (or LFB) might be a better choice than multiple full smaller tanks. And lastly, if any of the new engine types show up in the updated results, I'd need to manually assign them readable colors.

Good thread. I haven't updated these so the part data's a few versions old now, but have a look at https://dl.dropboxusercontent.com/u/8244638/KSP%20Design%20Optimizer%20v02.html (need to install the Wolfram CDF Player plugin http://www.wolfram.com/cdf-player/ ), or the OpenOffice version here https://dl.dropboxusercontent.com/u/8244638/KSP%20Design%20Optimizer.ods (read over and enable the macro) For a single stage using a given single type of engine, and a set of discrete fuel tank choices, solving for the number of engines and number of each type of fuel tank to minimize total mass (or cost, or part count, or some linearly weighted combination thereof) subject to minimum delta-V and minimum TWR constraints is a mixed-integer linear program. You can translate the delta-V constraint into a mass ratio constraint by inverting the rocket equation, since Isp is constant for a single type of engine (at a fixed altitude). Don't try to use the mass ratio of the fuel tanks to get a continuous answer, since fuel tanks aren't continuous in stock KSP. Unless you're looking at a mod that gives you continuously-sized fuel tanks, you can only use integer numbers of each type of fuel tank in the stock game. With tweakables you can now vary the fuel load almost continuously, but the dry mass of the fuel tanks makes this an inherently discrete integer problem. If you want to consider mixing separate engine types together and/or multi-stage rockets, it becomes a mixed-integer nonlinear problem and quite a bit more challenging to solve.

Cubic struts are massless in flight, so they actually don't count. Crew capsules and seats behave differently here. Repeat your test with a seat, and you'll see the Kerbal mass does contribute to the craft.

Ubuntu or Mint are the easiest to get started with. Installing Arch is more complicated, it kind of forces you to understand what you're doing every step along the way of building the operating system, piece by piece. Unless you know what you're doing, it's best to go with an apt-get based distribution: Debian, Ubuntu, Mint, etc. These are the most popular, so most documentation online starts first with "you need to sudo apt-get install this that and-other-thing." If you're on an RPM or Pacman distribution (Fedora, Arch or Manjaro, etc), then packages will often be named slightly differently and you may have to go looking for the equivalent call to yum or pacman. Frequent use of the command line is a feature, not a bug. Bash is an infinitely superior scripting environment to Windows cmd and batch files. Once you get the hang of it, you may find yourself writing lots of little shell scripts to help automate routine tasks. If you want more power/expressiveness than bash, pick your favorite out of perl, python, ruby, etc - they're all right there for you. Package management for these languages works much much better in a recent apt-get distribution than anywhere else.

From page 1, about 9 months ago: Don't think Arrowstar has implemented the 2-burn transfers yet, but please correct me if I'm wrong.

This was almost a year ago, 1.64 tons not including the pair of Kerbals: Nowadays with the 48-7S you can beat this by maybe half a ton or so? Kerbal on a ladder (perpendicular to thrust direction if you want to exploit broken physics to save dV), one FL-T100 drop tank off the front, and a couple of round-8 tanks to finish the ascent and do the powered landing. Doing the powered landing is obviously harder without MechJeb, but I bet some of you can do it

Appreciate it! I have gone lurker for most intents and purposes. Too busy to play KSP, work and other distractions are taking more of my time.

Depends what type of engine you're using: You can do better by splitting things up into multiple stages, that changes the optimal TWR story a little bit but is harder to plot in a general way. For single-stage landers if you want to maximize payload fraction, I put together a fancy tool for that here http://forum.kerbalspaceprogram.com/threads/61659-Wolfram-Web-App-Optimal-Single-stage-Lander-Design-Tool, you may or may not find it useful.

A delta-V map only shows a single number for landing and takeoff. This is an extreme simplification and tries to show generic average numbers, so is not all that useful for detailed design. For landing and takeoff from an airless body, the delta-V cost depends on your TWR, specific impulse, and trajectory. For ideal minimum values assuming the best possible trajectory, see data here http://forum.kerbalspaceprogram.com/threads/39812-Landing-and-Takeoff-Delta-V-vs-TWR-and-specific-impulse

Isn't this just applying the Pontryagin principle to express the solution in terms of a boundary value problem? I don't see how this is any different than what I was trying on page 4. If you come up with a shooting solver, either forward or backward or multiple-shooting, that can converge to good values of the initial or final costates, let us know. If C++ is too much of a PITA, you may want to have a look at writing in Julia. It's a new language, still a bit rough around the edges, but it's aiming at a nice best-of-both-worlds combination of Python's high-level productivity and close-to-C++ speed.

If you have infinite TWR, it doesn't matter which direction you burn in once you're past escape speed. If you have a given speed at a given altitude, your orbital energy is the same no matter which direction your velocity vector is pointed. But for finite TWR, your net acceleration is lower when you burn up than when you burn perpendicular to gravity. So it takes less time to reach a given speed by burning sideways. The lower your TWR, the more the difference.

I'm not an expert in all the finer implementation details of how automatic differentiation works, but essentially given the source code of some complicated nonlinear function, automatic differentiation can calculate the numerical gradient of that function at a given input point with roughly the same complexity as computing the function value. There are different methods, forward mode is good for functions with a higher-dimensional output than input, reverse mode is good for functions with a higher-dimensional input than output. Then there are different types of implementation, commonly based on either operator overloading or source code transformation. The result will be much more accurate and much more efficient calculation of gradients than naive finite differencing, which results in faster convergence of an optimization algorithm.

Oh, hah! Whoops, didn't know how that worked. Was I supposed to get a message from the tip bot or something?

Glad you appreciate my math! I should note that FAR changes some of these jet thrust curves around a bit. If I had FAR installed I could go dig through the part.cfg's and see how different they really are.

That question reduces to, can you formulate the problem in such a way that the objective function and constraints are differentiable? Logic and switching could make that rather complicated, but it depends on the specifics of the objective and constraint functions. If you can write Matlab code to evaluate them in the first place, then you should have enough information for an automatic differentiation library to do the rest of the work. It's not something I would try to do symbolically, I would use an AD library. For C++ ADOL-C and CppAD are very good, I'm not so sure if there are any good open-source tools for doing the same thing entirely within Matlab. This page http://www.i2c2.aut.ac.nz/Wiki/OPTI/index.php/Advanced/Deriv1 looks like a pretty good reference on the topic. I'll frequently use Matlab or Python to put the problem together in the first place but then output an optimization problem representation that a compiled solver can read and do AD on - either OSiL which is XML-based, or .nl which is used by AMPL and not really human-readable (but Pyomo knows how to write them). Sure, go for it. Some test inputs would help too, I imagine you already know where the bottlenecks are and what's most important to look at.

Why would there not be a gradient? SoI transitions are discontinuous, but with a lifted formulation adding additional variables and constraints there should be a way to express the whole problem in a differentiable way. It's generally better to have more variables with a simpler nonlinearity structure than trying to do finite differencing on a smaller number of variables with all functions as black boxes. I imagine the logic could be difficult to do correctly, it's easy to resort to a couple of "find" functions that will absolutely kill your speed. Logical indexing usually works nicely, but requires some care. I can look at things if you want some Matlab profiling help, are there similar functions or test cases in the released version of KSPTOT that would run the existing implementation?

It used to have a somewhat valid application doing the same job as the structural fuselage (adding new radial stacks with 1m attach points) at a slightly lower mass, but more recently added structural panels (or empty fuel tanks thanks to tweakables) serve that purpose even better.

I put a link in at the end of the OP. Yep. Since that depends on the engine and fuel stats, it's a bit more involved. Check out this tool http://forum.kerbalspaceprogram.com/threads/61659-Wolfram-Web-App-Optimal-Single-stage-Lander-Design-Tool I put together for precisely this purpose.

Was watching an Elon Musk keynote on Youtube from late 2012, at the end someone in the audience asked him if he had ever heard of KSP since they thought the video of Falcon 9 re-entering and landing propulsively looked like KSP.