arkie87

Try starting out at TWR > 1. If you start below 1, you must be standing still until you burn off enough weight? How does that work? It's also possible you started high enough above sea level such that you began falling...

Gravity has nothing to do with the page i pasted from my textbook... my textbook derives the phantom forces experienced due to transformation of coordinates... Where do you see any value related to gravitational constant? or the planet? Very confused.... Absolutely no idea what you are trying to convey here. The acceleration vector is given in the theta and r directions. If the term on the right-hand-side is positive, so is the acceleration. You misunderstood. In my model, what i call "x" is really "theta" and what i call "y" is really "r" i.e. even though my model uses "x" and "y" coordinates, it is not Cartesian, but rather, polar. Free body diagrams wont help you, since we are discussing transformation of coordinates. The book derives what happens to conservation of momentum in a rotating reference frame. I really cant believe we are even debating this.

I unburied my dynamics textbook: Turn your attetion to polar coordinates (which are the coordinates i am using). r-coordinate is y-direction and theta-coordinate is x direction. a_r = r'' - r*(theta')^2 v_theta = r*theta' So: a_r = r'' - v_theta^2/r the V_theta^2/r term is the "centripetal lift"

This is the "horizontal" approach described. It is more efficient, but more dangerous. I recommend buying life insurance for your Kerbals before you attempt it

This is called a suicide burn. What's more efficient is a horizontal one (albeit much harder to pull off and not always possible due to terrain). What's more practical is to slow down horizontally over your target and then fall (from as low as possible) onto your target, performing a suicide burn from a low altitude.

Rather than respond point by point, i think the example you provided is poignant: The "centripetal lift" term results from transformation of coordinates. Either we have to treat the craft moving in a circle (in which case, centripetal lift term is not necessary) but we must calculate gravity vector in both x- and y-coordinates; or, we rotate x-coordinate (theta coordinate) and y-coordinate (radial coordinate) around with the craft, such that x =0 always (i.e. stationary) and gravity is always pointed down in the y-coordinate (in which case, centripetal lift is necessary). Now back to your example: In the case of the spacecraft at 10 km perfectly circular orbit, either we track its position in x-y plane using gravity vector (which has components in both x- and y-coordinates), which changes with time, and will cause the craft traveling at orbital velocity to travel in a circle or We transform coordinates, such that x- and y-coordinates follow craft around 10 km orbit-- with this method, it is obvious that x-coordinate remains zero always (since it is moving with the craft); however, the y-position will not remain at zero due to gravity always pointing downward in the y-direction -- to counter this, we need centripetal lift. As a side note, in an ellipse, centripetal acceleration does equal V^2/R; however, R is not constant, so instantaneous R must be used.

No drag isn't an assumption; it's a requirement for the model i.e. in only applies to atmospherless bodies. That said, terminal velocity under realistic aerodynamics models, such as NEAR or FAR, is unreachable. Single-stage i'll give you though, so clearly it applies only if you are single stage, which might realistic if your lander is single stage to ground and back up to orbit, where it docks with the main craft.

Dont sweat it! No, by "centripetal lift" i mean decrease in apparent gravity force due to horizontal velocity around a circular/spherical body i.e. V^2/R term, before the craft reaches orbital velocity. This occurs even if no change in height occurs during burn. At orbital velocity, centripetal lift = gravity. When accelerating up to orbital velocity, this term is very important; after you've already achieved orbital velocity, i agree, we can assume planet/moon is large enough such that very little height is gained during acceleration. I am locking phi (theta) to the angle it needs to be to cancel gravity (minus centripetal lift). The angle is, however, NOT constant during the burn for two reasons: (1) Mass is decreasing, so instantaneous TWR is as well (2) Centripetal lift is increasing, so instantaneous TWR is as well The only main difference between our two models is centripetal lift term (that, and you define efficiency using escape velocity whereas i define it as just getting into orbit). I have compared our two methods, correcting for the fact that my model only accelerates up to orbital velocity, rather than escape (so i've added in the difference). Here are the results: So you can see, my model predicts a higher possible efficiency because it includes effect of centripetal lift, which benefits the craft as it approaches orbital velocity.

Yeah, he PM'ed me and i check out his thread, but he neglects centripetal lift

Eq. 7 has a typo (it is inverted); the equations deriving from it seem to be correct though. What about centripetal lift? It appears this paper neglects it (and in doing so, arrives an an analytical solution). Please check out my thread, which accounts for centripetal lift (thereby requiring numerical integration), and non-dimensionalizes equations such that similarity requirements become apparent, and thus, results are applicable for all planets/moons etc: http://forum.kerbalspaceprogram.com/threads/103890-Non-Dimensional-Model-for-Optimal-Launch-Efficiency

Oh, my bad sorry!

Not sure where any of this is coming from? Nobody said it was a "conceptually difficult" problem, I was just providing the solution. And who said i was having trouble maintaining altitude? Though i would agree, a plugin (i was thinking about writing a kOS code http://forum.kerbalspaceprogram.com/threads/68089-0-25-kOS-Scriptable-Autopilot-System-v0-15-2-2014-11-19) would be ideal to always follow the orientation to produce zero vertical velocity. Alternatively, a plugin to put a marker on the navball would be pretty sweet.... EDIT: actually, i think K^2's point is that in the OP title, i said "optimal launch efficiency" rather than "optimal horizontal launch efficiency." I have revised OP title to reflect this.

Yeah, ive heard people say prograde orbit and the only way to interpret that is in the same direction as the planets rotation. But just thought i'd clarify. And "normal" direction is defined such that when looking at orbit from normal, orbit is going counter-clockwise always, even in a "retrograde" orbit.

the issue of what makes science "new" is up for debate But my main point is that contracts should assign NEW science (regardless of how it defines it as "new"). I assume you like that idea?

temperature could vary on Mun, due to volcanic activity, reflectivity of surface material, sunlight/daylight etc... so it's not soooo unrealistic. but yes, Kerbin is an exception since aerial surveys do have biomes themselves. But my main point is that contracts should be linked to doing NEW science; i dont care if what makes science "new" is the biome or not.

For temperature scans, for instance, biome overhead doesnt matter; what matters is altitude i.e. low orbit, high orbit. So too for aerial surveys, the requirement should be, "get a temperature scan from Low X orbit" rather than from Y meters above Z random location. My main point/suggestion is that contracts should be linked to doing new science, rather than something random. I will revise OP to prevent any confusion.

I was just thinking this. I assume by prograde you mean counter-clockwise when viewed from north? This would make sense since normal is defined using the cross product of radial vector and velocity vector

Can't say I'm a big fan of the aerial surveys (especially early in the game without spaceplanes) since it takes a long time flying to get there, you have to hit a relatively small target, and waste a lot of fuel with correction burns etc... Furthermore, the biggest problem is that you are conducting a random experiment in a random location, and you might not even yield any new science (I've had aerial surveys which required a crew report, for which i got no science since i had already performed a crew report in that Biome). Thus, what i want to propose is that contracts should be linked to doing new science. For instance, instead of taking surface samples from a random location, what would be better is to assign biomes with which to conduct X experiment. This has many advantages over random locations: (1) The target is much larger, so it will be easier to hit Furthermore, the game should only assign biomes that havent had X-experiment done there, thereby: (2) eliminating repetitiveness/pointless contracts since each mission will yield new science (3) guiding (new) players by telling them which experiment to do where (less sandbox-y) (4) giving players a budget with which to conduct science (instead of expecting them to fund it by cleverly linking testing contracts to their scientific expeditions) (5) helping players fill out their science log and essentially pointing out experiments that havent been done yet (6) intrinsically limiting the number of contracts of each type (since you cannot get a contract to perform the same experiment in the same biome) (7) better integration with existing KSP features i.e. Biomes (rather than random locations which are lost...); it will help tie career mode together What do you guys think? Is there a mod that does this? If not, want to write one?

Has anyone else noticed that sometimes when you are passing a descending node, and you want to burn to zero out ascending/descending nodes, you should always have to burn normal, but sometimes, when i try burning normal without using a maneuver node first (because I'm lazy) i find that it is reverse-- i need to burn anti-normal. What's going on? Is this a glitch with the definition of normal/anti-normal, or is something else happening that I'm not noticing?

Yeah, basically, what Slashy said. I do not prove that this strategy is optimal, but i do provide the optimum TWR if you choose this strategy. I am an engineer, not a mathematician, so I do not need a rigorous mathematical proof, but the only alternatives i can think of is vertical for some distance and then horizontal, which for the case of infinite TWR, requires more deltaV than horizontal, so I see no reason why/how it would/could be better...

I had to revise my model to accept TWR < 1 Was quite simple though, just said theta = 90 degrees if argument into arcsin function is greater than one (so it burns fuel but does not move horizontally). Tylo tests seem spot on. Mun tests with TWR >> 1 seem significantly under-performing compared to model. Perhaps it is more difficult to properly aim completely horizontal and you wind up climbing too high? Mun tests with TWR <~= 1 are higher than model predicts is possible...

Did you ever post your results for TWR = 1? A comparison between your efficiency and that predicted by my model would be cool to see...

It would be really nice to see each Kerbal's specialty next to his name everywhere, that way when we are moving kerbals around and are looking for the extra pilot, we know which one to pick.... Alternatively, if putting their speciality causes too much clutter, a color code would be nice

Yes, K^2 has said that treating landings the same way as treating ascents is optimal since suicide burn is the same thing as vertical take off (though you do fall from a much lower height so it's kind of a hybrid approach). And K^2: isnt my work here the solution for finite TWR? I provide all the information you need to select optimum TWR Finally, I was wondering what method you've come up with to improve landing technique? If it's just the opposite of horizontal ascent, i imagine its harder to perform (since you have to maintain zero vertical velocity while avoiding terrain) plus it would be very, very difficult to predict where your landing site will be.... ?

Eve has TVR = 0.8, but yeah. Making TWR go up til 4 is still wasted space Also, for TWR = 1, a good correlation to use: eta ~= 1/log(2.488622+TVR^0.546581); Out of curiosity, if you have been testing TWR = 1, how do you not crash and how long do your tests take????? They take long enough at TWR = 1.1....