Meithan

Unless the eccentricity is high (e > 0.8), in which case it seems M = À (pi) is a better choice. Edit: after checking I think this applies to Newton's method, not to this fixed-point method. For high eccentricities, Newton's method will converge much faster, it seems. Still, a few hundred iterations is peanuts to any modern computer.

Yes, five of the six orbital elements (a,e,i,Ω,É) are completely "time-agnostic", as rkman put it: they contain only geometric information on the size, shape and orientation of the orbit. But the sixth element, the mean anomaly at epoch, does contain a piece of time information. However, it's not enough to make predictions: as ZetaX says, these six elements only determine the motion "up to temporal scaling". In order to determine this "scaling", you need one additional piece of time-related information: it can be the period (inferred from the mass of the central body in a central force problem, or the masses of the two bodies in the more general two-body problem), or the speed (the magnitude of velocity) at any point along the orbit. So I guess my answer to you, T.C., would be: you're right, there's an implicit extra quantity apart from the six orbital elements that's required to make predictions. Typically, this is the mass (or gravitational parameter) of the central body, which is a quantity so important in orbital dynamics that I guess it's generally assumed to be known. The "Orbit prediction" section of the article includes an explicit formula of the mean motion n where the dependence on knowing the gravitational parameter of the system is shown; I do agree that there is no explicit and clear mention of this dependence. Let's discuss it some more, and if all becomes clear and we still feel the Wikipedia article needs to be amended to clarify something, I'd encourage you to do it (or I can do it myself).

Remember that the force of gravity depends only on the distance between the two bodies (it doesn't depend, for instance, on their velocity). That means that if you know, for example, the exact 3D position of a body relative to the Sun (and it's assumed you know the Sun's mass or its gravitational parameter), then the force is implicitly known too. You'd need the mass of the body too to calculate the force, but as peadar1987 pointed out what matters to determine the motion is the acceleration (the force is just an intermediate calculation, if you will, to obtain the acceleration), and gravitational acceleration is independent of the mass of the body. So you could say that the orbital elements contain in themselves the information that determines the acceleration of the body at any point in time (since all you need is know where it is relative to the other body). This is not an accident: the elements were actually derived using the fact that we can compute the acceleration just by knowing the position of a body. Also note that if you already know the six orbital elements, you don't need to compute the force or the acceleration anymore to make predictions! The orbital elements are already a solution to the equations that dictate how a body moves knowing its acceleration. So once you have the orbital elements you can forget about force or acceleration altogether: predicting where a body will be or was at any point in time is a matter of geometry.

If all you need is to make sure you can take off from Tylo, why not simply compute the Tylo-relative TWR? Tylo's surface gravity is 7.85 m/s². If you need to know if you have enough propellant to reach orbit, compute your ship's delta-v. Low Tylo orbit requires about 2300 m/s. You can just use your engines' listed vacuum values for thrust and Isp.

Thanks a lot for the link to the press conference, Streetwind, I enjoyed it greatly. The opening summary by Mark McCraughean (the first speaker) was inspiring and the rest of the presentations were extremely interesting and enlightening. It also settles most of the questions regarding what kind of orbits Rosetta has been flying since last year. (On a very innocent sidenote that has no intention to spark debate, it was nice to see two women out of five speaking in that team. The world has to encourage more women to go into STEM, and I think this is a great example to follow.)

Yeah, it does the same thing on my computer. Apologies for not mentioning it. I had to focus on 67P instead, and Rosetta is there.

Alright, take two: http://meithan.x10.mx/KSP/engines/ After trying several options I found that the simplest was the best: simply have the document, instead of the chart/canvas, catch the MouseUp event. Pan or zoom selection can only be started by clicking inside the chart area, but the mouse can then wander outside it while holding the button and releasing it anywhere will trigger the pan/zoom. It seems to be working on my end. What do you think?

Just installed Eyes on the Solar System and spent 30 minutes following the trajectory of Rosetta around 67P. Amazing! Thanks for the link!

Ok, here's the story of the orbits as far as I've been able to determine. Earlier in the year they transitioned from close "stable" orbits to flyby orbits to get closer looks at parts of the nucleus: http://www.esa.int/spaceinvideos/Videos/2015/02/Rosetta_s_close_flyby Now, since 67P is getting closer to perihelion (which will happen on August 3 of this year), its activity is increasing. This means that during these close flybys Rosetta was flying into increasingly denser environments of dust and comet emission. This was measured as larger drag being applied to the orbiter as early as February 17. During the March 28 flyby of the nucleus, dust and emission from the nucleus confused Rosetta's star trackers which are used to accurately determine its attitude (when that fails, it falls back to gyros, but they seem to build up error over time). The result of this issue with the star trackers was that Rosetta entered a safe mode. It took mission controllers two days to restore it to normal operating conditions. As a result of this safe mode, Rosetta was left in a hyperbolic trajectory that reached 400 km from the nucleus. Then, they executed a series of maneuvers starting on April 1st to bring it back to about a 140 km orbit by April 8. Since then, they've been much more cautious about getting close to the nucleus and Rosetta has been executing "pyramid orbits" (legs of nearly-straight hyperbolic trajectories forming triangles) since. To get a sense of scale, each of these legs takes about one week to complete, so one full "pyramid orbit" takes about three weeks. After contact with Philae was reestablished on June 13 (with a second, briefer contact on June 14), ESA planners have been planning further orbit changes to maximize the chances of communication with Philae. So far contact with Philae has not reoccurred, and the initial contacts were weak, so the first priority if Philae is to resume operations is to strengthen its link with the orbiter, and thus Earth. Rosetta is currently about 230 km from the nucleus on one of these hyperbolic legs. It seems they'll bring down Rosetta below 200 km, which was the altitude on which Philae was first contacted.

From an old post in Rosetta's blog: And here's the technical specs page for the thrusters. To get a sense of size, that nozzle's diameter is only 35 mm (1.38 inches)! Edit: 40 N applied to 2000 kg of mass gives an acceleration of 2 cm/s^2.

You're right, the onMouseLeave event is disabled. Working on it. I think I can make it execute the last action on canvas leave (catching the event on the html document instead of the canvas object).

Yeah, it seems if the mouse is moving too fast it doesn't catch the canvas exit event (since there's nothing outside the canvas to register it). I can work it out. What should the expected behavior be in your opinion? Cancel the current pan when the mouse exits the chart area instead of the canvas? Should the current pan be executed instead of cancelled?

Alright, people, it's here! http://meithan.x10.mx/KSP/engines/ Changelist: New toolbar Shrink or expand the payload or dv ranges (separately) with the zoom buttons (got rid of the old on-chart buttons). Recall previous views with the arrows (only remembers payload/dv ranges for now; might consider remembering all settings). [*]New chart interactivity Click-and-drag to pan the view! It will limit the pan to prevent negative values. Alternatively, hold the control key while click-and-dragging to draw a zoom box, as before. Click on the chart to freeze the details panel on that point; click again to unfreeze. [*]Performance upgrade: I optimized the calculation, it should run 2x-3x faster than before. [*]Changed how the Dawn is handled: instead of two engines (one with, one without the panel mass), it's now a modifier on the engine. I hope you like it, and I'll be waiting for your bug reports. The panning was kinda acting weird at times, and I'm not sure I've completely fixed it. Any suggestions to improve intuitiveness of the controls are greatly appreciated (for instance: do you think the behavior of the +/- signs is intuitive, or are they backwards?) I think I'm happy with the current set of features and would say the app is ready for release feature-wise (pending more testing to iron out bugs). The only thing left to do is adding some tooltips/instructions/help.

Hey guys, sorry for being absent, work has been absorbing. I've been progressing with the app and it's almost ready for the next revision. I think you'll be pleased with the changes . Hopefully I'll be able to finish the remaining details and post an update during the weekend. I'm realizing the JS JIT compilers are indeed pretty fast. The JavaScript port of the calculation definitely outperforms the original Python implementation (granted, that's not saying too much since Python isn't fast by any measure, but it's still an interesting observation). Uploading the code to GitHub so other people can work on it is a great idea. I'll find you on reddit.

I had been thinking about magnets too, but now that skykooler mentions it, velcro might be a better idea. It's maybe not as clean as magnets or twist-locking, but it'll work. Four smallish strong velcro patches 90° apart should hold the pieces together even when twisted.

So you'd get rid of the zoom buttons? A "go back" button is completely doable. It could even remember all settings since the last time the ranges were manually set (or, heck, even since page load -- it's just remembering four numbers per view). For the click-and-drag panning I'm thinking something similar to what alexmoon did in his Launch Window Planner. Take a look (much of my UI was inspired by his). It's not trivial to implement, but I think I can pull it off. Of course, this would mean getting rid of the selection-box zooming. What do others feel about this zoom functionality? What method do you prefer? Freezing the details is a great idea. I could rig the right-click to "unfreeze" the details. A crosshair on the chart would indicate what point is currently "frozen in", and right-clicking would let go of that selection. LittleBlueGaming's idea of only freezing one of the details panels is also good, but I'm not sure about some of the aspects of this. I like the idea of being able to see both the optimal and runner-up engines because it quickly gives you an idea of how close the top solutions are to each other. And unselecting an engine to see the other solutions requires recomputation of the whole chart, so I'd rather this be a sort of "last-resort" channel to get the information you want. But I'm thinking of ways to make this idea (freeze only one panel) work. Great catch, Teilnehmer! Must've missed that checkbox id when I changed the names of the engines. It's fixed now. Thanks, Starhawk! tavert (the author of the original charts posted before 1.0) still feels that what I'm doing isn't valid for the very low mass payloads, due to tanks being discrete in reality, but I still feel the tool is generally useful in giving an idea of which engine is likely to be optimal for a (payload,dv) combination. I'll add a disclaimer about this to the final version. I've also been discussing with him the possibility of porting his original code to JavaScript and using it instead of mine to drive the calculations behind the webapp. My main concern with this is speed: at some point his code does a bit of trial-and-error exploration, and that could take some time. We'd have to find ways to optimize it.

OK people, I just uploaded the latest updated version: http://meithan.x10.mx/KSP/engines/ I haven't tested it much so please do try it out and report any errors / weird behavior. Changelog: Zoom capability: (1) you can click and drag to draw a selection box, and the chart will be recalculated for that region (2) you can also click the + and - zoom buttons in the chart's corner, which will widen or shrink the ranges by 2x [*] Expanded details area on chart mouseover, showing some provisional details for each of the solutions. [*] "Full" engine names (and got rid of "show old names" checkox) [*] Added a version of the "Dawn" engines with 100 kg of "solar panel mass". What do you think? I've considered changing the click-and-drag behaviour to instead let the user pan the chart, and reserve zoom for the buttons. Also: what details of those currently shown do you think are useful? Which would you eliminate? What other details could be displayed there? The buttons are lacking some form of feedback when you "click" them, but I'm working on it. The burntimes shown assume starting the burn with the tanks full, when acceleration is smallest. I'm thinking that with some more polishing this is could be mature enough for release. Additional big features like selecting which variables are plotted or total masss line plots could then be added post-release.

Dammit, Steve.

A TWR of 1 basically means the acceleration produced by the engines is equal to 1 g, or about 9.8 m/s². You can thus think of TWR as a measure of the acceleration that the engines can impart on the ship. The standard reference for g is Kerbin's surface gravity of course, which is what is implied when we just say "the TWR is 2". But it's also possible to re-define TWR relative to the gravity on any other body. Thus, an "Eve-relative TWR of 2" means an acceleration of twice the gravitational acceleration on Eve's surface, which is 16.7 m/s². Since "minimum TWR" is basically equivalent to "minimum acceleration", you can use this information to compute approximate burn times. Say I have a ship with a (Kerbin-relative) TWR of 2.0. That means the engines can yield an acceleration of about 2 * 9.8 m/s² = 19.6 m/s². How long will a 1000 m/s burn take? If the acceleration remained constant, then you could use the formula burn_time = delta-v / acceleration, which would yield burn_time = (1000 m/s) / (19.6 m/s²) = 51 seconds On the other hand, the LV-N is too heavy to efficiently provide large TWRs. Say I have an LV-N based ship with a TWR of 0.3. Then the burn time for the same 1000 m/s maneuver would be: burn_time = (1000 m/s) / (0.3*9.8 m/s²) = (1000 m/s) / (2.94 m/s²) = 340 seconds = 5 minutes 40 seconds Note that these are approximations only because the acceleration is not constant: as you burn fuel, your mass diminishes but the engines still produce the same thrust, so the acceleration will increase. The real burn times will actually be lower than this, but it's a simple way to get an idea. Edit: ninja'd by Concentric . By the way, I will add burn time data to the "details" panel.

Sure thing, I'm just worried about fitting some of the longer names. Let me try to squeeze things together. Makes sense. But I wonder why is the atmospheric performance so different? One of the charts in the OP did include the Dawn engine with the weight of panels included (I simply added 100 kg; it's the one named ION-SPs). Back then I decided not the include the Dawn in the analysis because the electrical demand issue is complex enough (there are now three ways to deal with it: panels, RTG, fuel cells) that it deserves its own separate analysis. However, I can add this solar-panels-at-Kerbin version of the Dawn for now. - - - Updated - - - Yes, the original charts limit the number of engines to 50 (in the webapp I'm developing, the limits is configurable). And yes, I'm considering the dry mass of the tanks in the calculations. This imposes another restriction on the maximum ÃŽâ€v of a ship (the first one being the TWR of the engines, if a TWR restriction is imposed on the ship).

I quite agree: when the basic paradigm is the same it's just a matter of picking up the new syntax. Thanks for the link to juliabox, I'll toy around with it. Yes, that's the obvious place to optimize. It's currently done in this inefficient way because the code comes from a Python program that was initially used to compute total mass for single combination of parameters, and I simply adapted the plotting routines to it. It'll be interesting to see how much performance is gained by this change (I don't have much experience with JavaScript so I don't know how smart the JIT compiler optimization is).

In vacuum, the LV-1R "Spider" is never optimal because the LV-1 "Ant" is always better (they have the same mass and thrust, but the Ant has a slightly better Isp). However, once you go inside an atmosphere the roles are quickly reversed. For some reason the Ant's atmospheric Isp is terrible while the Spider's is not. ~~~~~ Webapp update: http://meithan.x10.mx/KSP/engines/ Changelog: Added the KR-1x2 "Twin Boar" (I'm adding it as a 6 tonnes, 2000 kN "normal" engine; thanks to the infinitely divisible fuel/tank mass approximation, the fuel and tank it carries can simply be lumped into the ship's totals). The new nicknames of the engines are now shown by default, bit I've added an extra option to use the old names. Moved the mouseover info box to the right of the chart and started styling it. I'm working on the click-and-drag zoom capability, but it's not complete yet.

Well 500x500 seemed like a good target point, and I like the results so far. I've also added a low-resolution (200x200) option for slower computers (the map gets scaled to 500x500 to fit the same space). Interactvitiy means that the chart itself doesn't have to be that precise or information-rich (which is part of the reason I decided to use linear scale for the axes; there's no point squeezing the full conceivable payload range in one graph if the user can simply key in the specific range he wants). What could be done at some point down the road is port your Julia code to JavaScript and use it on my webapp. The user interface and plotting routines are what's consumed the majority of development time anyway; the actual computation is straightforward enough. But I've never laid down my eyes on a line of Julia, so I guess that'll have to wait (good learning opportunity, though; I've heard high praise from Julia). Right now I'm directing my efforts towards polishing the web interface and adding extra functionality. Some enthusiastic users have been recommending some interesting things and I do intend to indulge them wherever possible.

Agreed, but then wouldn't the difference between the computed optimal masses be on the order of the discretization error? That means that even if my program does not find the actual optimal solution, it can find a solution within a small margin of the optimal one. That's good enough for me, and I could add a disclaimer to warn about this. The webapp is not meant to be a full solution of the design problem anyway. If you're looking for that, I'm sure you've seen GaryCourt's Optimal Rocket Calculator. The engine charts are meant to be provide approximate guidelines of the regions where a specific engine might be a good choice. I still want to leave the player the fun of designing the ship. I'm not sure I fully understand the procedure you describe, but I wanted to avoid exploratory solutions due to computation time concerns. I want the app to be running on JavaScript on the user's browser. Currently I'm simply evaluating a couple of formulas for a 500x500 (payload,delta-v) grid of points, and it already takes on the order of 500 ms. I do admit however that my current implementation is slow because I'm repeating the costly (I presume) exponential function. As a point of reference, how long did your original engine charts take to generate?

Yep, there's a cute almost-conscious feeling to that behavior: <observe something> "You have to see what I just saw, guys!" <turns towards Earth and transmits>