Meithan

OK, people, release day has arrived! Here's the release thread: http://forum.kerbalspaceprogram.com/threads/127691-WEB-1-0-4-Optimal-Engine-Charts-interactive-webapp Please direct all further discussion about the app to that thread. Thanks all for the help!

Optimal Engine Charts An interactive webapp for Kerbal Space Program v1.1.1 >> New URL: http://meithan.net/KSP/engines/ << Current app version: v1.1.2 Github project: https://github.com/meithan/engine_charts This webapp will let you compute interactive optimal engine charts on demand. They are meant to answer this general question: What is the optimal engine for a given payload mass and desired Δv, subject to a minimum TWR (or acceleration) restriction, where by optimal we mean that the resulting ship should have the least possible mass? The calculations include the dry mass of the tanks and consider a variable number of engines to satisfy the TWR restriction. The purpose of these charts is not to design the ship for you (there are tools for that), but to provide general guidelines about which engines are the best choices for a wide range of circumstances. These charts are inspired by tavert's original engine charts, which I continued (with a different approach) and expanded for 1.0 in a previous post. How to use the app Basic instructions: Choose a fixed variable out of Payload mass, Minimum TWR or Delta-v. The remaining two variables will be on the axes of the 2D plot. Fill in the chart parameters, including payload and Δv ranges, minimum TWR, atmospheric pressure and maximum number of engines. Select the engines that should be included in the analysis. Click "Calculate!" and the chart will appear; details will be shown on the panel to the right. You can get more help by opening the collapsible areas by clicking on the buttons. Some extra details are also given by mousing over the tooltips. The chart is interactive: Mouse over the chart to see details for the point under the mouse in the panel to the right. Click on the chart to lock the details panel to a specific point in the chart; click again to unlock. Click-and-drag to pan the currently displayed view; the chart will be recomputed with the new ranges. Hold the CTRL key and click-and-drag to zoom the chart to the selected area. Use the button controls under the chart to change the ranges, recall previous settings or save the chart. Further details and assumptions Single-stage ship. As we all know, dropping mass is the way to reach higher Δv budgets, but I'm keeping it simple here. As a rule of thumb, above ~5000 m/s it's probably better to use multiple stages. Ship has only one engine type, since testing all possible engine combinations would require a different approach. "Payload" is defined as everything that is not the propellant, tanks or engines used to push the actual payload around. This means "payload" includes stuff like structural elements required to mate the actual payload to the tanks/engines. Propellant quantity is treated as a continuous value, so tanks are considered infinitely divisible. While this is not entirely realistic, one could approximate this in practice by using a large numbers of small tanks. In this respect tavert's original analysis is still superior. This means that the analysis can be inaccurate for light (< 2 tonnes) payloads. The thrust-to-weight ratio (TWR) restriction should be used to ensure solutions remain practical (sure, a single LV-N pushing 1000 tonnes will have fantastic Δv, but burns will take forever). Note that Kerbin-relative TWR is equivalent to minimum acceleration measured in standard gees. Assumes the full-to-dry mass ratio of the tanks is 9 in general, except where noted. All "rocket" LFO tanks have this ratio in 1.0.4, while the "spaceplane" LFO tanks (i.e. Mk2-Mk3 tanks) have slightly worse ratios, very close to 8. The change to liquid fuel-only for LV-N is accounted for, and I've used a tank full-to-dry mass ratio of 8 for it, which closely matches the ratios of the Mk2 and Mk3 liquid fuel-only fuselages. The KR-1x2 "Twin Boar" liquid booster is treated by discounting 4 tonnes from its mass, which is the dry mass of one orange tank; the propellant it can carry and the dry mass of the tank are included elsewhere in the calculation. The RAPIER is only considered operating in closed-cycle mode, i.e. "rocket mode" using liquid fuel and oxidizer. For the O-10 monopropellant engine, I've assumed a full-to-dry mass ratio of 7, which is close to the average value for the larger tanks; the smaller tanks have worse ratios. For the "Dawn" engine the full-to-dry mass ratio is assumed to be 2.3, roughly that of the xenon tanks. Also, by default the analysis will include an extra 100 kg of mass per engine, which accounts for the mass of the solar panels required to continuously operate the engine at Kerbin's distance form Kerbol. This extra mass can be turned off with a checkbox. Engine specs for 1.0.5 are used throughout, extracted directly from the game's .cfg files. Airbreathing engines and SRBs are left out of the analysis, for now. Formulas For a given desired Δv and payload mass (m_payload), the optimal (i.e. minimum) total mass of the ship for a given engine type is: where m_engine is the mass of the individual engine, I_sp its specific impulse, g0 standard gravity (assumed to be 9.81 m/s^2), and the number of engines, n_engines, is given by where TWR_min > 0 is the minimum required Kerbin-relative thrust-to-weight ratio of the ship, TWR_engine that of the engine by itself, and is the ceiling function, which indicates to round the result up to the next integer. If no TWR restriction is imposed (i.e. TWR_min = 0), n_engines is simply 1. In these two formulas, the parameter alpha (α) is defined as the propellant-to-dry mass ratio of the tanks; it is equivalent to the conventional full-to-dry mass ratio minus one: Finally, the calculation requires computing the maximum theoretical Δv of a the engines, which depends on α and the minimum TWR as Here's a plot of this quantity for some of the engines (click for larger image): Planned/suggested features Option to plot a different set of variables as the axes of the plot (e.g., minimum TWR vs. Δv for a given payload mass) Option to determine optimal engine by propellant mass, not total ship mass Ability to add user-defined engines Cost information? Engine pics ... suggestions are welcome! Changelog License The Optimal Engine Charts webapp is free software licensed under the GNU General Public License v3. You are free to use, distribute and modify this software as you see fit, subject to the provisions of the license.

Yes, I'm afraid the app is not very touch-device compatible at the moment. The problem is that "traditional" mouse events don't work the same way since there's no mouse. I have to read up on how to make these things touch-device friendly. Thanks for your feedback, and I'll let you know when I've made some progress on this issue.

These charts are not meant to address combinations of engines because they're based on analytical mathematical results. Exploring engine combinations would require a trial-and-error iterative approach, or more complex iterative optimization methods. For that, take a look at the KSP Optimal Rocket Calculator. This question is already answered by this app if using a single engine type. Just input a delta-v range that includes these values (say, from 100 to 1000 m/s), and compute the chart for various TWR restrictions. Of course, the answer will depend on your payload mass: it will be completely different if it is a small 1 tonne satellite vs. a 20 tonnes Duna lander. If you want the answer to be applicable to a wide range of payload masses, well, enter an appropriate payload mass range. For now, minimum TWR is a fixed parameter because only two variables can be plotted in a two-dimensional map. But one of the planned features (perhaps the highest priority one) is being able to change which two variables appear on the plot and which third variable is fixed (out of payload mass, delta-v, TWR restriction). The app does tell you the fuel mass of the two top solutions (look in the details on the right panel), so you could use that to get an idea, but it's a very simple change to have it determine the "fuel optimal" engine instead. Added to the list of wanted features . I do suspect, as you do, that this will give an extra advantage to the LV-N and thus will dominate even more. I'm not sure it would be that useful. Most engines use the same propellant (LFO/LF), so in those cases it would reduce to "fuel mass optimality". Thus this would become a Dawn vs. everyone else comparison. But it's also easy to add fuel cost information and make that the parameter to optimize. Added to list of desired features.

Here's another "positive" take on the Falcon 9 launch failure (and the previous recent ISS cargo delivery mission failures), posted on YouTube channel Smarter Every Day (which is fantastic, btw):

Oh, you shouldn't feel like that, I think we all started doing "trial-and-error" (at least I did; I remember how I failed to reach orbit --because I ran out of fuel-- many times when I started playing). There's just a point when your missions start to get complex enough that you don't want to get there and realize you don't have enough fuel (or thrust, or whatever), and for that a little math goes a long way. And it's not like you need a lot of complicated stuff: computing delta-v's is pretty much the only really necessary tool in my opinion, and for that I use MechJeb. I can no longer design anything without knowing its delta-v; it's just such a crucial piece of information. But that's pretty much it; I still do trial-and-error for most other things. These charts are more something done out of geek interest (and, for me, desire to learn HTML5, too) rather than necessity; even I only occasionally use them to get a rough idea of which engines to start trying when designing a new ship. It's even frequent I will not choose the optimal engine, too, sometimes for practical reasons and sometimes even for aesthetic one (a non-optimal engine just looks cooler).

OK, try refreshing the page and see if it's fixed. Also, I just realized that some of the chart interactions might not work properly on a tablet or mobile, where there's no left & right clicks. How's dragging the view / locking the details panel working for you?

1.0.4. And I just fixed a typo in the mass of the Twin Boar.

Thanks a lot John. I've seen that happen once before, on a Mac. Let me see what I can do.

Weird, at that resolution you should not have any layout problems, it's higher than my own screen's! Is it possible for you to post a screenshot?

I don't remember this being posted before. Here's a site maintained by the John Hopkins Applied Physics Laboratory where they are releasing LORRI images in raw form almost as soon as they're received on Earth: http://pluto.jhuapl.edu/soc/Pluto-Encounter/

Thanks for the report, John. I'll look into it. Bootstrap is supposed to do "smart" changes to the page layout to accommodate smaller screens, but I haven't tested it much. What tablet are you using? What's the screen resolution?

Update: the webapp is ready for release! Check it out and tell me what you think: http://meithan.x10.mx/KSP/engines/ The functionality is mostly unchanged; I just added info tooltips and help buttons, as well as acknowledgements and a license notice. I also updated the engine stats to 1.0.4 (thanks for the list of changes, Slashy). I'm preparing a new forum thread in the Tools and Applications subforum. Additional discussion related to the webapp should be directed there. There are still some ideas I'd like to develop (if time permits), such as being able to change the pair of variables that are plotted, and perhaps line plots giving further details for specific points. Thanks to all who helped with testing and provided useful suggestions.

Yeah, "explosion" is not really a precise scientific term, and could mean both of the above (or none). But anyway, I was trying to point out that the start of the anomaly does not look very "explosive". The first stage remains stably lit and doesn't noticeably change orientation, so it looks like the upper stage didn't lose structural integrity immediately. Perhaps a valve or feed line ruptured and was venting LOX for some time (a few seconds) before the tank really failed, "explosively" this time. Edit: and by the way, it's likely that the final explosions were triggered by the Flight Termination System after the onboard computer(s) determined the rocket had gone past acceptable limits.

Technically, a conflagration is also a spontaneous combustion. The difference between that and an explosion (or, perhaps more precisely, a detonation), is that in a conflagration the "burn front" moves slower than the speed of sound -- in a detonation, it's supersonic. But this is just pointless nomenclature. I do agree that the initial anomaly doesn't look like an explosion. It's almost as if the second stage is venting gas while mantaining structural integrity (after a non-explosive tank failure, perhaps). The first stage seems to remain stable during this time. It's only by the end that we see the second stage exploding, followed shortly after by the first stage doing the same, and then bits and pieces.

Thanks for the summary of the changes, Slashy, it'll come in handy. I just wrote a small python program to read through KSP's config files and generate the corresponding updated engine stats as JavaScript code for the app. That'll make it easier to update in the future. And sorry for the lack of activity regarding the app, folks, work's been consuming. I'll very soon (this weekend?) release the app officially on the forums. All I'm missing is some info tooltips.

According to Emily Lakdawalla, So I'd guess that all science data, which is pretty much most data, is definitely compressed and sent losslessly. It's only when they release images online for the public to view that they might be put in a lossy format.

It looks like the ASDS is ready for Sunday's landing attempt as part of CRS-7 . Say hi to everyone, OCISLY. Edit: higher-resolution version here.

That will look great, MoffKalast. I specially want to see how the KR-2L will look like. Also, are you planning on making the stages separable?

Uhm, yes, you're right. Probably testing the thrusters and other stationkeeping equipment then?

The new East coast ASDS (name, if any, still unknown) left last night to get in position for CRS-7. The barge stalkers enthusiasts at NSF forum couldn't get a pic of it at port, but they did spot it in the distance from the beach.

They just finished painting the bullseye circles and the X in the center of the deck of the Marmac 304 ASDS. It's unclear at this point whether it will be given its predecessor's name (Just Read The Instructions), a new name, or no painted name at all (at least for CRS7). We'll probably find out very soon.

Alright then, I'll post some comments in the Talk page and think about what modifications we could do to make the article clearer. Your pointing out that μ is not defined, for instance, is cause enough for an edit.

I'm glad the discussion was of help to you . It's quite common to forget the "obvious" assumptions people make when they're talking within a very specific and agreed-upon context. Now, regarding the Wikipedia article, I think the question of whether we should introduce a clarification still stands. Your points in the talk page are valid, and while they may be clearer now to you, the fact that initially they weren't even after reading the article suggests it is perhaps not as clear as it ought to be. Would you like to discuss a modification here? PM? Directly on the talk page?

The fixed point method will work alright for large eccentricities, it just will converge more slowly. Here, I ran a test for M = 3.0 (it seems values near pi are bad for this method): with e = 0.05, it takes 6 iterations to find E to 7 decimals. With e = 0.95, it takes 264 iterations. If we push it really far, say e = 0.999, it now takes 3997 iterations to find E. ~~~~ But let's not go off-topic. I'm interested in knowing what T.C. has to say about what's been discussed so far.