K^2

Sagnac Effect only covers frequency shift. Not the fact that the clock rate on GPS satellite doesn't match clock rate on Earth, which is critical for GPS operation. In fact, GPS clock is affected both by Lorentz and Gravitational time dilation, making General Relativity absolutely essential to operation of GPS. Again, actually learn something about the subject before embarrassing yourself.

I got some preliminary results for a 2D optimization case with a gravity turn. Unfortunately, I've messed up the mass of the rocket, but that's not a huge deal, as far as these results go. Because optimization is local, I had to start with something that gives a believable ascent program. I chose to go with something very simple. Vertical ascent to 8km, gravity turn to 45°, continue burn until apex is at 80km, and then burn prograde to establish orbit. Here is the graph of the control inputs. Blue line shows rocket's angle in radians, with 0 corresponding to vertical, and +pi/2, which is marked with a dashed line, corresponding to a rocket pointing directly East. Magenta line is throttle position. It's always full throttle, except for the coasting region to reach orbital altitude. So this was the starting program which I fed to the genetic algorithm. I've ran 10k iterations with 100 genomes in each, corresponding to 1M launches. The criterion for optimization was amount of fuel left over in second stage, while any trajectory that did not reach orbit at all would be discarded. And this is what I got. There are several things worth noting right away. First, the throttle remains at 100% throughout the whole flight, except for the coasting region. Unfortunately, I believe that to be an artifact of the "mutation" algorithm, which I will revise. However, the other bit is interesting. The gravity turn begins as a counter-rotation. I don't think that's actually helpful directly. But rather it's an indication that the turn should have been more gradual. The actual control input is rate of rotation, rather than the angle, and correcting a large jump in initial program would not be easy. Instead, rocket beings the turn with countersteer, so that eventual angle change isn't as high. Which brings us to the next bit. Actual velocity. Here is the graph of the speed of the rocket as a function of time. Here, I have original program in red and the optimizer output in blue, as before. Thin blue line is terminal velocity at relevant altitude. Here, I wanted to point out a few things. First, on both graphs you can see a sharp cusp at around 70 seconds. That's stage separation. Doesn't appear to cause any difference in burn procedure. The other bit is slower decay of the blue line once it begins to coast around 120s mark. Why? Because optimized flight is at higher altitude. Let me show the same graph broken up into components. Here, I have vertical and horizontal axes correspond to vertical and horizontal speed. Negative X corresponds to moving East. Here we can clearly see that the rocket ends up with more vertical velocity at the cost of horizontal speed, resulting in lower air density by the time the engines cut out. So what I want to do next is start out with a much smoother gravity turn, so that it doesn't result in that sharp jump, as well as allowing the system more freedom on the throttle. There are several things I can do that. And, of course, I'm going to fix the rocket mass to correspond to an actual thing from KSP.

What are you using for time step? And are you integrating with Euler or Verlet?

Let me just stop you right there. Are you aware of the fact that General Relativity is absolutely essential for operation of GPS satellites? I know you aren't. Or you wouldn't be saying such nonsense. Please, read up on the subject before you embarrass yourself further. Oh, and Brotoro nailed it on the matter of dark matter.

And now you've gone off into the crazy lands. Dark matter is a consequence of general disagreement between observed trajectories and visible mass distribution. It's a problem in General Relativity as well, which is the most frame-invariant thing we've got by its very design.

Just compute fuel flow yourself. It's thrust/(ISP*g0). The game uses g0 value of 9.82m/s². ISP should be linearly interpolated between the low and high values based on pressure. (The full formula is more complicated and discussed in this thread. But for engines with just 2 key values it's going to be linear interpolation.)

With 30km ascent, Coriolis will start to make a difference in a rotating frame. That's kind of why I went with a <6km launch for early tests. I've gone to orbital flight now, but I still haven't sorted some minor inaccuracies in simulation.

In general, it's probably even worse, because I'm not sure that 45° angle is your best bet. But I'm pretty sure that full throttle and constant angle of the rocket is. So the problem reduces to a) Finding where the rocket ends up when the engine cuts off, and Computing the range from that using range formula, and optimizing result by varying the angle. Which seems to be the way you were going about it. Final velocity is pretty easy. You just apply rocket formula, and subtract off the amount of impulse you are going to lose to gravity. That might make for a simple v(t) than what you have right off the bat. What's a bit more complicated is getting final height. You can, of course, integrate over velocity to get final position, but that doesn't sound fun. But you can make it much simpler. Again, split velocity into the pure rocket formula component and gravity component. After all, a gravity problem is equivalent to an accelerated frame problem. Remember the monkey and the hunter problem? Anyways, just integrate rocket formula separately, add in the free-fall, and you should get final position as a much neater formula.

Center point between the slits is your best bet to get a nice pattern, but it doesn't have to be that precise. That's kind of the whole point. Particle propagates as a wave packet, so you aren't aiming a point object. But if you get center of the packet aimed at the center point between the slits, you get the nicest overlap between the wave packet ad the general area where the slits are. If you are off, your interference pattern ca be a little uneven, because intensity through one slit is greater than through the other.

There is a pressure differential between floor and ceiling equal to the weight of the air per unit area. So yeah, there will be an air flow between the portals. It will have a finite speed however. And, naturally, energy for this has to come from somewhere. Presumably, from whatever is powering the portals.

To be more precise, Tycho did note that for parallax to be too small to measure, stars would have to be more than 700 times more distant than Saturn from the Sun. For all of the limitations of their understanding of cosmos, they had excellent understanding of geometry and geometrical optics. So it's not like they'd assume that if there is no measurable parallax, that there is no parallax at all. Possibility that stars were simply too distant for parallax to be measurable was understood. The problem was lack of understanding of wave optics, leading Tycho to greatly over-estimate the apparent size of stars. Even to a modern telescope, light from a distant star might as well be from a point source. However, even a point source results in an apparent disk of finite size. Brighter source results in a larger apparent disk, which is what Tycho was measuring, resulting in absolutely enormous predictions for sizes of stars.

That's a common misconception, and I suspect I know where it comes from, but not how it actually works. Because velocity is relative, I can always find an object moving at 3,000m/s relative to you. So say you've enabled warp drive, and now travel at .3c relative to that object. How fast are you traveling relative to object with respect to which you were at rest before enabling warp drive? Well, .3c - 3000m/s almost on the dot. There is going to be a slight relativistic correction, but you are still performing an STL warp relative to that initial point, despite never moving relative to it. So you don't actually have to have an initial velocity to perform a warp. Where this works a bit funky is with interplanetary travel. If I want to travel from Earth to Jupiter, for example, I've just left Earth's orbit, and I engage warp drives. If I did manage to warp to Jupiter, I'd find that my ship's total mechanical energy is actually negative. That can't happen. You can compensate for this with warp drive, but it gets all sorts of complicated. More realistically, I need to be on an Earth-Jupiter transfer orbit already before I engage the warp drive. Hence, the "initial velocity". But this is only relevant because we are working within Sun's gravitational field. All of that said, I don't know if STL warp is conceptually different from FTL one. Certainly, it'd take less energy to perform, so it'd be the first thing we do. But I don't think there is anything special that happens at the speed of light for the warp bubble that would prevent you from just scaling up your STL tech until it's FTL capable. So if we figure out how to do STL warp, we will figure out how to do FTL warp as well, eventually. Whether we ever get to that former stage is a separate question entirely.

In KSP, terminal velocity is pretty rigid, as far as craft design goes. The drag coefficient of almost any craft is going to be almost exactly 0.2, and that means terminal velocity at 1atm of almost exactly 100m/s. But if you mean due to change of starting conditions, like if you started from sufficient elevation that results in lower terminal velocity, yes, maximum altitude will greatly improve. If you want to consider extreme case of rocket in vacuum, take a look at the red velocity curve above. See how it starts as a straight line, but then curves in right as it crosses terminal velocity line? That's where drag becomes more significant than gravitational force. If there was no air, that line would continue straight. In fact, it'd curve up a bit as your ship gets lighter. However, the cutout point would be exactly the same. So if you mentally extend this straight line to the 30s mark, you can see that final velocity would easily be twice as high, resulting in more than 4x the altitude! Naturally, an increase of only 10% is not going to be anywhere as extreme, but it'd help. The optimized solution is pretty much the same, though. Gun the throttle until you almost reach terminal velocity, then ease off to TWR of 2 as you settle at terminal velocity, and continue ascent. How that holds up when I throw in gravity turn, we'll, hopefully, soon find out. Considerable! The value is (angular_velocity)² * (distance_from_center). And you get angular velocity by taking (2 pi)/(sidereal_period). The game actually takes this into account (as well as Coriolis force). In my simulation, it boosted me from apex of 5,200m to over 5,800m. Of course, with actual apex being at 5,488m, I'm still not sure if this is exactly right. But it gives you an idea of how significant centrifugal effect is.

Fuel mass is included. So the drag changes as fuel is used up, but terminal velocity remains the same. (Except for minor variations in drag coefficient.)

500g definitely won't make a difference, but I'll recheck my numbers. For drag, yeah, all of that times mass. Since everything but thrust is proportional to mass, I've been working with acceleration, but I should have clarified. And I'm starting at 75m. tavert, game supports two atmospheric models. One is exponentially decaying, referred to as legacy atmosphere, and the other is based on curves. Later can be used to model a more realistic atmosphere. There are some mods out there that already support it, but vanilla planets use the exponential atmosphere. So I started putting together a genetic optimizer. It's still a bit rough, and might need better annealing, but it looks like a good start. This is 1D, using same simulation as above. (So this isn't a perfect replica of KSP, but qualitatively it should match, at least.) The only optimization parameter is maximum altitude achieved. Altitude (left) and velocity (right) as function of time. Full throttle ascent in red, optimized in blue. The thin blue line on the velocity graph indicates terminal velocity at altitude achieved by optimized flight. And this is the throttle position (left) and resulting TWR (right). Only first 45 seconds shown, because engine cuts out after that. Yes, it's noisy. Yes, I can do something about the noise, but it's not a priority right now. It's good enough for a test. It does show an interesting feature, though. As expected, the ship takes off with full throttle, and then dials it down as ascent settles on terminal velocity. TWR holds around 2 at that point. However, right before the engine cutoff, throttle goes up again. Apparently, to give the ship that one last push before it begins coasting. That bit was somewhat unexpected. So, I guess, now I just have to figure out a good way to do this in 2D and give it enough fuel to make orbit.

Ok, so you need a function that has an equal number of defined an undefined points on any arbitrary continuous interval? Hm. It's definitely possible if we only consider rational numbers. Let me think for a bit if there are any contradictions with requiring this is also true for reals. Edit: Here is basically what it boils down to. If you require that on any interval the number of points are equal, it automatically demands that both sets are dense with respect to each other. So we need to split real numbers into two sets which are dense in each other, and both of these sets must be uncountable. That will satisfy conditions, but I'm still not sure if this is possible. All of the methods of picking a dense subset of reals I'm coming up with give me a countable subset, which doesn't satisfy the "equal number" requirement. Edit 2: So apparently, the answer is yes, but I'm having trouble following it. You might encounter the same problem.

I've been playing around with all of this, and I'm having trouble getting simulation to match the game to a satisfactory precision. For a ship, I have an FL-T100 with LV-909 underneath and Mk-1 on top. Oh, and Mk-16 parachute for not killing the test pilot. That gives me dry mass of 1.463T and 0.4995T of fuel on the pad. The engine produces constant 50kN of thrust. ISP is computed according to atmospheric pressure, and I'm using g0 value of 9.82m/s², same as the game's code, to get the fuel flow. Speaking of the atmosphere, Kerbin has legacy atmo, meaning pressure as function of altitude is P = exp(-h/5000m) atmospheres. I multiply that by 101325.0/82843.125 kg/m³/atm to get density at altitude h. This leads me on to drag, which is computed as 0.5*0.008*ÃÂ*d*v². The value for d is computed dynamically as fuel is used up, but it's so close to 0.2 that it might as well be that. Finally, I add in acceleration due to gravity g = μ/(h+R)² with μ = 3.5316000x1012 and R = 600km. As well as centrifugal force, ɲ(R+h). Both of these are consistent with how the game computes them. I do ignore Coriolis force, but since the craft lands almost next to where it took off from, it cannot be significant. I've tried integrating with Euler and Verlet using a 20ms time step, which seems to be default physics time step for Unity, and I think that's what the game uses at Warp x1. The problem is that in my simulation, the craft overshoots by almost 10%. In KSP, I get maximum altitude with throttle to the wall at 5488m, while simulation yields 5840m. In addition, I've tried comparing other parameters. Fuel cutoff seems to happen at the correct time, so I'm pretty sure fuel usage is fine. However, right before cutoff, my simulated craft is going at 216m/s, and the game tops out at about 206-207m/s. Similarly, if I just drop the ship in my simulation from 5488m/s, the impact happens at about 106m/s, while in KSP I get something clsoer to 104m/s. So error in drag computation would be my first guess. But I just can't find any problem with it. The equation I'm using for drag computation is consistent with both the wiki and what I've been able to dig up in the game's code. Of course, I don't expect perfect agreement, nor do I need it, but 10% is much too much for something that seems to be using all the same computations. Any suggestions?

I'm still trying to figure out what he means by solution to a function...

There is one less mystery in the world. I almost feel sad.

Perfect fit. Magenta points are from the page you linked to, one with numerobis' data. Blue lines are my piecewise-cubic fits. Jet Engine: Turbojet:

And would you mind telling us where the center of the universe actually is? At least, point in the general direction.

I don't think it's fair to say that it caused no alarm, given quite a stir it caused in New York in the 30's.

It's not inaccurate. It's possible to describe universe from Geocentric perspective with almost as much precision as any other frame. And it has a certain elegance to it. It's not so much about Earth being the center, as about any arbitrary point being as good a center as any other. I'd find an Areocentric or Selenocentric system just as exciting.

I've said that it was piecewise-linear. It only follows the above formula between 0 and 1. Even that might not be exactly right. See bellow. Outside of that range, however, behavior is very simple. It's a constant at whatever value the end point had. So for any pressure above 1 bar, it's going to be 320s. The actual behavior of the AnimationCurve is more complicated. It seems to be piecewise-cubic, with the 4 fitting parameters being the 2 values and 2 tangents at either end. The problem is that you can define the curve without specifying the tangents. And I have not yet figured out what Unity substitutes for the tangent values in that case. The cool thing is that even though none of the modules make use of it, KSP does allow you to specify a curve with custom tangents! So instead of using "key pressure value", you can use "key pressure value tangent_in tangent_out". This allows you to define almost any smooth curve you like for atmosphereCurve and the velocityCurve. I don't, but I might know where to look this up, if you are interested. The thing, though, is that it very much depends on the bell. The actual bell shape depends on a few parameters, and is basically just designed to match the engine. But the point at which the curve of the bell is truncated depends on design operating pressure. The ideal nozzle for a rocket engine narrows at first to make the exhaust speed up. However, once the flow reaches speed of sound, the nozzle needs to start expanding. Hence the bell. The bell then keeps on expanding until either the pressure in the exhaust flow matches external pressure, or it no longer becomes worth it to increase the mass of the engine for the extra impulse you are going to get. Consequently, an engine designed for operating in atmosphere is going to have a short bell. It will perform a little better in atmosphere than an engine designed for vacuum, but the main benefit is a much lighter engine due to much shorter bell. The drawback is that it will gain almost nothing when operating at lower pressures than the pressure that it's designed for. Engine designed for vacuum is going to have a very long bell, since there is no external pressure that dictates a cutoff point. It's just as long as they can make it without making an engine too heavy. This engine will have its peak ISP in vacuum, and will suffer significant penalties when operating in atmosphere. Edit: I think I worked out what the algorithm for AnimationCurve actually is. I've used the key-value pairs for the jet engine posted earlier in the thread. atmosphereCurve { key = 0 1200 key = 0.3 2500 key = 1 800 } And I replaced these with key-value-slope triplets. {{0, 1200, 4333.33}, {0.3, 2500, 952.381}, {1, 800, -2428.57}} The way I got these is by taking slopes of lines connecting a key to its neighbors and averaging these. For end points, I've averaged them with themselves. Once I had these, I used 3rd order polynomial to connect the keys, matching slopes at both end points. And this is the curve that I got. Why do I think this might be right? Because it peaks at 0.35 bar with a value of 2,524s. Which is very close to what tavert indicated, and I'm strongly inclined to believe him. Trying to "average" the end-points as well, assuming slope of 0 beyond end-points, results in a slightly different keys with a lower maximum. So it looks like end-points aren't averaged. That means that if the function is defined by just two keys, it will, indeed, be linear between the keys.

I'm really starting to think that the "simplest" way to solve this problem is a genetic algorithm with simulated annealing. I guess, I'll play around with that.