GoSlash27

But that's a crap design and nobody's going to find themselves in that scenario! That's *my* point. It goes back to "crappy rocket is crappy no matter which way you point it". Why would anyone in their right mind design a $10,000 heap with 5 (five!!) SRBs when they can do the job for less than $2,000, 1.4T total mass, and a half ton of liquid fuel?? And that's without really trying. And what monstrosity are you gonna use just to place that Edsel on the Munar surface? You gotta do the TMI hauling that ginormous payload, and get all of that off of Kerbin. And you think the differences between these two approaches will be "marginal"?? I'm half- tempted to expand the challenge to a full Munar mission from launch to splashdown and spot you the 1Km/sec+ advantage from running FAR, it's so bad. What started this whole ballyhoo was the idea that "maybe vertical launch isn't as awful as people think", but as a practical matter, it *is* awful. Not just awful, but truly *horrendous*. Sorry, -Slashy

I really have no idea what you're talking about here. Launching off of the surface at these angles, your math would hold true, but not in a vertical departure from the surface, which would be any *realistic* scenario. If the t/w is precisely 1, then at the instant of ignition nothing will happen. But as the fuel burns off, the ship will have t/w > 1, and the excess is used to provide horizontal acceleration IAW Pythagoras. It's not an "engineering miracle", it's common practice. The challenge is open to you as well, if you'd care to try your hand at it. Best, -Slashy

Arkie, Aye, but there's the rub: Any rocket that is *designed* to launch East is going to have a light engine and low t/w ratio, because a high t/w and heavy engine is completely useless for such a craft. Your argument is that a craft, if given a high enough T/W can out-perform another copy of itself by going vertical in this scenario... which could *possibly* be the case if t/w is sufficiently high, but it's a moot argument because any craft designed to go vertical will *by nature* be grossly inefficient compared to a craft designed to go horizontal in every category. So when you say the differences would be "minor", it would only be true if you happened to have placed a grossly inefficient pig of a rocket on the surface of the mun in the first place. FAR and stock are identical out of atmosphere, so we can directly compare results. I can build a rocket that will outperform your best vertical effort in every category of efficiency in the scenario you have proposed here. DV, cost, fuel consumption, total vehicle mass... everything. And the difference between these two vehicles wouldn't be anything you could call "minor".. The scenario is as follows: Place a vehicle of your own design (stock parts, no cheats) in the location you describe carrying a Mk.1 command pod as payload. Build it to be as efficient as you can and post the specs (mass, cost, fuel). Then escape from the Mun vertically and establish a periapsis within Kerbin's atmosphere. Again, post mass and fuel state. You may use solar panels to provide power, since they are massless. You may deduct the cost of the solar panels for the purposes of this exercise. You will not be charged for any parts you use to place the lander on the surface itself or decouplers to detach the launch vehicle from the lander, as placing the payload on the surface is not part of the test. I will do the same, but going horizontal. I guarantee my rocket will blow your rocket's doors off. Best, -Slashy

Arkie, Sorry, yeah I as referring to Kerbin. Your vertical launch would not have exceeded Vt, but your prograde launch would have. On an airless body, there is no question that Prograde is preferable. The math is greatly simplified, and the reason prograde is preferable is so simple, that you'll laugh when you hear it: DV on an airless body is merely a*t. When accelerating vertically, your acceleration is reduced by 1.63m/sec each second you burn, whereas if you burn horizontally, it's not. So if I were to accelerate at (say) 2G horizontally for 200 seconds, it would give me 652m/sec + 9 m/sec for the rotation. If you burn vertically at the same rate, you only get 356. Now... you can reduce this disparity by increasing acceleration, but the difference between the two methods can only approach zero as acceleration approaches infinity. it can never exceed it. But there's no good reason to add the mass of bigger engines, since the prograde burn will get optimal results with engines producing exactly local G acceleration at liftoff. There's no benefit to adding thrust in a prograde launch. Adding thrust in the vertical mode will reduce (but not eliminate) the disparity between the two modes in theory, but in practice any gains you get from increasing thrust will be erased by the penalty of the big engines required to produce it. Best, -Slashy

Just occurred to me: So now that you have established that 10G acceleration is sufficient to catch Vt in FAR, what acceleration is sufficient to maintain it? That's gotta be lower than 10 Gs, right? Wouldn't you expect that 2 Gs would be sufficient? Best, -Slashy

Ferram4, I think this is what was dominating my thought process; I was so focused in on the Cd that I was forgetting the velocity^2, which is the dominant factor. Sorry for the headache! -Slashy

^ Addendum to the above... After establishing that the prograde profile is much more efficient than the vertical, it should then become apparent that using engines with enough thrust to generate 10 Gs of acceleration in the prograde mode is wasteful, since you don't need anywhere near that mass of engines. Taking this into account would make the disparity even greater. Best, -Slashy

Arkie, Given the results you've achieved in the t/w ratio thread, you might want to revisit this. Assuming a 10G thrust is sufficient to achieve Vt in the vertical mode, you could test such a craft for total DV to munar apoapsis, then compare it to the results you'd get from the same craft when flying prograde and throttling back to maintain it's Vt. I think if you do it that way, you'll see more disparity in total DV between the two methods than you had before. This is what I had done in my test; the vertical launch was conducted at 2G acceleration, while the prograde test was done with the acceleration roughly proportional to the sine of the pitch angle. Your previous test had you going full throttle in the prograde maneuver and you lost a ton of DV due to drag. Best, -Slashy

Arkie, After pondering this (haven't seen the video yet), I've concluded that your approach must, indeed, be correct. The free-fall terminal velocity for a craft would be the point where the total drag equals the weight, so successive approximation like you have shown can find it. I think the light bulb finally went on. Sorry for all the confusion! *edit* just watched the video, and yeah, I think we can definitely put this to bed. Thanks! Best, -Slashy

Your response was posted to an earlier edit of my post. I will wait for you to confirm that you stand by this before we proceed. *edit* crap! Gotta update mine too! Best, -Slashy

Apologies, as your response was posted before mine. I *would* expect the prediction itself to converge though I would not expect the prediction to converge on a value that is below the current velocity. Your example above shows otherwise. So now with this new information in hand, would you state that the ballistic Vt for your vehicle at 10Km is 1,962 m/sec? That is, the velocity that it would stabilize at in a homogenous pressure of .165kPa with 1 G of force applied? Best, -Slashy

Actually, your math works out the way I predicted it would. See above. Now that you're home, I'm looking forward to seeing your attempt to make the Vt readout indicate that you have achieved Vt. Best, -Slashy

Because the acceleration affects the velocity a vehicle has attained at a given altitude. It could be going 100 m/sec, or 300 m/sec, or even 3Km/per second, depending on the acceleration that got it there. Each of these objects will exhibit a different Cd due to it's velocity. I'm not talking about where the velocity actually trends, which is absolutely correct by your math and as it should be. I'm talking about where the *predicted Vt* trends. It goes above the current velocity, not below. Your formula says "this is my velocity, so this is my Cd. Using this Cd, the terminal velocity is blah". But the assumed Cd is too low, so the predicted Vt is too high. And the predicted Vt is always higher than the current velocity. Assuming the Cd of the predicted Vt will always result in a lower prediction of Cd, which will result in an even higher prediction of Vt. The aerodynamics work fine, it's the prediction that goes haywire. If you feed in a Cd lower than that of an object actually *traveling* at that velocity (in the supersonic regime), the prediction diverges from the correct answer.

Close, but you converged on the *same* solution, which would be expected. Doesn't mean that it's "correct" if your initial assumption is higher than the actual Vt. I already have the explanation

ferram, Gettin' a bit rude here. I know the feeling, so please bear with me. in FAR, Cd is a decreasing function with Mach when you're supersonic. That's by your own submitted formula. The faster you go, the lower your Cd. That's all well and good, but what happens when your velocity is higher than the ballistic terminal velocity? Say you had an object at 10Km altitude that had been accelerated at one G until the drag had equalized with the thrust and equillibrium had been achieved. That is your ballistic terminal velocity for that object at that pressure/ temperature. Say (for the sake of argument) this value was 600 M/sec. What happens when you attempt to calculate this velocity from an object that is travelling 800 m/sec? That object has a lower Cd due to it's higher Mach number. If we calculate the Vt of an object with that lower Cd, it will return an even *higher* value. If we attempt to iterate it, it gets worse, not better. You can't calculate Vt assuming the Cd of an object that's already going faster than it. You just can't. That's my point. Best, -Slashy

Ferram, I'm not referencing *any* equations for this beyond what has already been provided here. Current acceleration is *not* a factor in computing free-fall terminal velocity. Likewise, current velocity is not a factor in computing terminal free-fall velocity. Or at least it's not *supposed* to be, and that's the problem. Any attempt to estimate it based on current velocity and Cd in FAR *does* make it a factor because it assumes that the current Cd is valid in that scenario, and it's just plain not. Thus, it gives you an incorrect answer. When you're supersonic that error will always be positive.

I don't want to derail the experiment by getting us off on a tangent, but you're using the "current velocity" as a seed value when the "current velocity" wasn't achieved from 1G acceleration in the current atmospheric density. Your iteration will always scale upwards because you're supersonic and thus Cd decreases the faster you go. If you put in a higher seed value (say, by having climbed at 8 Gs instead of 5) it will iterate to an even *higher* terminal velocity. If you put in a lower seed value, (say by having climbed at 3 Gs instead of 5) it will iterate out to a lower terminal value, but still well above your current indicated speed. It is based on the assumption of current velocity, *not* the velocity the ship would have actually been going had it been at the actual 1G free fall terminal velocity. The error in this approach is exactly the same as it is with the FAR readout. No matter what "current velocity" you feed into it, it will *always* spit out a higher velocity as it's estimation of the free-fall terminal velocity. It is therefore useless as an indicator of when you have truly achieved free-fall terminal velocity.

I'd like to bookmark this and revisit it, as it contains a major flaw, but to avoid getting us off on a tangent, I'd like to continue with the current thought experiment. You have proposed that the Vt display will show a lower value than your indicated airspeed at 10KM if you accelerate at 10G. Could I convince you to try it? It'd be really helpful if you did, but if you don't want to, then we don't really have to. Actually, it would simplify everything *tremendously* if you would humor me and try it. I'm keen to see what the new numbers look like, and I expect it'll be a real eye- opener for you.

If it's "inaccurate", then it's not displaying it. Okay, so 10 Gs acceleration. I don't suppose I could convince you to test that theory out, could I? Actually accelerate a rocket vertically at 10 Gs and see if the indicated speed actually does exceed the Vt display? I bet it wouldn't.

You said that even though the display doesn't display the free-fall terminal velocity, that it would still indicate the relationship between your current velocity and the free fall terminal velocity; that it would read higher than your current velocity if you had not yet reached free-fall terminal, and lower if you had exceeded it. So exactly how rapidly do you have to accelerate in order to exceed the free-fall terminal velocity and thus have this display read a lower velocity than your current velocity?

Actually, you haven't calculated it. You need to calculate it the hard way. I believe somebody had posted a chart of the relationship early in this thread. If we can't hash it out this way, we can try a thought experiment... How rapidly would you have to accelerate in order to get that display to flip? 10G? 300G? 3,000?

This, right here, is the crux of the matter. You would think it would, but it doesn't. Approaching Mach 1 makes your Cd increase, while accelerating beyond Mach 1 makes your Cd decrease. Concurrently, your displayed terminal velocity will diverge from your *actual* terminal velocity will seem lower than it really is as you approach Mach 1, while it will seem higher the more you exceed it. Therefore it is actually possible to exceed your free-fall terminal velocity without ever having seen the display flip. This is what's happening to you. Case in point; during your video at, say, 10Km, your velocity is 660M/sec. Were it revised to reflect your Cd *at* the actual terminal velocity, it would show you're actually twice your terminal velocity, but the display suggests that your Vt is 1,270. It says you should be going faster, but you should actually be going slower. Try calculating it out. What would your ship's 1G terminal velocity be at 10km? ÃÂ=0.165 kPa.

You are very passionately arguing the exact same thing I've been saying for the last I-don't-know-how-many pages now. This should be bolded and stickied. The display isn't showing a terminal velocity using the terminal Cd, but rather the *current* Cd. It is therefore misleading for the purpose arkie was using it for. The assumption that approaching your terminal velocity would be reflected in that display is erroneous because it's displayed "terminal velocity" will always exceed your current velocity no matter how quickly you accelerate. In fact, the more rapidly you accelerate, the more rapidly it will appear to increase. Even when you've left your free-fall Vt far behind, it will still read a velocity far ahead. You just plain can't use that display to determine an optimal launch profile.

"None of these variables are in any way dependent on the current velocity" And *this* is why you're mistaken. In FAR, Cd *is* dependent on the current velocity.

The problem with your point above is that it's not gonna work that way. Your assumption is that if you ever approach Vt (Vt in the sense that Starman thinks I don't understand), your display will become correct and would reflect that you've exceeded or met it. In reality, the instantaneous value is going to run away and hide no matter how rapidly you accelerate, so *it* will still be much faster than your current velocity even if you've already exceeded your free-fall Vt at your altitude.