tavert

Members
  • Content Count

    1,006
  • Joined

  • Last visited

Community Reputation

107 Excellent

About tavert

  • Rank
    Rocket Scientist

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  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.