arkie87

So in 0.90, you get rescue missions before you can set the poor kerbal as a target. I think i need to upgrade mission control to get patched conics, but i dont see anywhere what i need to be able to set a target (unless that's patched conics as well). I was wondering if anyone tried rescuing someone without patched conics... i tried but kept on overcorrecting until i was nearly out of fuel ...

you can also click on location in map screen ONLY (not tracking station), to add a marker to your navball

First of all, i think i used more than 10G's to get to terminal though less might have sufficed.... I have no idea... i would need to test it... I can imagine it might be sufficient for a while, until you get high enough that terminal velocity increases too fast to accelerate too. This happens with stock aero too (i sent you a graph of it), however, for both stock and FAR, it probably occurs during gravity turn (in FAR, gravity turn begins right away anyway).

I think it's important when debating to pause for a minute and seriously consider the other person's perspective, rather than rushing off to a rebuttal. I readily admit that I can be guilty of that to, but i can say with certainty that in this debate, I seriously considered your side, read and re-read your posts (to make sure i wasnt misunderstanding you, which will just lead to frustration on both sides) and even thought I was wrong a few times through the course of the debate (I even mentioned it once). That said, I'm glad it's over

So to confirm i understand, you are talking about LKO not LMO (this thread is about LMO)? You essentially want me to confirm that terminal velocity is most efficient in FAR i.e. if my TWR is scaled up for FAR i.e. like 10+, then i will indeed need to back off the throttle, just like in stock. I dont see the pressing need to do this. How did i lose a ton of deltaV due to drag, if i was below terminal velocity the entire time? This is once again referring to the Kerbin case and not the Munar case, which this thread is about. Regardless, I agree. My point, as others have said (in one of my threads ), is that increasing TWR increases deltaV due to burn becoming more like an impulse, but require more mass, and so reduce deltaV as well. Which one is larger depends on the circumstance. Furthermore, I am not arguing this case. I am arguing, for the Kerbin case, that with a given vehicle with high TWR already. In career mode (before 0.90), all we care about is kerbucks, not mass or complexity or efficiency. In practice, SRB's are dirt cheap and easily increase TWR. So whereas one skipper costs 2850 without the fuel, the tallest SRB costs only 1800, with the fuel!! Thus, it's probably cheaper to go with SRB's, which already will have high TWR, with FAR aeryodynamics. As a side point, in stock, high TWR is a waste of fuel since it cannot be utilized while climbing (until you reach gravity turn) since terminal velocity is soooooo low. However, 5thHorseman will argue that even if you are using SRB's with FAR installed, it pays to throttle them back (before launch) and do a gravity turn and forgo the extra thrust, which is available at 0 mass increase; if i had a mainsail, no one would tell me i should reduce the thrust to be equivalent to a skipper, since i have already paid for the weight of a mainsail!

How are my displays dodgy? can you elaborate? Even if you dont trust KER, its clear that for LKO burn, i used just about the entire first stage. And for vertical burn, I used entire first stage plus a bit of second stage... so even if you dont trust deltaV values, you have to trust fuel usage, which says they are really close. I could be talking about either raising periapsis first, or not. It doesnt matter too much, since, it is my understanding, they are close either way. My discussion isnt hypothetical at all.... I have provided calculations (and a video, if you are referring to LKO; many videos if you consider related arguments). Calculations or actual trials are hard data. Even logical arguments can be accepted under certain conditions (since they can be refuted). But what i oppose, is people merely asserting that they are right and I am wrong, without giving any reason whatsoever. Not sure why #2 is an advantage? Unless you mean shorter burn time, which is the advantage of high TWR in general, not vertical ascent. If we are talking about in a vacuum i.e. Mun, then yes, there are no other advantages... Also, while on earth, burning vertically will cause you to travel approx 100 km during ascent before engines need to cut out, burning vertical from Mun might take you just as far (a bit less since acceleration will be faster due to higher TWR), and 100km is one Mun radius, so gravity drops by 4. #1: It is not a gravity free acceleration, unless you assume impulse burn. You have to accelerate up to orbital velocity, at the very least, while aiming at the angle necessary to prevent you from falling, which is wasteful. #2: I dont follow. the advantage of LXO, is that once you are in a stable orbit, you can burn perpendicular to gravity to avoid gravity losses. So the advantage of of going to LXO first only comes if periapsis burn is large enough #3: I dont see what time has to do with it, persay. And i dont think you can say definitively the paripasis will have less time spent in SoI, since vertical goes straight up to SoI exit, while LXO approach has to swing around the entire planet first (even if it's going faster, though i dont think it is-- escape velocity is a function of altitude and, as long as you dont hit the planet/atmosphere while doing it, the direction you choose )...these are "hand waivy" logical arguments. And I can think of hand-waivy logical arguments which could provide the other conclusion. Thus, i much prefer either hard trials or math. Yes, I agree and having been saying this the entire TIME (pun intended). It is actually my origional argument. And it's not about overall time, only about time spent burning (since fuel flow is constant). Yes, this is the main advantage of LKO; you can burn in stable orbit where due to centripetal forces, gravity is essentially zero. Thus, low TWR and more efficient engines can be used, saving mass thereby increasing deltaV. I am not arguing with that point. That is a great attitude to have

On second thought, cost of parts might be different, if balance of the career mode has changed. Can you verify you craft has not changed price?

How are my dV calculations wrong? I report that vertical is less efficient, not vice versa (but only marginally)? And i try to adjust for the overshoot with the maneuver node as best I can...

I just played the game and i can see markers on the map (in map view by pressing M and in tracking station as well). you do not need to upgrade anything. Also, if you click on these markers in map view, you can click "add to navigation" and then an icon will appear on the navball to show you how to get there.... You do not need to cheat and go into biome menu.

I doubt anything has changed between 0.9 and 0.25. But right now, i cannot get access to FAR for 0.90 so module manager wont enable it... so i have to wait... And of course i was aware that deltaV requirements are different. That's why i was asking. If you were using stock, i could build a better rocket with FAR without trying :-P

Also, were your tests done with 0.25 or 0.90

No. The Cd vs Mach relationship i used is made up since i did not yet receive the information from Ferram (at that point in time), and the actual one used by FAR is a lot more complicated and i'm not entirely sure how to evaluate it since it must be applied to all parts carefully. But what it does contain is the same relationship between Cd and M when M>1, that is, a proportional to 1/M relationship.

So i found an old version (0.24), and luckily, i kept FAR for this version (since FAR hasnt been updated yet, probably because we have been bothering him-- sorry everyone!), so i was able to do your test. Watch the video: Can we put this to bed yet?

I never thought i would say this but, DAMMIT! THE NEW VERSION OF KSP CAME OUT AND NOW I HAVE TO UPDATE ALL MY MODS BEFORE I CAN TEST THIS! But i am excited for the new version of KSP Video will come. I only need to update FAR to do this test...

If it converges, it converges to the correct and only solution.

Yes, i think me and 5thHorsemen discussed before that having the same apoapsis isnt fair since lko method will have less velocity relative to the mun when it arrives, and will therefore, require less deltaV to get into an orbit. Which aerodynamics model are you using, 5thHorsemen? You have to be using FAR or the tests will not be comparable (if i use stock, then my method will not work since terminal velocity is a killer in stock).

What you are talking about is whats know as an "initial guess". Dont say acceleration since it is confusing given your previous arguments. The acceleration of the craft gives it a different initial guess, so just say initial guess. Predicted Vt trend is correct as well. Look at my table again: After the first iteration of my algorithm (which is what FAR does for its prediction-- only ONE iteration), Vt prediction goes from 3000 m/s to 2400 m/s, thus, it DOES go in the correct direction even if initial guess is above Mach 1 and above actual terminal velocity.

Yes. This is the reason why.

Best explanation is this: While drag coefficient decreases with increasing Mach for M > 1, drag force always increases with Mach (this should be self-evident from the fact that drag force is proportional to Cd V^2 and Cd is proportional to 1/V when M > 1, thus, V^2 trumps 1/V and drag force still increases). Below is a plot of drag force (blue line) vs. velocity. The green line is weight (40 ton craft). The intersection of these two lines is terminal velocity--- 1961.8 m/s. - - - Updated - - - False. There is only ONE solution. See graph of Drag force vs Velocity. False again, because if the iterative method converges, it converges to the correct solution, regardless of the initial guess. Besides, from your logic, if our initial velocity is larger than V_t, V_t will only increase with subsequent iterations, but when we try iterating, as you suggest, it doesnt... Maybe you need me to remind you what you just said: And i did exactly what you recommend, but the math does not work out the way you describe. It works the way Ferram describes

So i thought about what he said on my ride home, thinking that he had a point: what he was saying is that the iterative method isn't stable when mach number is greater than 1 and when your initial guess (i.e. craft velocity) is greater than terminal velocity (assuming we know what terminal velocity is somehow) because it causes V_t to go in the wrong direction due to he logical argument i'll present below. Thus, the method FAR uses-- one iteration in this iterative method--is actually predicting a completely unrealistic value, since if FAR let it iterate indefinitely, it will not converge to the solution, but rather, diverge to infinity. The basic reasoning is that let's say (using my made up Cd vs Mach number relationship since I am still working on yours, Ferram ), we are able to determine that V_terminal = 1961.8 m/s (since my method converged, we know it is the correct answer for terminal velocity). If we happen to be going above that value: say 3000 m/s, FAR will calculate drag coefficient at 3000 m/s, which results in a lower Cd, which should result in a larger terminal velocity; the next iteration, the larger terminal velocity will result in an even smaller drag coefficient, which will then increase terminal velocity yet again until terminal velocity approaches infinity and drag coefficient approaches 0. However, to my surprise, this isnt what happened; it still converged to the correct solution: 1961.8 m/s. Here is the table of the results on a per iteration basis: Thus, even though my initial guess was above terminal velocity, it was still able to converge to the correct solution despite he logical argument i just made (and that I think you are making). I am still working on an explanation... I agreed with you! Until i tried actually iterating! See above!

T is constant or T has some profile? gamma = 1.4 T=300 K R=287?

I will test it when i get home. Meanwhile, I'm dying to hear what the major flaw is...

Question about the *= format: Cd *= 1 + 0.4 * e^(10 * M - 10) means: Cd = Cd*(1 + 0.4 * e^(10 * M - 10) ) Correct? If so, what is initial value of Cd? 0.003? What is aeraNode/refArea (i assume 1 for this graph)? And is this term active if a rocket is placed on the backside? If so, below is my graph of Cd vs M that FAR uses for Rockets: Can you confirm this looks correct? If areaNode/refArea is 4 since the leading edge of the rocket is small (1.25 diameter) and the trailing edge is large (2.5m), then my graph looks like: Are either of these correct?

Thanks, i will update matlab code with these values shortly...

Ok. I have made a model in matlab to calculate this exectly (which is similar to what FAR would have to do to get accurate results for terminal velocity display). First, i had to make an assumption for the relationship between Cd and Mach (i have assumed speed of sound is 343 m/s). I have defined it as a peicewise function: If Mach < 0.8 (a placeholder value for critical_mach number): Cd = 0.2 + 1/8*M If 0.8<Mach < 1: Cd = 0.3 + (M-M_crit)/(1-M_crit)*0.7 If Mach > 1: Cd = 1/M The graph of this function looks like this , and is realistically looking: http://upload.wikimedia.org/wikipedia/commons/0/0e/Qualitive_variation_of_cd_with_mach_number.png I have then wrote a matlab code which will use current velocity as a guess value for drag coefficient, which it will then use to calculate terminal velocity. It will then iterate until the terminal velocity used to calculate the drag coefficient returns the same terminal velocity. This takes about twenty iterations: As you can see, V_t increases from its initial value since it is over estimating the drag force, not underestimating it. Furthermore, after 20 iterations, the terminal velocity value we have calculated is correct, since if we compute drag coefficient using it, and then use drag coefficient to compute terminal velocity, we arrive at the same number...