K^2

Modern definition of science implies scientific method, which mathematics lacks completely. But it's not less for it, just the opposite. Science can fail. In fact, it's all it can do. Science can never be right. It can, and often enough is, wrong. It's still very useful, even when completely wrong, but you can't expect some deeper truths from it. That's not what science is for, and consequently, not what it does. Mathematics is a different story. It cannot be wrong. It is a self-consistent system of rules. It can be useful or useless, and some branches of mathematics are more one than the other. And the intuition math gives us about nature can be completely wrong, but that's our fault for trying to draw hints from something that isn't purposed for it. Mathematics just is. If you think one can find a flaw in it, then you don't understand first thing about it.

E² = (pc)² + (mc²)² Photons have no rest mass (m = 0), but they always have momentum. So the energy contribution is entirely from momentum of the photon.

Kerr metric does introduce a Coriolis-like term, and you can use it to extract energy from rotating object, but a) you basically need a black hole, and you are still just extracting mechanical energy from something that already has that energy. It's no different than powering a generator with a flywheel. It'll work for a bit.

I want to apologize in advance if I'm reiterating a bunch of things you know already. It's a little hard for me to gauge your precise background. But hopefully, at least some of this is helpful. Think about how you are storing the orientation of the ship now. You have the XYZ vectors of the ship written in world's coordinates. If you want to take some vector (x, y, z) in ship's coordinates to world coordinates, you compute a new vector xX+yY+zZ. But that's exactly the same thing as writing a matrix with columns (XYZ) and multiplying it by a column vector (x, y, z)T. Storing the body axes is equivalent to storing a rotation matrix. Instead of storing a rotation matrix, you can just as easily store rotation quaternion. Lets break it up a bit more. Suppose you have quaternion s that tells you how to transform some vector v in ship's coordinates to world coordinates. Write u = svs*. Now, suppose, you want to apply a rotation quaternion q to that vector u. That q might be precisely the change in rotation of the ship that you are currently applying to the axes. The fully transformed vector is now quq* = qsvs*q*. And because quaternions follow standard conjugation rules, s*q* = (qs)*. In other words, you can first compute a new quatrnion r = qs, and then apply that to original vector v as rvr*. Starting from the beginning, and looking at transformations as they come in at each time tick q1, q2, q3..., you start with, say, vector X = (1, 0, 0) as one of your body vectors. You then update it to q1Xq1*. Then you update that vector on the next step, and you get q2q1Xq1*q2*. And so on. Well, instead of keeping track of that X on each tick, all you really need to do is keep track of that product on the left, and call that your ship's transform quaternion. s = qn...q2q1. At each time step, you just need to multiply by one more quaternion on the left. The numerical errors will manifest in normalization of that quaternion drifting, and it's a good idea to just renormalize it every once in a while. I'm more used to single precision quaternion math, and that tends to drift annoyingly fast. So with single precision, I'd recommend renormalizing on each time step. Especially, since that's really cheap to do. With double precision, it might not matter as much, and you can get away with renormalizing much less frequently, but it's really inexpensive on modern CPUs, so you might as well just do renormalization on each tick.

Oh, if you are doing all of your transforms with quats, you should store the transformation of your space ship as a quaternion as well. In that case, all you have to do is renormalize the quaternion once per tick. To get the body axes of the ship, just take basis axes and transform them with ship's quaternion. The error from a single transformation is minimal, and you don't need to worry about enforcing orthogonality. By the way, so long as your quaternions are properly normalized, there is a good shortcut for computing the qvq* that you can use. By using the commutator operator defined as [a,b] = ab - ba. qvq* = qq*v + q[v,q*] = v - q[v,q] The scalar part of the [v,q] is zero and the vector part is twice the cross product v x q.

It was sort of expected that we are only seeing a small fraction of exoplanets in the systems we have been studying. How reliable are these sorts of prediction methods is still too early too say, but yeah, there should be a huge number of Earth-like worlds in habitable zones of their stars out there.

Gram-Schmidt sounds like overkill for a 3-basis. Cross products can be computed with a handful of SSE2 instructions. What are you using for rotations? If you aren't scared of low level code, you might be better off writing rotation code that does orthonormalization during rotation in a single pass, saving you trouble of doing any other checks. Branching, in particular, can be avoided all together, and that's probably costing you more than the actual operations.

Almost. It's twice the semi-major axis. (Also known as the major axis.) r1 + r2 = 2a However, keep in mind that in KSP, the apsides are reported as altitudes, and the r1 and r2 above are from center of the planet. So: h1 + h2 = 2a - 2R Here, h1 and h2 are the apsides as reported by KSP. Now that's tricky. It's easier than going from time to angle, but it's still tricky. First, you need to understand the concepts of Mean Anomaly and Eccentric Anomaly. Mean anomaly is the angle (in radians) you'd make in this fraction of your orbit if it was circular. In other words, after time t, your mean anomaly is M = 2pi * t/T. So if you know M and T, you know t. Now, the Mean anomaly is related to Eccentric Anomaly via Kepler's equation. M = E - e sin(E) Here, e is the eccentricity of the orbit, and it's equal to (r1-r2)/(r1+r2). e = 0 corresponds to circular orbit. e = 1 corresponds to escape trajectory. Elliptical orbits will fall somewhere in between. Now, Eccentric anomaly is the angle the body makes from the center of the ellipse. And that is related to the true anomaly θ (which is the phase you want) by the following. tan(θ/2) = (sqrt(1+e) / sqrt(1-e)) * tan(E/2) Once you know tan(E/2) from formula above, you can find E/2 by taking arctan of it. (It's also called tan-1 on some calculators). Make sure that your θ is in radians and is between 0 and 2pi.

Always check the units. s * m/s^2 = m/s

Beat 'ya to it. There's a lot of redundancy to it on most airplanes. Hydraulics are doubled by mechanical linkages. Trim can be used in lieu of actual control. And even if 2 of 3 DoF totally fail, you can usually use remaining DoF and throttle to have some limited control and line yourself up for a landing. A multi-engine aircraft can be flown by engines alone. Very poorly, but you can line yourself up for a survivable landing. If you are unpowered, using lifting body design, and surfaces need to be capable of surviving re-entry, your options are far more limited. Redundancy is still your best friend, but there could be weight limitations on making it trully effective. Honestly, I'd want parachutes as a final fallback for a lifting body vehicle. Even just crew parachutes. Lifting body vehicle can do passive re-entry and descent to safe altitude to bail.

Again, methane freezes solid in boiling oxygen.

T = 2*pi * sqrt(a³/μ) Substitute in period in seconds for T and Kerbol's gravitational parameter for μ. That will give you the semi-major axis a in meters, from which you can get your apsides.

So long as the Sun's starting velocity isn't zero, it should be fine. But choosing center of mass of the Solar System as origin makes a lot of the computations easier. It makes it easy to place initial position and velocity of the Sun to counterbalance all of the other objects in the System. What you want to make absolutely certain of is that whatever coordinate system you've chosen, center of mass either remains at rest or moves at uniform velocity. This should take care of itself if you simulate the system and all of the planets. But if you plan to use pre-determined positions of planets for testing, you will have to make sure that the coordinate system choice is appropriate and consistent.

Time dilations due to gravity and orbital motion are multiplicative. Orbital dilation is given by sqrt(1-v²/c²). Gravitational by sqrt(1-2GM/(rc²)). Here, G is gravitational constant, M is mass of the Sun, c is speed of light, v is orbital velocity, and r is the distance from Sun's center. For a roughly circular orbit, this simplifies to approximately sqrt(1-GM/(ac²)) * sqrt(1-2GM/(ac²)), where a is the semi-major axis. But this doesn't account for dilation due to planet's gravity. For planetary bodies, this is roughly multiplicative as well. So time dilation factor for the planet is approximately given by the following. tplanet = tdeep space * sqrt(1-GM/(ac²)) * sqrt(1-2GM/(ac²)) * sqrt(1-2Gm/(Rc²)) Where m is mass of the planet and R is its radius. You can compare these factors between different planets to figure out the difference in time flow between different ones.

Good plan. But even then, doing proper numerical integration on plaents' paths is a pain. I would recommend starting with planets on rails, and seeing how well you can simulate trajectory of the spacecraft. You can grab data for planets in the Solar system from Horizons. Make sure to set coordinate system to Sun's barycenter. Otherwise, you'll have some fictitious forces due to accelerated frame of reference. And you can compare your simulation to trajectories of some asteroids and comets. If you can get decent simulation for an asteroid, you'll know that your integration method is good. Then I'd give a crack to integrating motion of planets using Encke's.

Gravitons only make sense in quantized gravity. The full problem is not quantizable, but you can do mean field theory of gravity (which works above Plank Scale and does not work bellow it) and it will give you gravitons and their description as quantum particles. If you are working with pure gravity, however, quantization isn't useful. So then you just treat it as fields and forget about particle properties. Higgs mechanism only provides for single Higgs field, and it's sufficient to describe our observations. It is an SU(2) field, which has 3 generators. I suppose, you can think of it as 3 particles. But that's like saying that there are 8 different gluons. Without symmetry breaking, as there is with U(1)xSU(2) of electroweak, they are all the same. There could be more Higgs-like fields, of course, but there is neither need nor evidence of them in current model. Higgs field does not couple with gravity directly. So the only effect is via the masses of electroweak bosons, which we already have accounted for. Non sequitur. Gravity's coupling constant is a free parameter of the theory, just like every other coupling constant. It cannot be computed from any other coupling constants or parameters. The exact knowledge of how gravity works (which we have) will not help us do the actual computations. There are experiments we can do in regimes where gravity starts coupling to other forces, which is how we normally measure coupling constants, but the energy levels required are much above these we have access to. The fact that gravity is so many orders of magnitude weaker than electromagnetic forces makes probing gravitational constant in direct ways impossible with our technology. And various indirect methods only yield the precision we get.

Depends on a whole bunch of things, including failure modes of things that can fail. But in principle, one could design a lifting body capable of passive re-entry. Landing without controls or landing gear, though, that's just not going to happen.

I was thinking that very thing, especially near the end there. In the sense of needing to understand the question to have any chance of making use of an answer. Hence, "The ultimate answer." But I find that sometimes knowing some of the answers before you can ask the question helps find the right way.

Typical auto-rotation "glide ratios" are 3:1 to 4:1. So not quite as well as a glider, but way more than you'd expect. Lithobraking isn't on the list? Shame.

NaN propagates through any operation, and 1/0 will trip an integer exception. What's your point?

Be careful with that. Regardless of numerical precision, integrating equations of motion produces errors. It has to do with finite time steps. Typically, double precision computations are more than sufficient for any simulation, so you can stick to that for performance reasons. But you can only go so small on time steps before your machine can no longer handle computations. There are numerous methods for dealing with finite time steps. Velocity Verlet is one of these. It's a special case of Runge-Kutta methods. If this is the first time you hear of these, it's worth taking a look at. Gravity problems are notorious for causing problems with numerical integration. There is no symplectic integrator for gravity. In simplest terms, it means that there is no method that perfectly prevents energy drifts in simulation. The errors can be reduced to within reason. There are a number of methods developed specifically to deal with gravity. Unfortunately, I'm not an expert in these. For my purposes, I've never had to go beyond implicit RK methods. And if you aren't looking for NASA-grade precision, you will probably be fine with a higher order explicit Runge-Kutta. RK4 will probably be more than enough. The main reason I'm mentioning this is because everybody's first instinct when writing a simulation is to use the simple forward Euler, and that tends to produce horrible results for gravity.

Nah, we can do better than that. I mean, sure, ultimately, any science question will run into an unanswered, or indeed, unanswerable why question. But the point is to take it a few layers deeper every time. First of all, the speed of light is just a conversion constant. It's how many meters there are in a second. This has no reason to change any more than there should ever be a different number of feet in a mile. So the more correct way to state the question is why it's the fastest speed there is and why light travels at that speed regardless of frame of reference. And the real answer to this is that everything travels at the speed of light all the time. Or more precisely, 4-velocity always has magnitude c. Stationary things propagate purely in the time direction, and so they appear stationary. Things that cut at a bit of an angle appear to move, as they are in a different place in space at a later moment in time. The angle at which something propagates through space and time is determined by momentum and energy. And the relationship between momentum and energy determines mass. Hence more massive objects require more energy and momentum to be accelerated. Light is massless, and so it has a linear relationship between energy and momentum, E = pc. That means that light always cuts at a 45° angle, always traveling same amount through space and time. Change of coordinate system changes energy and momentum, but preserves linear relationship. So you get light that's red or blue shifted, but still traveling at c. This brings up the question of a) Why is light massless? and Why does relationship between energy and momentum is what we call mass? Unfortunately, this is starting to get complicated. The answers to both of these questions come from Quantum Field Theory. Light is massless because Higgs Mechanism allows for a single massless electroweak boson, and that's light. Behavior of mass as actual mass has to do with mass shell and a singularity in the propagators, and that's getting really complicated. The ultimate answer to all of the thread questions, as far as we know, is "Because Lagrangian is invariant under a continuous group of local transformations which includes Poincare subgroup." That actually gives you the entirety of General Relativity as a consequence. But it's turtles all the way down from there.

Yup. Then you have to do full rigid body simulation, which means keeping track of the body axies. The only additional recommendations I can give are these. 1) If your moment of inertia is a tensor, Euler's Equations are probably your best bet for updating craft's orientation. 2) Precise integration isn't quite as important for rotation, but I'd still use at least Velocity Verlet method. It's a bit of work to derive equivalent for Euler's Laws, but it's worth it. The integration method for n-body gravity needs to be more robust. 3) Error on the 3 axies will not be exactly the same, and it's absolutely critical to keep them orthogonal. It's worth enforcing this with cross products every once in a while.

Not quite. Earth's density isn't uniform. If it was, then yeah, it'd be exactly like r. In reality, it's quite different until you hit the core, and even then it's not quite linear because of differences in densities of inner core and outer core. Blue line is the estimate for actual gravity.