Jump to content

tavert

Members
  • Posts

    1,006
  • Joined

  • Last visited

Everything posted by tavert

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. You need to fix that. Otherwise your results are flat-out wrong for small craft.
  6. 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.
  7. Max thrust changes with atmospheric pressure now, right? Is it a linear relationship, or are people still testing and working that out?
  8. Not exactly a closed-form equation, but if the initial and final altitudes are the same and you want to stay at exactly zero vertical velocity through the entire burn, you can use the same differential equation just with custom initial and final horizontal velocities instead of the specific values I used here (which were based on orbital / rotation speeds).
  9. 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.
  10. 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.
  11. @taio in case it's helpful, here's a dumb cfg file parser in 30 lines of Julia code that I wrote a while ago: http://www.reddit.com/r/KerbalSpaceProgram/comments/23nxde/mass_optimal_engine_charts_updated_for_0235/ch0teog Consider that released under the same BSD license. Someone on reddit did some work to put in RCS engines and automatically put the thumbnail engine pictures into the legend, they contacted me via PM on reddit a while back and their modifications to the code are on github, but I don't think they finished them. There were also some bugs in the way they did fuel-tank combinations, they tried to dynamically compute the list of combinations based on stats but were doing it incorrectly. - - - Updated - - - Also to taio and John FX, it would be nice if you could keep track of and collaborate on your updates/modifications to the code via a github repository. Easier to review and spot anything that might be incorrect that way. - - - Updated - - - That should be pretty easy. Just scale the right hand side of any line that says "thrustk = ..." by whatever function of "atmpressure" ends up being used in-game.
  12. Hiya numerobis, been a while. Shouldn't be too hard, you probably don't need the fancy variable-step integrators that Mathematica uses here. Simple RK might work well enough with small steps. Interesting thing to play with here is the variable transformation of whether you want to integrate velocity as a function of time, or the other way around.
  13. The difference is down to the sidereal rotation velocity at the surface. You're right that a hypothetical orbit at 0 altitude around the Mun has orbital velocity of 570.7 m/s, whereas around Eeloo it is 595.3 m/s. But Mun's sidereal rotation period is (or was, as of 0.18.2, I don't know whether it's changed since then?) nearly 140,000 seconds, which only contributes 9 m/s to a prograde equatorial launch. Eeloo's rotation period is 19,460 seconds, which contributes 67.8 m/s to a prograde equatorial launch. So if you land from or take off into an equatorial orbit to take full advantage of the surface rotation, overall Eeloo will take less delta-V to land or take off than on the Mun. You can come in at whatever altitude you feel safe, then for the final part of the descent try to maintain a shallow descent while at low speed (still mostly horizontal, but dropping you below whatever safety margin you kept for terrain). You can calculate out the total angular distance that it takes to do this style of landing and predict fairly accurately where you'll land, in terms of longitude difference between when you start your landing burn and the final point of landing.
  14. Sorry about my lack of responsiveness here, I no longer play KSP and it's been a while since I last checked the forums. I added a BSD license to the code. Go nuts.
  15. Slight bump, but interesting thread that could use some additional clarification. Remember that engines aren't free, in mass or cost. In reality engine cost is much much larger than fuel cost, and terminal velocity is very high for rocket-shaped objects. Mass and cost don't technically matter in KSP yet unless you enjoy optimizing things, but that's a separate issue. In KSP, what are you optimizing for? If it's fuel per unit altitude for a fixed design, then you want to get as close to terminal velocity as you can for a vertical ascent (low atmosphere). But your design isn't fixed, is it? If your TWR exceeds 2.2 or so (TWR of exactly 2 only maintains terminal velocity if the atmospheric density remains constant - since terminal velocity goes up as you ascend, you actually need a TWR of 2.1-2.3 to keep up with the acceleration), then you're throttling down to stay at terminal velocity, which means you're carrying engine mass that you aren't using, and burning fuel to lift that useless engine mass. You could've saved engine mass and used less total fuel by having fewer engines to start with, even if that drops your TWR a bit lower than required to maintain terminal velocity. Search the challenges section for the payload fraction challenge, and see what the designs there look like. They have lots of asparagus stages so TWR stays roughly constant, and start out each stage a fair bit lower than TWR of 2.
  16. I'm not really playing lately so I'm not sure whether or not this is still the case, but last I checked you can't trust the dV numbers from MJ or KER in the VAB, you have to go into the flight scene from them to properly take into account massless parts. In the VAB MJ will (or used to?) think that the aircraft landing gear are 0.5 tons a piece, but in flight they have no mass. Using them instead of landing legs is considered a little bit exploitative by some people for this reason, but it would be a very minor change to just use conventional legs on decouplers and the ascent vehicle would perform the same.
  17. Haven't played KSP for months, but couldn't resist this one. I had this design put together on new year's but don't think I ever actually flew the entire mission. Had to add landing gear and parachutes, then it was good to go. 19.755 tons on landing, 19.228 tons at takeoff after burning a bit of fuel to soften the landing and dropping the chutes. 8762 m/s total dV, used 53 of it to land and had 50 left over once back in orbit. Craft file at https://dl.dropboxusercontent.com/u/8244638/EvePod%201f.craft
  18. Where's that 5263 number coming from? It's closer to 8 km/s from the highest mountain.
  19. Nope. High orbits are bad for efficiency, you never want to be any higher than you absolutely have to. Target a low periapsis on all encounters, perform all capture, landing, ejection, etc burns at low altitudes. Oberth effect means the higher orbital velocity (kinetic energy) of a low orbit is actually useful, whereas the potential energy of a high orbit isn't good for anything. The only thing that's good to do at high altitudes is inclination changes, but you can easily do those from the apoapsis of a highly eccentric orbit where the periapsis is still at a low altitude.
  20. Just randomly browsing the forums slightly more often the last few days than the few months beforehand. All of these are old calculations, with the exception of the updated engine charts for 0.23.5.
  21. Here, have some data (assuming you're not using FAR)
  22. Delta-V maps are oversimplified for the costs of landing and takeoff. The actual values depend on your craft's TWR, staging, Isp (since that determines how quickly TWR changes), and your landing trajectory. Here is the math for best-case single-stage numbers as function of TWR and Isp http://forum.kerbalspaceprogram.com/threads/39812-Landing-and-Takeoff-Delta-V-vs-TWR-and-specific-impulse
  23. Perform the initial part of your landing burn at the minimum possible safe altitude. Then transition from burning off-retrograde (constant altitude trajectory) to something more like a standard retrograde suicide burn as your speed drops. The very end of the landing trajectory can look the same, you just start (and do most of the near-orbital-speed braking) at a lower altitude. The important part for efficiency is to prevent yourself from losing altitude while you're moving relatively quickly, but slower than orbital speed. You can control vertical speed during landing (by adjusting pitch) to gradually descend however you like, so you'll be close to the ground by the time you counteract the last bit of your horizontal speed.
  24. Alright, since people asked I finished the new version and updated the OP.
  25. Alright, I re-implemented the core calculation (just for the conventional liquid engines so far, didn't put in LFB, SRB, or ions yet) in Julia: https://dl.dropboxusercontent.com/u/8244638/KSP_engine_charts.jl I also haven't done all the boring plot labeling or colormap stuff, but now that it's in an open-source language, if you want the plots updated you can mess with the code yourself (please share any additions). Download and install Julia here http://julialang.org/downloads/ - I use the 0.3.0 prerelease, the older version might work too, not sure. Then do the following (the double-backslashes are required if you're on Windows), with MINTWR and ATMPRESSURE replaced with your desired numbers. cd("C:\\wherever\\you\\put\\the\\code") include("KSP_engine_charts.jl") (bestengine, bestmass) = KSP_engine_charts(MINTWR, ATMPRESSURE); Be patient the very first time it runs, it needs to download a couple of Julia packages. If you tweak anything in the code (like max number of engines, dv or payload limits or resolution, etc), you have to re-include the file before re-running the function since Julia is based on a just-in-time compiler instead of an interpreter.
×
×
  • Create New...