Jump to content

Effect of initial TWR on orbit dV cost


Recommended Posts

a_r is negative, due to the radial unit vector changing direction (in the Cartesian plane). But even so, this means you accept the form of the equation I've provided, which includes the V^2/R term i.e. centripetal lift...

LD has already addressed this, but to clarify: in my example, your V^2/R term is the only non-zero term present in a_r - and it's negative (technically positive, but a negative sign's stuck in front of it in a_r)! Since a_r is the acceleration along the radius vector, a negative term corresponds to a "downward" force. That means gravity, not lift (of any kind): lift would be an "upward" force counteracting gravity, or in other words a_r would have a positive term, which it does not for a circular orbit. Is this clear enough for you?

As to whether or not I accept the equation, it's printed in your textbook which I assume passed through at least basic verification steps before being published. Additionally the equation fits with what I would expect acceleration along the radius to look like - change in r over time (in polar coords) plus gravity, so unless I were simply being thorough, I have little to no reason to question it. Technically you could say this is really an "argument from authority" fallacy, but in this case the "authority" is most likely correct. What I disagree with is your interpretation, not the equation itself.

LD: I would happily test this on video for you, the only problem is my (ancient) computer lags playing KSP normally if I'm moving too fast close to the surface or there's a lot of parts on screen, and sometimes just for the hell of it. Recording software on top of that would just be unbearable. :( The "dot" notation for time derivatives is actually quite standard though, if a little bit strange. I'm a little surprised you haven't seen it before but I guess it's not terribly important :)

Link to comment
Share on other sites

LethalDose:

The simplest way to explain the need for the "centripetal lift" term is the following:

Consider a spacecraft at orbital velocity. By definition, this is the velocity where V^2/R = g. If you leave the spacecraft alone, it will orbit in a circle. If you try to calculate the thrust angle needed to balanced gravity from phi = asin(m*g/T)=asin(1/TWR) you will arrive at a non-zero thrust angle from the horizontal/prograde. This is clearly not correct since at orbital velocity, one can burn at horizontal since gravity is canceled by centripetal lift term.

I have made a 2-D Cartesian model that integrates the second-order equations of motion (for position and velocity in x- and y-coordinates). The mode assumes infinite ISP engines, such that mass is constant (not a function of t) for simplicity, and is always equal to 1. For these conditions, if we neglect centripetal lift, the angle, phi, above horizontal needed to cancel gravity would be constant since TWR does not change during flight.

The governing equations of motion are:

a_x = T*cos(pi/2 + theta - phi) - g*cos(theta)

a_y = T*sin(pi/2 + theta - phi) - g*sin(theta)

The angle, phi, is calculated from:

phi = asin(g/T);

The trajectory is as shown below:

e0A5h2X.jpg

It is clear the spacecraft lifts off the planets surface since the angle is steeper than needed due to centripetal lift.

On the other hand, if we calculate the angle from:

phi = asin((g-v^2/R)/T)

The trajectory is as shown below:

Dr8uFMH.jpg

It is clear that the spacecraft stays on the surface, as expected.

Link to comment
Share on other sites

LD has already addressed this, but to clarify: in my example, your V^2/R term is the only non-zero term present in a_r - and it's negative (technically positive, but a negative sign's stuck in front of it in a_r)! Since a_r is the acceleration along the radius vector, a negative term corresponds to a "downward" force. That means gravity, not lift (of any kind): lift would be an "upward" force counteracting gravity, or in other words a_r would have a positive term, which it does not for a circular orbit. Is this clear enough for you?

See this response:

This term is negative, but it is on the same side as m*a (i.e. inertia side); when we bring it over to the sum(F) side, it becomes a positive force :wink:

In order to be considered a "force" it has to be on the same side as the sum(F) i.e. force side.

It starts off as negative on the inertia (i.e. m*a) side. We have to switch it over to the force side to treat it like a force, and when we do that, it becomes positive.

I assume now you see how ridiculous this post was:

I'm sorry arkie, but I feel compelled to educate you on basic mathematics: Let's assume a perfect circular orbit, then r is a positive constant, which means r'' is 0. Now, v_theta is a real number (i.e. not a complex one), which means v_theta^2 is positive (or 0 - but this is a very odd case), which means a_r is negative (or 0). The only explanation for this is gravity; the fact constants are not mentioned is irrelevant, because these are absorbed into the v_theta value.

I wouldnt recommend responding this condescendingly or rudely, especially since if you are wrong, it will make you look like a fool :wink:

Link to comment
Share on other sites

In order to be considered a "force" it has to be on the same side as the sum(F) i.e. force side.

It starts off as negative on the inertia (i.e. m*a) side. We have to switch it over to the force side to treat it like a force, and when we do that, it becomes positive.

Okay, now I see how you're misunderstanding this. First off, I said the acceleration has a *corresponding* force, not that actually is one, however, you convert acceleration to force via F = ma. Every high school physics student knows this (or should). Rearranging the formula is not how you convert to force, you do that by multiplying both sides of the equation by m; your equation is in the form "acceleration1 = acceleration2 + acceleration3", where acceleration3 is negative. Remember a force and its corresponding acceleration are always in the same direction.

I wouldnt recommend responding this condescendingly or rudely, especially since if you are wrong, it will make you look like a fool :wink:

This applies just as much to you as it does me, good sir.

Edited by armagheddonsgw
Link to comment
Share on other sites

Okay, now I see how you're misunderstanding this. First off, I said the acceleration has a *corresponding* force, not that actually is one, however, you convert acceleration to force via F = ma. Every high school physics student knows this (or should). Rearranging the formula is not how you convert to force, you do that by multiplying both sides of the equation by m; your equation is in the form "acceleration1 = acceleration2 + acceleration3", where acceleration3 is negative.

This applies just as much to you as it does me, good sir.

Yes, you convert acceleration to force units by multiplying by m, but this is not what we are discussing.... lol

sum(F) = m*a_r

From the textbook:

a_r = r_dot_dot - V_theta^2/r

So, substituting this identity:

sum(F) =m*(r_dot_dot - V_theta^2/r)

Re-arranging:

m*r_dot_dot = sum(F) + m*V_theta^2/r

The term m*V_theta^2/r is positive when on the "force" side of the equation, therefore, it acts as lift...

Link to comment
Share on other sites

Arkie, sum(F) is "the sum of all forces acting on the object". m*V_theta^2/r is already included in that list - and it's gravity. You rearranging it like that just isolates the forces that are retained in polar coordinates, which normally "removes" gravity (in a sense) since your motion in a circular orbit is constant r with theta changing at a constant rate (namely your angular speed in the orbit - sidestepping the detail that the actual value of this speed depends on the strength of gravity).

EDIT: I somehow missed this line:

The term m*V_theta^2/r is positive when on the "force" side of the equation, therefore, it acts as lift...

Both sides of the equation are forces. The only difference is one side has an explicit expansion in terms of F = ma.

Edited by armagheddonsgw
Link to comment
Share on other sites

V_theta^2 is not gravity. r'' is the second derivative of r, ie its actual rate of r velocity change. a_r is the acceleration generated by true forces in the r dimension - in the case of a free-orbiting body, this is gravity, with negative value. V_theta^2/r is an emergent term from the coordinate transformation and does not truly exist as a force, but must be considered as one when simplifying to a polar coordinate system to allow altitude to only be considered in a single dimension.

So, rearranging to represent the actual resultant r'', which should equal zero for a circular orbit, we have r'' = a_r + V_theta^2/r. We have established that a_r is negative, and that V_theta^2 is positive, meaning r'' can be 0, the first requirement. Further, if you go to basic orbital equations, you will be able to find very clearly from thoroughly derived and undisputed equations that v_orbit^2 = g*r. Which, substituted in as v_orbit = |V_theta| and -|g| = a_r, results in r'' = 0, as required. Arkie is correct, and not accounting for this factor when using polar coordinates is incorrect.

PS. It's misleading to claim it's 1.5% error. The absolute minimum possible usage is direct escape velocity, and these equations are for deriving how little above this a particular craft can be - so to give fair representations of % error, you should take model and actual results minus ideal Hohmann transfer.

Edit: just in case anyone can't do a substitution required above, or can't figure out the relevant equations, you should be able to find v_circ = sqrt(GM/r), and g = GM/r^2. These go to v_circ^2 = GM/r and g*r = GM/r, thus they are equal.

Edited by Iskierka
Link to comment
Share on other sites

/snip

First, phi should be asin(mg/T), not asin(g/T). It's correct in the first paragraph, but in your definition 2 lines above the first figure, it's incorrect, which concerns me since the semi-colon leads me to believe it was taken directly from code...

Second, even if that's correct in your code, I think the figures are misleading, for reasons of scale if nothing else. The planetary radius here is 600 km, where all examples have been given for the Mun, with a 200 km radius. The burns you're showing here are taking place over >250 km, which is way more than the burns given as examples, but our burns occur over on a smaller globe. This makes it very difficult to compare.

As I've stated before, take place over ~ 50 - 60 km for the Mun example, which is < 5% of the Mun's circumference (~ 15 degrees longitude at the Mun's equator). Over such short distances, the natural change in altitude that occurs because, you know, ellipse, is incredibly minor, and the assumption for constant altitude holds well. When you start stretching the distance traveled because you built a crap vessel with terrible TWR, that assumption starts to fall apart. The model strongly discourages that kind of design, so doing it anyway is really nothing more than willful ignorance the larger picture...

It's slightly less accurate around the edges, oh well.

Finally, yeah, I think I get what you're calling "centripetal lift", but it's not a force, hence, it's not lift. And because of the short distances we're dealing with, it's not an issue.

Until you show a rigorous derivation of it using clear notation, there's no further use for discussion. You have your own thread for that method already. Please keep the discussion there, where it belongs.

Link to comment
Share on other sites

Edit: wait this is silly heh, it is pretty easy to test. If you want improved accuracy and to know the flight path is correct, why don't you try it yourself?

Good question...

It's much simpler to execute the test yourself than it is to invent reasons to reject other people's results.

Merry Christmas,

-Slashy

Link to comment
Share on other sites

V_theta^2 is not gravity. r'' is the second derivative of r, ie its actual rate of r velocity change. a_r is the acceleration generated by true forces in the r dimension - in the case of a free-orbiting body, this is gravity, with negative value. V_theta^2/r is an emergent term from the coordinate transformation and does not truly exist as a force, but must be considered as one when simplifying to a polar coordinate system to allow altitude to only be considered in a single dimension.

So, rearranging to represent the actual resultant r'', which should equal zero for a circular orbit, we have r'' = a_r + V_theta^2/r. We have established that a_r is negative, and that V_theta^2 is positive, meaning r'' can be 0, the first requirement. Further, if you go to basic orbital equations, you will be able to find very clearly from thoroughly derived and undisputed equations that v_orbit^2 = g*r. Which, substituted in as v_orbit = |V_theta| and -|g| = a_r, results in r'' = 0, as required. Arkie is correct, and not accounting for this factor when using polar coordinates is incorrect.

This made a huge amount of sense. Thank you for clearly explaining these terms. It also makes sense that the term would appear in a properly rigorous derivation when transforming to polar coordinates.

Now am I mistaken in that what I presented in the OP is in a linear frame of reference, instead of rotational? Or am I asking the question incorrectly?

It was written assuming the vessel travels in a straight line, not a curved path, due to minimal curvature of the planet over which the burn occurs. Hence a Cartesian coordinate plane and no need to account for this "phantom term".

Seriosly, thank you for providing this explanation. Have some rep.

PS. It's misleading to claim it's 1.5% error. The absolute minimum possible usage is direct escape velocity, and these equations are for deriving how little above this a particular craft can be - so to give fair representations of % error, you should take model and actual results minus ideal Hohmann transfer.

Eh, I'm disinclined to agree with this statement, primarily because the point of the exercise was that the Hohmann transfer is impossible to make in the first place. The purpose of what's presented is not to prove that method described is the most efficient method for making the burn, it's simply an assumption of the equation.

Link to comment
Share on other sites

Good question...

It's much simpler to execute the test yourself than it is to invent reasons to reject other people's results.

Merry Christmas,

-Slashy

Wow, kettle, pot...

To which you'll simply state I did it wrong on purpose because I'm biased.

You made the claim the method is repeatable, onus of proof doesn't lie on me.

It's easier for you to just take a video to prove your claim.

Link to comment
Share on other sites

Now am I mistaken in that what I presented in the OP is in a linear frame of reference, instead of rotational? Or am I asking the question incorrectly?

It was written assuming the vessel travels in a straight line, not a curved path, due to minimal curvature of the planet over which the burn occurs. Hence a Cartesian coordinate plane and no need to account for this "phantom term".

What you presented was inherently polar, as it is considering altitude rather than x/y coordinates. Your attempt at a "stripped-down" cartesian model has partial validity, as it does tend to the same answer, as proven by the fact the models are identical at infinite T/W ratio. However, it doesn't take much for significant errors to creep in.

To cite, you say the burn takes place across roughly 15 degrees of the Mun's surface. Go and play with cos and sin functions at 15 degrees - at such a small value, already the force of gravity in the ignored direction is over 25% of total magnitude. In the considered direction, the surface is now more than 7 km below you if you started at 0, and even without accounting for reduced gravity due to this altitude, you've lost 3.5% of the gravity in the considered direction.

There's a number of other factors relating to considering the curve, but just those quick numbers should show that things are changing rapidly, and over burns even that short, error is building up. While the semi-cartesian estimate gets a guess for infinite or very high T/W, to get a good answer at sensible T/W, either a full cartesian (which can be more confusing), or polar (which just requires a small coordinate refactoring) needs to be used.

Link to comment
Share on other sites

Wow, kettle, pot...

To which you'll simply state I did it wrong on purpose because I'm biased.

You made the claim the method is repeatable, onus of proof doesn't lie on me.

It's easier for you to just take a video to prove your claim.

Well I personally don't care about proving a point, I was just curious myself, which is why I tried out slashy's experiment for myself xD I'm just saying, if I personally spent hours working on an equation, I'd want to test it out. Whether you post it to the forums or wish to discuss it is another matter. I mean, we're not ancient greeks here ;)

Although to be honest, if the aim of the equations was to just prove that excessive TWR doesn't really provide much improved efficiency, it's not like arkie's does either, in fact arkies says that efficiency drops off even sooner, so I'm not sure there's much merit in really doing all this arguing :/

But I guess "someone's wrong on the internet!" heh.

Edited by Greep
Link to comment
Share on other sites

Well I personally don't care about proving a point, I was just curious myself, which is why I tried out slashy's experiment for myself xD I'm just saying, if I personally spent hours working on an equation, I'd want to test it out. Whether you post it to the forums or wish to discuss it is another matter. I mean, we're not ancient greeks here ;)

Although to be honest, if the aim of the equations was to just prove that excessive TWR doesn't really provide much improved efficiency, it's not like arkie's does either, in fact arkies says that efficiency drops off even sooner, so I'm not sure there's much merit in really doing all this arguing :/

Yeah, pretty much this.

I don't give a flip *which* model is more accurate (I'll shamelessly apply either one to my efforts), but LD and Arkie were fighting over it and I provided a data point. Arkie's model (for whatever reason) serves as a lower bound for my results and LD's doesn't.

LD wants to reject it, that's his business... but if I were in that situation and didn't trust other's results, I'd run the test myself.

Merry Christmas,

-Slashy

Edited by GoSlash27
Link to comment
Share on other sites

First, phi should be asin(mg/T), not asin(g/T). It's correct in the first paragraph, but in your definition 2 lines above the first figure, it's incorrect, which concerns me since the semi-colon leads me to believe it was taken directly from code...

Didnt have time to read the rest (i will later tonight), but in my code, I'm using m = 1 for simplicity, so my formula is correct. :D

Link to comment
Share on other sites

Well, now that we've sorted out the issue with "centripetal lift", I figured I might put my degree to use and have a crack at equation 17 like OP actually wanted :cool: (apologies for the incredibly ugly text notation):


I took the rearranged version from immediately after the (17) label - it seemed easier to work with.
equation 17: exp(deltaVp / (g0 * Isp))(1 + sqrt(1 + TWR0^2))/m0 = (1 + sqrt(1 + (g * m_end)^2)) / m_end
goal: rearrange for m_end.

There's a lot of ugly variables in the way, so let's get rid of most of them to make life way easier:
Let E = exp(deltaVp/(g0*Isp))
A = E * (1 + sqrt(1 + TWR0^2)) / m0

Substituting:
A = (1 + sqrt(1 + (g * m_end / F)^2) / m_end
A * m_end - 1 = sqrt(1 + (g * m_end / F)^2) // multiply both sides by m_end, move the 1 over.
(A * m_end - 1)^2 - 1 = (g * m_end / F)^2 // square both sides, move the 1 over.
A^2 * m_end^2 - 2A * m_end + 1 - 1 = g^2 * m_end^2 / F^2 // expand all the things!
(A^2 - (g/F)^2) * m_end^2 - 2A * m_end = 0 // Behold! we have a pretty quadratic!

But there's still some constants that make it a bit harder to read:
Let B = (A^2 - (g/F)^2)

Substituting:
B * m_end^2 - 2A * m_end = 0
B * m_end - 2A = 0 // we can disregard m_end = 0 since it's not realistic
m_end = 2A / B.
= 2A / (A^2 - (g/F)^2). // uh, yeah. you're on your own from here (it's ugly. very ugly.)

disclaimer: I make no claims as to the correctness of this, and it was all done in notepad using my head. :)

If however this is indeed correct, WolframAlpha's apparently not very good with big equations with lots of variables :(

Link to comment
Share on other sites

This is looking like great work LD. Keep it up!

If I ever take some time away from bug hunting/squashing, I'll have to take a more in depth look to give more detailed feedback. But what I'm seeing so far looks great. :D

Hopefully you can pull together more of the community to help collaborate on this project.

Cheers,

~Claw

Link to comment
Share on other sites

The purpose of this forum is to talk about space exploration, both in the game and in the real world. It is not to get into arguments with each other, post personal attacks and insults, and carry grudges from one thread to another. The previous thread on this subject had to be closed because it had degenerated to the point that people were talking about each other rather than the subject, but folks asked and asked us for another chance to discuss the subject, and we agreed, under the condition that it must stay civil.

But this thread is going the same way. If you cannot leave each other's personalities out of the discussion, do not post in the thread. Otherwise, this thread will also be closed.

Link to comment
Share on other sites

This made a huge amount of sense. Thank you for clearly explaining these terms. It also makes sense that the term would appear in a properly rigorous derivation when transforming to polar coordinates.

Now am I mistaken in that what I presented in the OP is in a linear frame of reference, instead of rotational? Or am I asking the question incorrectly?

It was written assuming the vessel travels in a straight line, not a curved path, due to minimal curvature of the planet over which the burn occurs. Hence a Cartesian coordinate plane and no need to account for this "phantom term".

Seriosly, thank you for providing this explanation. Have some rep.

Eh, I'm disinclined to agree with this statement, primarily because the point of the exercise was that the Hohmann transfer is impossible to make in the first place. The purpose of what's presented is not to prove that method described is the most efficient method for making the burn, it's simply an assumption of the equation.

I'm glad the way Iskierka explained it to you made sense. I was trying my best :-(

The phantom term exists regardless of which frame of reference we use. If you are using Cartesian coordinates, and you calculate phi using asin(m*g/T), you will steadily gain height for finite TWR. If you subtract phantom term (centripetal lift, centrifugal lift , whatever you want to call it, etc...) you will not gain altitude. I have redone my results for the Mun (instead of Kerbin). The result is essentially the same:

If Phi is calculated from asin(m*g/T):

UMlG3qL.jpg

If Phi is calculate from asin(m*(g-V^2/R)/T):

WZfx8Z4.jpg

In the end, as others have said, the difference is small since centripetal lift term only becomes significant near orbital velocity.

Furthermore, as you and others have noted, the final altitude gained becomes increasingly less significant for higher and higher TWR (since in the limit of TWR = infinity, phi = 0 for both equations):

3js7F9S.png

Edited by arkie87
Link to comment
Share on other sites

Well, now that we've sorted out the issue with "centripetal lift", I figured I might put my degree to use and have a crack at equation 17 like OP actually wanted :cool: (apologies for the incredibly ugly text notation):

What did we decide about centripetal lift?

Link to comment
Share on other sites

What did we decide about centripetal lift?

Well, LD seems to be satisfied with Iskierka's explanation. Namely that it's not a real force - which imho means the term "centripetal lift" is a misnomer (in two ways but that's not very important) - but the term is relevant for polar coordinates. Since this isn't my thread/model/..., I don't see that my opinion on whether it's been adequately dealt with is relevant, as long as the OP is happy with it :)

EDIT: I should add that I of course have no intention of putting words in anyone's mouth :)

Edited by armagheddonsgw
Link to comment
Share on other sites

Well, LD seems to be satisfied with Iskierka's explanation. Namely that it's not a real force - which imho means the term "centripetal lift" is a misnomer (in two ways but that's not very important) - but the term is relevant for polar coordinates. Since this isn't my thread/model/..., I don't see that my opinion on whether it's been adequately dealt with is relevant, as long as the OP is happy with it :)

No one said it was a "real force". It is a phantom force resulting from change of coordinates. Its effect is relevant regardless of the coordinate system used, however, since if you neglect it when calculating the thrust angle, you will steadily gain altitude.

If you dont believe me, write your own code to simulate this case for a 2-D Cartesian case (as i have done three posts above this one).

So LD's model is accurate in the limiting case of large TWR, but only because burn angle at TWR = infinity equals 0 degrees regardless of the way you calculate burn angle... (nothing to do at all with how many degrees around the circle it travels during the burn).

Link to comment
Share on other sites

If you dont believe me, write your own code to simulate this case for a 2-D Cartesian case (as i have done three posts above this one

That would require 1) learning to use a tool I have no other practical use for (matlab) and 2) owning a copy of matlab, which at £85 is simply not worth it to me (and ahem pirated software is bad, mkay. >_>)

Link to comment
Share on other sites

That would require 1) learning to use a tool I have no other practical use for (matlab) and 2) owning a copy of matlab, which at £85 is simply not worth it to me (and ahem pirated software is bad, mkay. >_>)

I fully understand, though you could use another language, like C++ or Octave (which is basically a free version of Matlab) :cool:

Who knows... maybe after learning C++, you will write an App that makes billions of $$$$ :sticktongue:

Link to comment
Share on other sites

I fully understand, though you could use another language, like C++ or Octave (which is basically a free version of Matlab) :cool:

Who knows... maybe after learning C++, you will write an App that makes billions of $$$$ :sticktongue:

I already know C++, thank you. The trouble is it's a lot more work to set up drawing pretty pictures with complex equations in C++ ;)

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...