Jump to content

Meithan

Members
  • Posts

    448
  • Joined

  • Last visited

Everything posted by Meithan

  1. 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.
  2. Probably not, since they have low Isp and are usually unsuitable as main stage "engines" (non-throttable, no gimbal, non-expandable fuel load). Remember that these charts are for a single engine type. Combining different types of engines would require a completely different approach, and for that there's tools like the KSP Optimal Rocket Calculator.
  3. I have kept the choices I used for the original charts: normal LFO engines assume the full-to-dry mass ratio of the tanks is 9 (that of all the "conventional" LFO tanks), while the LV-N assumes it's 8 (which is very close to the ratio of all Mk2-Mk3 liquid fuel fuselages). It's set on a per-engine basis.
  4. Yes I can. I just did a few calculations while waiting for the bus and I think the formulas remain valid for the Twin Boar as long as its "effective mass" is computed as (engine itself + integrated tank - fuel/alpha). I'll check my algebra again when I get home and if it's correct then I'll add the Twin Boar to the app.
  5. You guys probably know this, but it's important for people to realize that the main difficulty with a mission to Pluto is not really the ÃŽâ€v: a Hohmann transfer to Pluto (taking its average distance to the Sun) is about as expensive as a transfer to Saturn (15.5 km/s). The spacecraft construction and launch costs are thus comparable to those of the Cassini-Huygens mission to Saturn. The problem is time. A Hohmann transfer to Pluto takes about 45 years. On the one hand we don't know if a spacecraft can remain operational for that long (the Voyagers are about to hit 40, and that's way more than anybody expected at the time; the Pioneers weren't so lucky). On the other hand, it's also a social problem due to human timescales. By the time the craft reached its destination most of the project leads would be retired or even dead. It would require multi-generational planning, logistics and funding. The ÃŽâ€v becomes a problem only because the transit time is a big problem in the first place.
  6. 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.
  7. What I can do to keep the interface from getting even more complex is leave it with TWR as it is and display acceleration in the "Details" tooltip. I could then include min/max accel, average accel, and maybe even burn times for some delta-v values (100, 200, 500, 1000, perhaps?) there. How's that sound, Teilnehmer. Now, I'm no longer sure that the "total mass" line plots (see OP) are still a desirable feature, since the tooltip is already providing extra info for specific chart points. What do you guys think? Is it still worth it? If not, or if it's not an important feature to have right now, I'll work next on zooming capabilities for the main chart.
  8. Thanks for all your useful suggestions, Teilnhemer! This is effectively done by hitting the "Load defaults" button. Do you think it needs to be made clearer? I've thought about adding a popup or overlay with instructions on how to use the webapp (specially now that it's getting more and more complicated). I'm on the other side of the fence here: I'm still not used to the new "nicknames", so I find it easier to read LV-T30 than "Terrier" (or whatever it is ... *checks* See? I still don't get it right ). But I think I'm gonna follow your suggestion. It's gonne be both easier for new people to read and for old players like me to learn the nicknames if they are default. To please everyone, I'll throw in an optional checkbox to display the old names. Will add on next iteration. I think it's clearer if the legend only displays the engines that do appear in the chart, as opposed to all engines. Plus I like having the engine list right next to the chart, so it's easier to compare colors. What I have been considering is letting the user change the color of the engines, using something like http://www.jqueryrain.com/?W6V5HIOt/. That way the user could change the colors of shown engines that are hard to distinguish. This is something I've been considering too. As you say, for vacuum applications the acceleration is a more useful quantity (since, for instance, it lets you estimate a burn duration). However, for surface applications (e.g. taking off from Tylo) the TWR is a more natural parameter. So it's hard to say which should be shown. What do others think? ~~~~~ Alright guys, the next beta version is up. http://meithan.x10.mx/KSP/engines/ New features: Atmospheric pressure now settable, with recalculation of engine Isp and thrust. The reference body for the TWR is changeable (so you can now quickly do a chart useful for, e.g., Duna liftoff). Max number of engines is configurable, with "unlimited" option. Have a go at it, and tell me what you think / report any bugs.
  9. Yup, exactly those. At some point I was considering also adding a few extra Eve presets for say, 2, 5 and 10 km ASL, but with the changes in the atmosphere model in 1.0 I don't know how to readily calculate pressure for a given altitude. I'll have to look into OhioBob's investigations of the new model (which is based on the International Standard Atmosphere, a model with which I'm a bit familiar a floatCurve?). - - - Updated - - - The other engine is the LV-N, by the way, with an Isp of 800 s. But yes, the reason is its low mass: the LV-1 weighs a whopping 150 times less than the LV-N. For light payloads and/or very small ÃŽâ€v, the small mass of the LV-1 will kill the superior Isp of the LV-N. Imagine that your payload is 1t: if you use the LV-N, you'll be adding 3 tonnes for the engine alone!
  10. That's a great idea, Teilnehmer, I can see how these other variable combinations could be useful. I'll leave it for after this version is fully working because I'd have to redo some of the math and change the user interface, but I it's totally doable. This, setting the limit on the number of engines, and atmospheric pressure calculations are already implemented in my working version (sneak peek below); I'll upload it to the website as soon as I test it a little bit more .
  11. Yep, it's going to be much better than these static images. I'm working on the atmospheric calculations as we speak.
  12. Great to hear that . Your eyesight is fine, it's not implemented in the webapp yet. I'll do it soon.
  13. Alright, it should be fixed. Tell me if it works for you on Safari. It's my pleasure! Really, I'm learning a lot doing this.
  14. Ah, it seems Safari doesn't support what I'm using in the script to measure execution time (performance.now()). It's an easy fix (either use Date.now() instead, since I don't really need microsecond resolution, or simply disable the timing report for Safari). I'll get to it when I get back.
  15. Fantastic. I'm a little busy right now but I'll get to those remaining features soon. When I feel it's ready enough, I'll release the webapp in the Tools and Applications section of the Add-ons forum (and post a link in this thread and update the OP). Note that there already exist some tools that provide similar functionality to what I'm doing: An engine comparsion based on cfg file parsing (python) Python script that, given dv and TWR requirements, computes the payload fraction for all the engines (under either vacuum or 1 atm conditions). However, the calculation assumes only one engine, and so not all solutions are found. The Online engine cluster calculator is used "to work out an engine cluster layout for a center stack and attached booster stacks required for liftoff", where the booster stacks as asparagus-staged. It's nice but provides a different kind of funcionality. It hasn't been updated to 1.0, though. Finally, there's the KSP Optimal Rocket Calculator, which is a brilliant web tool that actually builds the rocket "on paper" by searching through many part combinations and finding that which optimizes mass (or cost or part count). The search is multi-stage, so it'll yield actual practical solutions. While this completely solves the optimal design problem, I feel my tool is still useful in giving a general impression (and does so graphically) of the regions where each engine is optimal or close to optimal, without fully designing the rocket for the player. It's more of a guideline tool than one that solves the problem for you. - - - Updated - - - It seems to be a Safari issue then (it seems to work on Mac using Chrome). Could you show me the output of the JavaScript console? It seems that option-command-C opens it; see here. Let's start with that. If the script runs, it'll output something like this: 0 20 0 5000 0.5 Array[18] Initializations: 3.670999998576008 ms Tick calculation: 29.225999998743646 ms Chart computation: 576.4839999901596 ms Image loading and scaling: 17.947000000276603 ms SCRIPT DONE
  16. Yes, it's not doing any input checks at the moment, and will simply produce NaNs and show a blank chart if data is missing. Checks and an alert on missing data added to todo list. You can also hit "Load defaults" to set the payload range to 0-20 t and the dv range to 0-5000 m/s, with a min TWR of 0.5.
  17. Faster than mine. So the chart never appears?
  18. Minutes? The chart is computed in about 600 miliseconds on my computer. What are the specs of your computer? OS, browser?
  19. UPDATE: I just finished the core functionality of the webapp for engine charts (no total mass plots yet). Try it out and tell me what you guys think (bug reports appreciated!): http://meithan.x10.mx/KSP/engines/ Mouse over the chart to see details about that location (below the chart). Currently shows the best and runner-up engines, indicating how many engines are required and the total mass of the ship for each case. Note that this recalculates the mass comparisons for that point, so if you're plotting the low-resolution chart you'll still get high-resolution results here. Since it's doing the computation for all engines now it's a bit slower than previously. Still, it's under a second for me, which I think is not too bad. To do: Improve how the values for a (payload,dv) pair are shown on mouseover (mouse-following tooltip on top of chart, maybe?) Zoom in/out buttons Click-and-drag zoom in directly on chart Show more detailed info for a (payload,dv) pair, e.g., total mass breakdown (how much is payload, fuel, tanks, engines) Total mass plots (when clicking on chart) Optimize computation
  20. Wow, thanks for posting this video, I loved it. It's cool to see how the instruments are programmed to be looking at different targets during the flyby.
  21. Similar to what I as thinking: a small tooltip when hovering over the chart showing, say, the top 3 engines for that point and the total masses they yield (sometimes the runner-ups are very close, and may be more practical than the top engine). Then, on clicking on the chart, a second line plot would be generated with the full total mass vs. dv curves for the payload of the clicked point. I also want to display the mass breakdown (how much is payload, tanks, propellant and engines) for a given solution somewhere.
  22. Glad to hear about the speed . I can probably make the calculation faster by saving intermediate results, but if it's fast enough for most users then I'll give low priority to this. Just added a link to save the generated image as a PNG. I have some ideas for interactivity features, just you wait .
  23. If you plotted the engine charts with a single engine, it would all be one color (or one color and white), which wouldn't be interesting. Perhaps you want to look at the total mass plots, where instead of just telling you which engine is better for any (payload,dv) pair, more detail is given about just how good or bad each engine is in providing dv for a given payload. In those plots you can follow the line for a specifc engine and see how heavy the spacecraft would be to yield a specific dv, and then compare that to the other engines. Don't know if this clarifies things a bit. Also, I agree that there's probably too much information in these charts to be represented clearly. I'm working on a webapp (see below) that computes these charts on the fly with user-customizable parameters, and I'm thinking of several ways to interactively extract information from the analysis. Oh, then yes, it's totally doable. In fact, a single-stage ship that departs from low Kerbin orbit, lands on Duna, and returns to Kerbin is probably doable. The LV-N is probably the optimal engine for such a ship. ~~~~~ Alright guys, I wanted to give you a very quick sneak peek of the webapp I'm working on. A word of warning though: this is a very much work in progress at this point. The engine selection is not yet implemented (it's fixed to the LV-N, LV-909 and Mainsail, and there's no color key so you'll have to guess ), and many things can go wrong. But at least the core calculation and part of the UI is done: http://meithan.x10.mx/KSP/engines/ Whad'ya all think? How fast/slow is it? Does it look good?
  24. Thanks a bunch, this is exactly what I needed! There was a typo in my middle tangent calculation (a 2 instead of a 5 ... man, my dyslexia strikes again). Here's the output now: tangents: [-20, -33.33325000000001, -46.666500000000006] 0.4463469 292.543744091 3.856129 157.169858986 and here's the resulting curve: Looks "smooth" now . Thanks!
  25. Ah yes, I see what you mean. I'll include it in the set of engines for the webapp I'm making. Yes, what the charts say is that what you're asking is pretty much impossible. You can't build a single-stage ship that has a TWR of at least 1 (which is the absolute minimum you'll need to get off Kerbin's surface) and 13,800 m/s dv. Nope. However, as 5thHorseman's pointed out, those dv figurs are a tad overestimated. Going to worlds with atmospheres means you can save a lot of fuel by aerobraking (and if you're landing there, the saving is mandatory, so to speak: the atmosphere will slow you down). Landing on Kerbin is close to free when coming from an interplanetary trajectory, so skip the capture and low orbit circularization dv. Still, if you want the single-stage ship to launch from Kerbin's surface, it's a lot of delta-v. So let's assume you can get to orbit with 3500 m/s (I haven't been able to hit these values in 1.0 yet, but I'm far down the tech tree), then an aerobraking-assisted 1200 m/s Duna transfer. I have no idea how effective parachutes are in Duna in 1.0, but you won't need anywhere near 1300 m/s to land. Let's say you spend 500 m/s in a little propulsive assist. You will, however, need around 1300 m/s to takeoff. Ater that, you can do the transfer back to Kerbin's SOI probably on 800 m/s if you catch good windows, and then just aerocapture at Kerbin and land with almost zero fuel expenditure. The total cost (ballpark) would be around 3500 (LKO) + 1200 (Duna transfer) + 500 (landing) + 1300 (takeoff) + 800 (Kerbin transfer) = 7300 m/s. That's also impossible, since you require TWR > 1 for Kerbin takeoff. So yes, no single-stage ship can pull this off (and there's a "good" challenge for anyone willing to try -- but they'll all fail). If you relax the single-stage from Kerbin surface requirement, and instead assume you start in low Kerbin orbit (so you're allowed to use an expendable launcher that won't travel to Duna), then the total cost is about 3800 m/s. Duna liftoff requires Kerbin-relative TWR of 0.3, but let's multiply that by 2 so the Duna-relative TWR is at least 2. The 0.6 TWR chart says this is totally doable, and that the optimal engine is the LV-N. Not sure what you mean by this.
×
×
  • Create New...