tavert

That's about what I expected for genetic algorithms, but I was kinda hoping you would come up with something that surprised us all If you want to try a different approach (besides PSOPT which has successfully worked for alterbaron and mhoram), I recommend using the Ipopt solver (I've tried many, and Ipopt is the only general-purpose open-source nonlinear optimization solver that's worth using) via either the Coopr/Pyomo modeling language, or through Casadi. The MechJeb ascent autopilot parameterizes its trajectory with a handful of numbers: target orbit altitude, gravity turn start altitude, turn end altitude, final flight path angle, and turn shape. Then there are optional thrust control settings like limit to terminal velocity, limit to a specified throttle percentage, or limit to a maximum acceleration in m/s^2. There's also a "corrective steering" option which adjusts pitch up or down to try to make the rocket's velocity direction match the provided pitch-versus-altitude path, rather than the default behavior of just setting pitch equal to the provided path and not trying to control the velocity direction.

So how much of that time per iteration is computing the objective function and constraints, versus the gradients and Jacobian? Are you relying on Matlab to do finite differences for you, or can you compute gradients analytically? Are the optimization variables the orbital elements and maneuver components for each phase? If vectorizing is adding overhead, either you're doing it wrong or your problems just aren't very big. For loops should be avoided like the plague in Matlab for sizes beyond about 5-10.

One thing I'm not certain on since none of our tests had nonzero tangents provided in the curves, was whether column 3 is the in tangent and column 4 is the out tangent, or the other way around. Until someone points to where the part.cfg data gets turned into an AnimationCurve in the code, or collects some conclusive test data for an engine with some nonzero tangents, I think we're all still guessing on this detail. Doesn't yet matter for any of the stock engines, but worth noting. Also K^2, where/how did you get that ModuleEngines code snippet from?

Also see recent thread here http://forum.kerbalspaceprogram.com/threads/67606-Fuel-consumption-as-a-function-of-atmospheric-pressure What Supernovy said is right for rockets, the story's a little more complicated for the jet engines.

They're in MechJeb, I don't really know what the default window settings are but it might be there in a window called "Ascent stats" or something to that effect. If there's not a preset for them, you can add them to a window with the custom editor. I don't remember which category they're under, but they're in there somewhere.

Delta-V expended, Gravity Losses, Drag Losses, and Steering Losses. I'm not sure I understand the question. For ascent to orbit, you need to impose a final condition of desired altitude, zero vertical speed, and the horizontal speed needed for a circular orbit at that altitude. Accounting for the rotating reference frame means you need to add the extra terms K^2 described to your dynamics. Or you can work in Cartesian (x-y-z) coordinates as long as you account for the correct variable direction of the gravity force, but then your final conditions are more complicated.

Some combination of gravity losses and steering losses, mostly gravity. Watch the ascent stats when you run these experiments. Oberth effect manifests itself as reduced gravity losses.

If there's an atmosphere, trajectory optimization is tricky and craft-dependent. If there's no atmosphere, the constant-altitude landing method (stay at full throttle until the very end, just control vertical speed using pitch) is more efficient than a retrograde suicide burn. The difference depends on TWR, it's more noticeable at lower TWR.

Right, you aren't making your engine any more efficient at turning fuel into thrust, but you are getting to the same destination using less fuel overall. I've gotten to low orbit in under 4300 m/s, but that was including a Kerbal sitting in an external seat and I think they have lower drag coefficient than most parts. Because of the way drag works you can reduce drag losses by using lots of low-drag-coefficient parts like aircraft cockpits or RCS blocks, but that's kind of cheaty. For low delta-V ascents, try making a rocket with a high TWR, set MechJeb ascent to start turn at 8 km, end at 37 km, final flight path angle 5 degrees, turn shape 66% (credit to Nao for finding this trajectory). Limit to terminal velocity, and as soon as you reach terminal velocity also enable an acceleration limit of 22 m/s^2 and keep that on for the rest of the flight.

There is the slight hiccup of the stock atmosphere not behaving like an ideal gas. For Mach number to be well-defined you need a well-defined speed of sound, which we don't exactly have in stock KSP. The temperature sensor readings are annoyingly decoupled from the rest of the atmospheric physics, so are mostly useless. If we assume ideal gas behavior then either the temperature readings are wrong or the pressure-density relationship is wrong. If we ignore the temperature readings, Kerbin's atmosphere behaves isothermally which would indicate a constant speed of sound if the molecular composition is also constant.

What you're looking for in the part.cfg is the atmosphereCurve: atmosphereCurve { key = 0 370 key = 1 320 } This example is from the LV-T30. It means that at atmospheric pressure = 0 atmospheres (vacuum), the specific impulse is 370 seconds. At atmospheric pressure = 1 atmosphere (sea level on Kerbin) or higher, the specific impulse is 320 seconds. When there are only two points in the curve, the interpolation is linear versus atmospheric pressure. Atmospheric pressure is an exponential function of altitude.

You're absolutely right on the prioritization. None of this makes much sense within the stock aerodynamic model either, and as far as I've seen the devs haven't shown much interest in improving it, or simply adapting some or all of FAR as stock (not saying this is their best option, but it's a possible option). KSP's not a flight simulator and Squad doesn't seem to want to make it one, but the fact that it's much easier to build your own aircraft in KSP than in real flight sims means people will continue to play around with aircraft in KSP. I don't think your minority feeling is justified or accurate, not sure why you would get that impression. Rocketry design tradeoffs at the simplified level KSP presents come down to a handful of numbers, and once you're in space those numbers are static. Design for atmospheric flight depends much more on operating condition, and covers a pretty wide range. You could fiddle with the curves within KSP's current setup and get something that may feel decent - modders are already working in that direction.

Be sure to right-click on the engine and watch the thrust carefully. Starting in 0.23, jets will now auto-throttle themselves down when running low on IntakeAir, down to a threshold of 10% for basic and turbojets, or 33% for Rapiers (I think only when auto-switching is disabled). Not really, the data itself is contained in the part.cfg files. K^2 finally figured out the proper way to interpret it here http://forum.kerbalspaceprogram.com/threads/67606-Fuel-consumption-as-a-function-of-atmospheric-pressure and we verified against a large set of points that numerobis had collected. I just plotted it all up. I think the Rapier's balance is about right, for what it is. It's a slightly worse jet than the turbojet, a slightly worse rocket than the aerospike, put together into a package that weighs more than either individually but less than the two combined. It's popular for its simplicity, but it's objectively less efficient because that's the role it's supposed to have. Edit: This would all be a different story if jets were rebalanced and given unique roles. Things would be more interesting if "conventional" jets had a more realistic upper speed limit, and there were alternate types of air-breathing propulsion like ramjets, scramjets, and precooled engines like the SABRE. These all have different characteristics in terms of weight, thrust, efficiency, speed, cost, and complexity. But this likely gets into too complex of a setup for the purposes of a game. The more complicated engineering details you put into the game past a certain point, the more difficult it is to make sure it's still entertaining to play for a wide audience.

Going strictly on numbers rather than feel (any manually flown flight results are almost useless for making scientific conclusions here, as differences in piloting will lead to large uncertainties in the data), the Rapier is an inferior jet engine to the Turbojet - it has the same same Isp curve vs altitude and the same thrust curve vs velocity up to 2000 m/s, but with 190 kN / 1.75 tonnes instead of 225 kN / 1.2 tonnes. That's a decent point. The lower jet TWR of the Rapier is only worth it if you get more rocket performance out of the difference in mass than whatever bipropellant engine you choose to pair with the turbojet. If you're already nearly at orbital velocity when you switch from jets to rockets, you rarely need much TWR. At lower speeds and altitudes, your TWR requirement will be higher. However any fans of the Rapier due to its simplicity should look carefully at your ascent trajectory. Even with small numbers of intakes, substantial efficiency gains are possible by building up as much horizontal speed as you can at the highest altitude your intakes allow you to fly on jet power. The mode switch on the Rapiers should also be toggled to manual, since I believe the automatic switch will occur at the first sign of flameout at full throttle whereas in manual mode you can continue flying higher in air-breathing mode by throttling down. Assuming a proper trajectory, the Rapier is never going to be more efficient than pairing a turbojet with an LV-909 (or a few 48-7S engines which do outclass every other rocket in most situations - a pair of radial 24-77s is also a good choice if you're staying within the Kerbin system, simple to construct and not overpowered), no matter how many intakes you have. But it will be more forgiving of suboptimal trajectories. The thesis of the thread title of the Rapier not sucking depends on your skill level more than anything else. If you know how to get an efficient jet ascent, on few intakes or many, then the Rapier does suck. If you're new and still figuring it out, then it doesn't.

I'll put a vote in for the RL10, the very first LH2 engine built in the US. First flight 1961, workhorse of the venerable LH2-LOX Centaur upper stage used with many Atlas and Titan rockets, in a cluster of 6 powering the upper stage of the initial version of the Saturn I, and in modified form powering the Delta III/IV Cryogenic Second Stage. Still flying after over 50 years! Thrust depends on variant, but ranges from 66 to 110 kN, mass from 131 to 277 kg. Pros: - Extensive track record and flight history, I suspect it has the most flights of any cryogenic engine, and if it's not in the overall lead among all engines then it's probably only second to the Soyuz RD-107 family. - High specific impulse of 440-460 s. - Powered the upper stages that launched the Surveyor lunar probes, Mariner 6, 7, (8 was a whoopsie) and 9 to Mars, Mariner 10 to Venus and Mercury, Viking 1 and 2 to Mars, Pioneer-Venus 1 and 2, Pioneer 10 and 11 and Voyager 1 and 2 and Cassini/Huygens and New Horizons and Juno to the outer solar system, the Mars Reconnaissance Orbiter and Curiosity Rover, and countless communications and military satellites. Cons: - Expensive - Very old design

Would you feel any differently if a little dialog popped up saying "You have earned 5 science points"?

Did you remove the monopropellant from the pod? And what do you mean by "legacy atmo"?

You beat me to it, I did the thrust curves first since they have tangents defined. Perfect fits there too: Mathematica code: AnimationCurve[Keys_, Values_, TangentsIn_, TangentsOut_] := Function[x, Piecewise[Join[ {{Values[[Ordering[Keys][[1]]]], x <= Min[Keys]}, {Values[[Ordering[Keys][[-1]]]], x >= Max[Keys]}}, Table[{InterpolatingPolynomial[ {{Keys[[i]], Values[[i]], TangentsOut[[i]]}, {Keys[[i + 1]], Values[[i + 1]], TangentsIn[[i + 1]]}}, x], Min[Keys[[i ;; i + 1]]] <= x <= Max[Keys[[i ;; i + 1]]]}, {i, 1, Length[Keys] - 1}]]]] DefaultCurve[Keys_, Values_] := With[{TangentFirst = (Values[[2]] - Values[[1]])/ (Keys[[2]] - Keys[[1]]), TangentLast = (Values[[-1]] - Values[[-2]])/ (Keys[[-1]] - Keys[[-2]]), TangentMiddle = (Values[[2 ;; -1]] - Values[[1 ;; -2]])/ (Keys[[2 ;; -1]] - Keys[[1 ;; -2]])}, AnimationCurve[Keys, Values, Join[{TangentFirst}, (TangentMiddle[[1 ;; -2]] + TangentMiddle[[2 ;; -1]])/2, {TangentLast}], Join[{TangentFirst}, (TangentMiddle[[1 ;; -2]] + TangentMiddle[[2 ;; -1]])/2, {TangentLast}]]]

It was no longer intact after it hit the water. It's hard to tell what condition everything was in immediately prior to hitting the water from just telemetry and a grainy photo, but from what they've shared with the public it sounds encouraging.

Interesting post, and I don't know when you originally wrote it, but this piece in particular is at least partly rectified now. The CASSIOPE test demonstrated supersonic retro burn, and survival of the first stage down to a few meters above the ocean. There's a grainy photo floating around taken presumably from some kind of aircraft close to the intended splashdown point, where everything looks surprisingly intact. I'm not sure if the photo was taken before or after the centrifuging flameout problem though. There's still lots of work for them to do, and you're right that reusing the first stage won't immediately be a silver bullet, but what they've already accomplished is extremely impressive.

The velocityCurve's actually do specify tangents. Ferram also puts some nonzero tangents in some of his engine curves in FAR. Good catch! That looks like the most accurate explanation I've seen yet. I'll run this against numerobis' data here https://github.com/numerobis/KSP-scripts/commit/0b3fb888bb5ec7b10eaadccc6216aa30ad2c604e and see how close it all lines up. He's been wanting to figure this out for a while, if he has already found the solution then his code doesn't reflect it yet. I was playing around yesterday with Catmull-Rom splines, but that's not quite what this is.

I tried ACADO (via C++ https://gist.github.com/tavert/7783938) with KSP physics a few months ago, it couldn't even solve a strictly vertical ascent problem. The authors are also absolutely unresponsive to most issues that get reported on their discussion board. Not sure trying to eliminate time and solve with radius as the differential variable is a great idea. You'll need to take into account the variation of Isp vs altitude if you want to minimize actual fuel use, and there can be trajectories for which altitude versus time is not an invertible function.

Interpolation of Isp for jets is not actually linear. You'll notice for the turbojet for example you have atmosphereCurve { key = 0 1200 key = 0.3 2500 key = 1 800 } but the reported Isp in the right-click menu peaks at slightly higher than 2500, around 2525 or so. When there are more than 2 points in the curve it's some sort of spline or polynomial, not piecewise linear. Also I only recently became aware of the fact that for jets in KSP, the reported specific impulse in the right-click menu is not accurate. The effective Isp, equal to thrust / (g0 * mdot), is currently scaled by the velocityCurve. I suspect that's a bug.

You have the right idea, using a gravity assist off the Mun is the most efficient way to make a large inclination change from low orbit. Will require careful tweaking of the maneuver and flyby to get it right. If the Mun weren't there or if you're having trouble finding a good flyby path, then a bielliptic inclination change is the next best thing for large changes (raise apoapsis to high altitude and close to the equator, change inclination at apoapsis, aerobrake to re-circularize).

Depends on your TWR: http://forum.kerbalspaceprogram.com/threads/39812-Landing-and-Takeoff-Delta-V-vs-TWR-and-specific-impulse. 1100+ is very conservative. Around 900 plus the cost of transferring down to a low circular orbit just over the terrain should do it if flown well.