Mattasmack

This has been my experience in hard mode as well, so far. It's great! There's some struggle now rather than just 'how fast can I unlock the whole tech tree?'. I haven't had to restart yet, but I've stranded Jeb in orbit on an attempted rescue mission, and can't rescue him because he can't EVA yet... I'll probably have to do a Mun or Minmus landing to raise funds for that, but one or two failed missions will bankrupt me and I don't have patched conics or maneuver nodes yet...

Ah, yeah, that would do it. Because the context of this thread is GregoxMun asking about analytic solutions to a restricted three-body problem.

It may be that the planar case was considered there for simplicity, but I've seen it mentioned in multiple places as a restriction so I felt safe in claiming that. But this is getting outside of my experience, so I would not be terribly surprised to be shown to be wrong.

On-rails timewarping as you describe it requires an analytic solution for the three-body problem. In general the gravitational three-body problem has no analytic solution. The only three-body systems that do have analytic solutions have very particular restrictions. For example, in addition to the third body having negligible mass, there are analytical solutions if the two massive bodies move around each other in circular orbits and all motion is restricted to the plane of that orbit. In more general cases, no. The motion is usually chaotic; there is no recursion time. Also, regarding restricted N-body simulations of the Kerbal solar system, yes, they can run at 1,000,000x time warp and faster. In the context of KSP the game (i.e., the simulation only need run for ~100 years rather than geologic time periods and only need be accurate enough to produce reasonable-looking behavior in the game), it is even easy.

I didn't know about that workaround! I'll give it a try next time I play. Thanks for pointing it out!

Oh dear, the radial decoupler bug is still there. I wish I had checked that before starting a hard career mode; I just assumed it would be fixed.

I'm playing a stock, "hard mode" (no quicksaves, reverts, or reincarnation) career mode game, and I accidentally accepted a "Plant flag on Eve" contract. I haven't failed or cancelled a contract yet, so I'm determined to get this one. But since killed Kerbals don't come back, the Eve lander has to successfully land and return to orbit unmanned before I'll put a Kerbal on it. Here are the prototypes, all of which except the last one Did Not Go (back) To Space Today. (Edit) Actually, here's the album showing the actual mission as well. Even though it did successfully Go To Space Today, twice, the final result fits the theme of this thread.

I'll admit, I wrote that last message without actually looking for numbers. Looks like you're right. Using the numbers from http://www.spaceflight101.com/falcon-9-v11.html, for a light payload like this one the second stage would have to throttle down significantly to keep the acceleration reasonable (under 5g's, say) if they run the tanks close to dry, where it wouldn't be necessary for a heavy payload. On the other hand, there's enough extra deltaV in the second stage for a light payload that if they start with a full load of propellants, it should finish its burn before running close to dry. I thought the first stage burn was shorter on this flight (MECO around 2:43, where SpaceX's website says the first stage burn is 180s), but looking back at a couple of previous flights on Youtube it looks like that's the normal MECO time as well. So, never mind!

It was also a very light payload for the rocket -- around 1000 kg, when it is capable of lifting over ten times that amount to orbit. So they certainly had some leeway to take a less-than-ideal trajectory. (I am curious about how they handle such light payloads. Do they have to add ballast? Do they launch with less than a full fuel load, or does any unneeded fuel act as ballast? Do they have to throttle down more than usual to stay within acceleration limits?)

Sure, and the reentering capsule sure doesn't have a problem with starting near the ground. But how well do you think something shaped like a capsule with stubby little rotors will autorotate? My guess is, not very well. I agree about putting rockets on the rotor tips for power. Its the most sensible way of powering the rotors, since it doesn't require counteracting any significant torque on the capsule body. (And I said so too a page or two back.) The high-inertia rotors were a concept for easing the transition to autorotation; if you're powering the rotors for landing there's no particular need for extra mass there. I don't know if there's otherwise any advantage to holding the fuel in the rotors rather than elsewhere. And now we're getting back to a Soyuz. It descends passively (unpowered) under parachutes, but its descent speed is too high for a comfortable landing so it adds rockets to slow it down at the last second. Now you have a system that descends passively under rotors, but needs rockets to slow it down at the last second. Shynung earlier said that an advantage of the rotors is that it gives more control over where the capsule lands ... but how much control there is depends on the glide ratio of the autorotating capsule, and I think that will be lousy. Heck, at one point there was a concept of having a Gemini capsule return under a parasail, and I think that would do better and could be completely unpowered. Hmm, has there ever been a helicopter (or similar vehicle) with telescoping or hinged rotors? I'm not aware of any. I assume it can be done, but it doesn't sound easy. Monopropellant, sure. Roton's test vehicle used hydrogen peroxide tip rockets, and I think Armadillo Aerospace experimented a bit with them as well, though they never got close to putting them on a vehicle.

That image you included comes from the Wikipedia article 'Height-Velocity Diagram'. Try looking at the two external links at the bottom of the article, especially the first one. A helicopter in autorotation is essentially gliding forwards; if its engine quits while hovering (or moving slowly) it needs to be high enough above the ground to have room to 'dive' to gain that forward speed. (The article mentioned an interesting case of an experimental helicopter with weights built into its rotor. The weights give the rotor high enough inertia that the 'dead man's curve' (the shaded portion on the left of that diagram) doesn't exist -- the rotors have enough inertia to keep spinning long enough to let the helicopter land even if the engine quits while flying low and slow. But there are disadvantages to making the rotors heavier, and the helicopter never went into production.) Interestingly, a link from that page discusses the aerodynamics of autorotation (http://www.copters.com/aero/autorotation.html), and it starts with the case of vertical autorotation. So I guess it is possible, after all. But the vertical speed is higher than in the forward autorotation case -- too high -- which is why the 'dead man's curve' exists. For something like an Orion capsule with rotors, the fact that the rotors wouldn't extend much past the body of the capsule itself (i.e. the capsule would block most of the 'driving region' of the rotors) is an additional problem for vertical autorotation.

That proves my point. The reason you need altitude if you lack forward motion, is that you use that altitude to gain the forward motion! Inside the red area on the left you don't have enough height to get up to the autorotation airspeed, and you just fall out of the sky.

Well, the Roton was pretty tall, which helped make room for its rotors. Applying this to something shaped like the Orion or other capsules limits you to much shorter rotors, and their diameter when deployed won't be all that much greater than the diameter of the capsule itself. That will certainly change its behavior. It's an interesting concept, but it might be nonsense -- you (or someone) would need to do some basic high-level analysis to find out. The thing is, that's a different concept from what the OP is talking about. Helicopters also need forward velocity to autorotate and that doesn't go very well with something capsule-shaped. I think a purely vertical autorotation is possible, with the right shape of the rotor blades, but descent might be pretty fast.

But if you put torque on the rotors, either to charge up the energy storage system or to drive the rotors from that system, then you need another system on the vehicle to counteract that torque. Likely that would be rockets, unless you envision a tail rotor popping out of the vehicle as well. Why not just put the rockets on the rotor tips and skip the whole energy storage system? Should be simpler and lighter that way. Can you flesh out your idea with some numbers to get an idea of whether it would make sense? Choose a vehicle as a starting point. How long a rotor blade could fit on it? How fast would they have to spin for their lift to counteract the vehicle's weight? Does that speed make sense from a strength of materials standpoint? How much power would be required to descend at your desired rate? (The power required to decelerate to that descent rate will be at least that high...) How much energy would have to be stored? (Related to how long you want to descend at that rate...) Those numbers would allow you to make a stab at how much each system (rotors, motor, energy storage) must weigh.

Liquids can indeed exist in metastable states where they should be vapor (at thermodynamic equilibrium). I'm more familiar with heating a liquid at constant pressure above its boiling point, but it can also be achieved by dropping pressure at constant temperature. The liquid needs a nucleation site to start the boiling process: a scratch on a solid surface that trapped some atmospheric gasses, a suspended dust particle with gas absorbed on its surface, etc. In the absence of a nucleation site, any bubble embryos that form in the liquid due to fluctuations quickly collapse again due to surface tension -- since the pressure difference across a surface due to surface tension goes as the inverse of the radius of curvature, the pressure difference pulling these nanometer-scale embryos closed is enormous. This situation can persist (again in the absence of nucleation sites) up until the limit of superheat, which can be predicted using an appropriate thermodynamic equation of state (thermodynamic limit of superheat) or kinetics (kinetic limit of superheat). That was a bit to the side of the original question asked, sorry. But it's kind of related an area I used to do research in so I have it on the brain. Metastable liquids and the limits of superheat have been studied experimentally for decades. Usually they're studied by heating liquids at constant pressure; a common apparatus is a column of heavy oil that is heated unevenly so that its temperature rises steadily from bottom to top. Then you can introduce a droplet of a lighter, low-boiling-point liquid at the bottom, and as it rises through the oil it gets hotter and hotter until it reaches its limit of superheat, and goes pop! The beauty of the apparatus is that the droplet doesn't ever touch a solid wall when its superheated, so it doesn't come into contact with any nucleation sites there. (See Blander, Hengstenberg, and Katz's paper in J Phys Chem 1971, for one example. Katz and Blander had a number of papers on the subject.) Anyway, if you have a liquid that isn't anywhere close to its critical temperature (water at room temperature, say), you can reduce its pressure quite a ways before reaching the limit of superheat. In many cases the limit is at a negative pressure; the liquid is in tension. This situation wouldn't last for long, because the liquid will find a nucleation site on the walls of the container. But the situation of liquid in tension has been produced, I believe using acoustic waves (which don't last for very long, and can be arranged to focus on a region in the middle of a container). Finally getting to the original question, talking about the boiling point in this situation doesn't really make sense in the first place! The boiling point is the dividing line between where a fluid at thermodynamic equilibrium will be liquid and where it will be vapor. But the fluid at negative pressure cannot be at thermodynamic equilibrium; while it is liquid it is in a metastable state, and as a vapor it must have a positive pressure. So the concept of boiling point loses its meaning. Or at least that's my take on it, FWIW.

Don't worry about the iteration for eccentric anomaly, it should converge very quickly. At least in my experience (using this sort of formula -- Kepler's equation -- for the bodies in stock KSP), if it hasn't converged (difference of less than ~ 10-12 between iterations, say) within half a dozen iterations, something is wrong. If your given time can get large compared to the period of the orbit you're computing, do make sure to bring the mean anomaly back into the range 0 .. 2*pi. A large mean anomaly will hurt convergence. I'm pretty sure KSP does something very much like this. Time warping is not an issue -- since everything in the game follows conic sections, the game needs to do this every frame for every vessel and body in the game. It doesn't matter if the time difference between frames is 1/60 second or thousands of seconds, the effort required is the same. And any modern computer should be able to do hundreds of thousands of these calculations in a second, without even getting into multithreading, etc.

Correct, I don't have any roundoff compensation. I wrote this code initially to simulate ships moving around the KSP solar system with the planets still on rails. 'Common wisdom' on the forum was that this was too computationally intensive to do in the game, and I wanted to put that to the test. So, my focus was on speed and large time steps (so that trajectories could be pre-calculated and then stored), and accuracy just had to be good enough to not produce obviously wrong results in the game. Now I'm using it for something else and these little errors that didn't matter before ... start to matter. If I do much more with this code I will definitely look into roundoff compensation, but I don't know if there is enough interest to justify spending much time on it. I'd had a few requests for the code, but now that it's released I doubt more than 5 or 10 people will care.

Yes, thanks! And, I've just cleaned it up to make it publicly available: https://www.dropbox.com/s/39mi6hqq3ve73vt/MLROrbit-v0_1.zip . It's a command-line program, not interactive at all. To make the animations, I use the .m files included in that zip file to read the results into Octave and generate a series of plots to be frames for the animation. Then Gimp and it's animation plugin (GAP) to crop them to the proper size, then ffmpeg to encode them into a movie. I am halfway tempted to put code in the simulator itself to generate the frames directly, but it sounds like a pain and I'm not frustrated enough by the Octave->Gimp->ffmpeg process yet to do it. Included in that zip file are input files for simulating Alternis Kerbol versions 0.0 and 0.1a and 0.1b. I call 0.1a the version with Bop a moon of Jool and 0.1b the version with Bop as a moonlet of Kerbin.

Very nice! I commend you for your decision to go your own way -- as you've already found, writing your own program specially to solve a particular problem usually gives you much better performance than very-general-purpose software. Plus, you become intimately familiar with the numerical method being used and better able to judge when its results are reliable. Your relative errors look to be between one and two orders of magnitude lower than mine. And I can't make mine much smaller by adjusting the time step size; they seem to bottom out at around 10-14 - 10-13 regardless of the step size or local error limits I set. So I would say you've made a good choice of integrator to use. Which version of the Alternis system are you showing here? A number of bodies changed from v0.0 to v0.1. I think a good first step would be to not put it in a resonant orbit with Kerbin and Laythe!

It turns out to be very stable! (at least through 100 years) You put it into a low enough orbit around Kerbin that I think it would take another body passing by pretty closely to do much to it.

Hooray! I went ahead and did an n-body simulation of the updated system, but so far only the case where Bop is still a moon of Jool. This time around, Mun gets ejected very quickly, by about 1.5 Ms (illustrated here: http://youtu.be/aGvYWqj7dfk ) Pol gets ejected later, around 560 Ms (animation to come). But after that, I ran the simulation out to 3 Gs and saw no other changes.

Do you know why the energy drift is so high? Earlier you mentioned you were using a symplectic integrator. If that's still the case, that high an energy drift suggests an error, either in the energy calculation or in the simulation. (After all, the point of symplectic integrators is to eliminate energy drift!). It might be helpful to look at a plot of the energy error over time, to see if most of it comes from one particular event or if it is just drift. In my earlier simulations of the stock Kerbol system, I found that tolerances loose enough to allow energy drift in that range definitely had an impact on the fate of Jool's moons. If that energy error does come from drift, then if you can control the solver in Mathematica you should try tightening its tolerances and see if you can get the error down by an order of magnitude or so. I'll wager you see a difference in your results. Also, what eccentricity were you using for Minmus in that simulation? I believe it's 0 in the Alternis mod, but your table earlier had 0.03. (replying to posts all out of order, whoops) Nope! I didn't show the outer planets in my animation, but I checked on them and absolutely nothing interesting happened around Tylo or Eeloo. Let us know just where you want to put Bop, and I'd be happy to try it (... later tonight or tomorrow, probably).

Well, first you have to decide what the outcome of a collision should be. Your question refers to completely inelastic collisions, but that doesn't seem like a correct outcome for many cases. For example, an extremely glancing collision of two similar-sized bodies might rip them apart due to tidal forces and strew most of their mass in all directions as smaller pieces of debris.

Yep, those match what I'm using, except that I got the M0 values for Ike and Gilly reversed from what you have in the table (which shouldn't really matter w.r.t Jool's moons) and I had an eccentricity of 0 for Minmus, not 0.03 (which might be significant). In addition, I used the gravitational parameters listed in-game from the info window in the tracking center. I don't think I can, unfortunately. They're the standard colors that Octave applies to plots, whatever those are. I haven't seen those colors defined in their documentation, but I haven't been able to look very extensively for them either. I'm using a C++ program that I wrote from scratch to implement an RK5(4) adaptive solver. It's not user-friendly at all, and all the planet parameters are currently defined in the source code. I've been thinking of trying to clean it up, at least to the point that it pulls parameters from a config file and does a little error checking, and making it available. The program spits out binary position data into a file, and I have a couple of .m files that I use in Octave to read the data in and make the plots. EDIT: And here's my simulation animated: http://youtu.be/84Q9GDj25qs eggrobin, I suggest adding another view that shows a closeup of Jool and its moons, since most of the action happens there.

Just for grins, here are a few highlights from that simulation: By the end of the simulation (400 Ms) Pol and Bop both look like they're on their way out of the Jool system too, but they haven't quite made their escape yet. In the images, the lefthand plot fails to show most of the moons after they escape, so I'm remaking them.