tavert

2012a is the next closest thing I have installed. Had to slightly modify helper_methods/multiStartCommonRun.m to replace optimoptions with optimset, and fiddle with /etc/hosts to avoid a java.net.UnknownHostException. Looks like I got something that is mostly working, I'll PM you a link so you can test in a VM.

As an update on attempting to build this on Linux, I finally sorted out my Matlab license situation for the new year and installed R2013a on a Linux machine. First issue was the Lambert solver, as bk2w saw on Mac. The recommended emlmex call to compile lambert.m into a mex file doesn't work in R2013a since emlmex is obsolete, but it did work in R2009b to generate a lambert.mexa64 which appears to work fine in newer versions of Matlab. When I run projectMain.m in Matlab R2013a after compiling lambert.mexa64 (and renamed lambert.m to something else for testing purposes), the basic Kerbin-Duna porkchop plot appears to work. Don't have much time to test other features. So then I tried deploytool to build the standalone application. It appears the Matlab Compiler is very buggy in R2013a on Linux, see http://www.mathworks.com/matlabcentral/answers/98190 and http://www.mathworks.com/support/bugreports/951485. I'm running into the same error as in those posts: Depfun error: 'Unexpected Standard exception from MEX file. What() is: ..' Tried the suggested workaround replacing depfun.opts, didn't fix the error. The error occured in the deploytool Build window after "Processing /opt/matlab2013a/toolbox/shared/instrument/mcc.enc", so I suspect it might be Instrument Toolbox - related. I might still have a copy of KSPTOT 0.10 lying around, I may try building that to see if it runs into the same error. Otherwise I don't have a lot of time to keep messing around with this, sorry.

Yeah, did not catch that quirk about jets until 6 posts later. It "makes sense" in that we can see how the bug happened, but it's still undoubtedly a bug. There's also throttle coming into the picture somewhere in that sequence, both user-set and (new in 0.23) from running low on intake air. Those effects should also be tested.

Well you'd really want to test while stationary vs while moving at 1000 m/s at the same altitude to compare at the same reported specific impulse. Anyway, some testing confirms that for jets, propellant mass flow (fuel + intake air) isn't given by Thrust / (9.82 * Isp), it's given by Thrust / (9.82 * Isp * velocityCurve). Strange. I can imagine where the bug came from though, fuel flow must've been calculated after scaling the rated thrust by the throttle but before scaling it by velocityCurve. The displayed fuel flow in the right-click menu is in tonnes per second including both fuel and intake air, to get to liquid fuel units in the resource bar divide by (16 * 0.005). Yes but the reported specific impulse only changes with altitude. If you were to climb extremely slowly you'd still see the same reported specific impulse in the right-click menu, though apparently the fuel flow would be higher per unit thrust because of the VelocityCurve factor described above. Wings are fairly light, but they aren't completely free. Horizontal launch imposes quite a few more structural constraints on your construction methods and the shapes of payloads you can carry, I'd usually rather just go with slightly higher TWR, skip the wings and call it done.

Going to have to go test this now, I don't think it works that way. If fuel flow for jets were always based on max nominal thrust instead of actual velocity-dependent delivered thrust, then at super high speeds we'd continue to see high fuel usage. As far as I understand it, the only thing that's strange about the way specific impulse works with jets is that 15/16th's of the propellant mass is coming from intake air.

Post the source of your simulation and we can look over it. Were you accounting for the reduction in effective weight due to the rotation of the surface of Kerbin?

The Rapier as a bipropellant engine is uniformly worse than an aerospike, so like the Poodle or Mark 55, it won't show up anywhere. Air-breathing TWR depends on craft speed and Isp depends on altitude, so there are more variables with jets than rockets. For stages that operate in oxygenated atmospheres, you want to use jets as often as possible due to their dramatically superior efficiency.

Uh, you mean thrust, right? Specific impulse of jets only depends on altitude. Agreed. Wings are overrated, and don't do much once you're at the altitudes you want to get to before building up most of your speed anyway.

In case anyone was having issues with the Wolfram spreadsheet version (I think it's a scrolling problem with Firefox. Opening in a Private Window or in Chrome may or may not fix it, or clicking on whatever you can see then hitting page up.), I went and implemented the same thing using the OpenOffice Solver here https://dl.dropboxusercontent.com/u/8244638/KSP%20Design%20Optimizer.ods This should allow adding mod engines, fuel tanks, and/or SRB's. Just change the "Number of __ types" on the relevant sheet so the macro knows how many to loop through, and add the listed part stats. You'll need to enable macros in your OpenOffice security settings for this to run. Excel won't load the formulas or macros properly, so OpenOffice is required for this to do anything useful. The Excel Solver might work for this too, but the macro would probably need to be rewritten.

You can do vertical takeoff with jets as long as you have enough of them. Keep in mind the turbojet and Rapier only provide half their rated thrust at 0 speed. If you have enough jets to do this, then you can skip the wings and wheels and all the complexity of a horizontal takeoff. Once you're in the air, you first want to get to high altitude to reduce drag losses, then you want to get as much horizontal speed off the jets as you possibly can. If you're running exclusively on jets when you're in the atmosphere then you want to have an effectively horizontal trajectory at the highest altitude your intakes can keep running the jets. Build up as much horizontal speed at that altitude as you can. If you have enough intakes and you're using turbojets, this can get you past orbital speed, with an apoapsis outside of the atmosphere. If you don't have enough intakes to reach orbital speed, just keep accelerating at constant altitude until you reach a steady speed. Then switch from jets to rockets and pitch up a bit.

Not in 0.23, the EVA propellant has zero density so the Kerbal is the same mass regardless of how full his EVA tank is.

Atmospheric ascent is a difficult optimal control problem that can't really be solved analytically because of the nonlinearities involved. The optimal gravity turn trajectory is craft-dependent. You could look at an idealized rocket with no maximum thrust limit and determine the absolute minimum delta-V ascent trajectory for each planet, but even this would require numerical optimization techniques and wouldn't be of too much practical use.

Are you trying to calculate velocity, distance, or both? Velocity is the first integral of acceleration, distance is the second integral of acceleration. Worth noting that cos(sin^-1(x)) = sqrt(1 - x^2), which you can work out by drawing a right triangle and rearranging the Pythagorean theorem. It's a somewhat long and messy integral. You can have Wolfram Alpha walk you through the Step-by-step solution (2 times per day after signing up with a free account), see http://wolfr.am/1jrh0KR

Was aware many of you guys play the game, quite amused you're posting job openings here too I'll be sending my resume to the GNC group when I'm closer to finishing my PhD.

Sounds like you're just not familiar with radians. Trig functions conventionally deal in radians, not degrees. 1 radian is 180/pi or roughly 57.3 degrees, sounds reasonable.

For terminal guidance I imagine the implementations could be quite similar. Hence the JPL flight testing looking pretty similar to the Grasshopper testing. What might be quite a bit different would be the incoming initial conditions on re-entry, would probably look much different for a Mars scientific mission than an Earth booster return. I've been voraciously reading as many papers like this one http://www.lpi.usra.edu/meetings/marsconcepts2012/pdf/4193.pdf and anything else by the same authors trying to find out the implementation details. Other than being formulated as a second-order cone problem, I don't know whether they're using an existing solver or if they wrote their own custom optimization code.

If you look at the control algorithms and researchers involved here, this has common development heritage with SpaceX's Grasshopper. JPL's more interested in the scientific benefits of improved powered landing accuracy on other planets, SpaceX for now is looking at returning and landing their launch stages.

https://github.com/mhoram-kerbin/ksp-launch-optimizer

It'll take less time in reality, but the game time (or distance covered in a given game time) should be very similar. The only difference is in numerical integration error at a higher timestep.

I've got a bunch of data here http://forum.kerbalspaceprogram.com/threads/45155-Mass-optimal-engine-type-vs-delta-V-payload-and-min-TWR that will tell you, for any given minimum TWR, payload mass (everything except engines, propellant, and tanks), and delta-V, which engine type you should use to minimize total craft mass. It's essentially running the rocket equation many times for each different type of engine, but also considering the number of engines you'll need to meet your TWR requirement, and how many fuel tanks to get the required delta-V.

The OP specifically says 2020. 6 years from now, not 30. Reusability on otherwise conventional chemical rockets will make a significant difference to orbital launch costs. That's not happening via SLS, hopefully it will happen via commercial means though. As far as space elevators go, the Elon Musk quote is "why haven't we built a bridge to Europe?" That would be cheaper and more technically feasible than a space elevator, and probably have a faster payback period in terms of economic activity.

Density, not coefficient of drag. Coefficient of drag in stock KSP is just a mass-weighted average of the drag coefficients of the parts contained in your craft. And density isn't totally arbitrary, it is a conventional barometric formula assuming constant temperature.

Yeah, I took the same approach, doing extra-atmospheric skips with extra thrusting while in the atmosphere, last time I ran this challenge. Takes a lot longer though.

Don't try to think of of the entire atmosphere as a control volume here, since the properties vary over altitude that isn't a very helpful way of looking at it. The ideal gas law says P V = n R T as you said. Assuming the chemical composition of the atmosphere is more or less constant, n = m / M where m is mass, M is molar mass. Rearrange the idea gas law a little, you get P M / (R T) = m / V = rho. So density of an ideal gas is directly proportional to pressure, inversely proportional to (absolute) temperature. In KSP's atmosphere the temperature is completely independent of the aerodynamics, the pressure and density behave as if the atmosphere is at a constant temperature.

Try going retrograde. Or polar.