Delta V calculations with Python

[Feradose]

Hello everyone,

I wanted to make a DeltaV calculator in python and I failed I think.

Can anyone fix it?

(I read it had to do something with local gravity too so I put them there)

You dont need to put aerodynamics stuff in it, just think its vacuum

mass_empty=int(raw_input("Enter dry mass "))

mass_full=int(raw_input("Enter wet mass "))

isp=int(raw_input("Enter Isp "))

thrust=int(raw_input("Enter thrust "))

celestialBody_number=int(raw_input("Choose celestial body "))

if celestialBody_number==0:

g=1.746

print "You have selected Kerbol"

if celestialBody_number==1:

g=0.275

print "You have selected Moho"

if celestialBody_number==2:

g=1.7

print "You have selected Eve"

if celestialBody_number==3:

g=0.005

print "You have selected Gilly"

if celestialBody_number==4:

g=1

print "You have selected Kerbin"

if celestialBody_number==5:

g=0.116

print "You have selected Mün"

if celestialBody_number==6:

g=0.05

print "You have selected Minmus"

if celestialBody_number==7:

g=0.3

print "You have selected Duna"

if celestialBody_number==8:

g=0.112

print "You have selected Ike"

if celestialBody_number==9:

g=0.115

print "You have selected Dres"

if celestialBody_number==10:

g=0.8

print "You have selected Jool"

if celestialBody_number==11:

g=0.8

print "You have selected Laythe"

if celestialBody_number==12:

g=0.235

print "You have selected Vall"

if celestialBody_number==13:

g=0.8

print "You have selected Tylo"

if celestialBody_number==14:

g=0.06

print "You have selected Bop"

if celestialBody_number==15:

g=0.038

print "You have selected Pol"

if celestialBody_number==16:

g=0.172

print "You have selected Eeloo"

Delta_V=(mass_full/mass_empty)*isp*g

print Delta_V

[Black_Tomcat]

g in the dV formula is always 9,81m/s^2

It's not dependant on the gravity well you are in, otherwise you'd have to factor in different g's for different altitudes as well.

[Frida Space]

That's why the exhaust velocity formula (i believe) is

Vex = g0 x Isp

"g0" means the g value at 0 m of height here on Earth/Kerbin (9.81 m/s^2)

[Feradose]

Thanks!

[GreenWolf]

That's why the exhaust velocity formula (i believe) is

Vex = g0 x Isp

"g0" means the g value at 0 m of height here on Earth/Kerbin (9.81 m/s^2)

You have it backwards. ISP (when measured in seconds) is Ve * 9.81, where Ve is exhaust velocity. ISP is less useful than Ve when calculating delta-v, since Ve plugs directly into the rocket equation, which is Delta-v = Ve * ln(Initial Mass/Dry Mass).

[Frida Space]

You have it backwards. ISP (when measured in seconds) is Ve * 9.81, where Ve is exhaust velocity. ISP is less useful than Ve when calculating delta-v, since Ve plugs directly into the rocket equation, which is Delta-v = Ve * ln(Initial Mass/Dry Mass).

Are you sure? Everywhere I look it says the opposite.

From NASA:

The specific impulse Isp is given by:

Isp = Veq / g0

where g0 is the gravitational acceleration constant (32.2 ft/sec^2 in English units, 9.8 m/sec^2 in metric units).

[GreenWolf]

Are you sure? Everywhere I look it says the opposite.

From NASA:

No, wait, you're right. What threw me off was the way you wrote it the first time. Guess this is what I get for not double checking my equations.

[Frida Space]

No, wait, you're right. What threw me off was the way you wrote it the first time. Guess this is what I get for not double checking my equations.

Don't worry... it's actually rather amazing that I for once wasn't the one who wrote an equation backwards

[K^2]

Always check the units. s * m/s^2 = m/s

[IzzyIA]

i am confused, how do i find the vex variable?

[Nefrums]

Add:

from math import log

And change to:

Delta_V=log(mass_full/mass_empty)*isp*9.81 

Then remove everything related to "g"

 

Edit:

This should probably do it:

from math import log

mass_empty=int(raw_input("Enter dry mass "))
mass_full=int(raw_input("Enter wet mass "))
isp=int(raw_input("Enter Isp "))
Delta_V=log(mass_full/mass_empty)*isp*9.81 
print Delta_V

 

Edited November 9, 2016 by Nefrums

[HebaruSan]

I saw this topic and thought it sounded like a fun project, so here's my contribution in case it's of any interest. The license is public domain.

https://github.com/HebaruSan/KSP_Tools/blob/master/deltav.py

[kurja]

18 hours ago, Nefrums said:

Add:

from math import log

And change to:

Delta_V=log(mass_full/mass_empty)*isp*9.81 

Then remove everything related to "g"

 

Edit:

This should probably do it:

from math import log

mass_empty=int(raw_input("Enter dry mass "))
mass_full=int(raw_input("Enter wet mass "))
isp=int(raw_input("Enter Isp "))
Delta_V=log(mass_full/mass_empty)*isp*9.81 
print Delta_V

 

Is "log" here same as ln??

[Streetwind]

48 minutes ago, kurja said:

Is "log" here same as ln??

Ah yes, that unfortunate bit about nomenclature...

"log" is shorthand for "logarithm". There are an infinite number of different logarithms, because by its very nature of being a reversal of the exponentiation operation, a logarithm is only defined in relation to a 'base' number. So you start writing the base down whenever you write log. A logarithm in base 10 becomes log₁₀. A logarithm in base 2 becomes log₂. And so on and so forth.

Now, when you're talking about exponential functions, there's one number that always comes up, because it appears everywhere in nature. The very term "exponential" growth or decay refers to this very special number. That is "e", or "Euler's number". e^x is called the exponential function. It follows, then, that in any reversal of the exponentiation operation, there needs to exist a reversal of the exponential function, and it should be just as important as the exponential function itself.

That is the so-called 'natural logarithm', or the logarithm in base e. Now, you could write this as log_e, but in practical application, nobody ever does this. Because it is called 'natural', it is written as log_n instead.

 

And this is where it gets confusing.

 

People are lazy. People who have to write a lot are especially lazy about writing. Mathematicians, programmers, scientists and engineers have to do a lot of writing. Lazy people don't want to write out the full terms of everything everytime, so they develop shorthands. In case of the logarithm, this is especially dangerous, because 99% of the time, your chosen field of study involves exactly one important logarithm and ignores the others. Mathematicians deal with the natural logarithm a lot. Musicians deal with the binary logarithm (base 2) a lot. And so on and so forth. And then everyone goes and shorthands it to just log, leaving the base out. After all, it makes perfect sense to them. They only deal in one single base all the time. In the rare case where they need a different base, they'll just write the base down explicitly.

This is of course super confusing to anyone outside a specific discipline, or worse, someone studying across disciplines. Enter the ISO, the International Standards Organization. Recognizing that people are lazy, they went and suggested a new form of writing the most common logarithms in shorthand. In fact, their suggestions are even shorter! The binary logarithm log₂ becomes lb, the natural logarithm log_n becomes ln, and the decimal logarithm log₁₀ becomes ld. Super short, super quick to write or type, and still easily distinguishable. Perfect for everyone, right?

Well, as it so often goes, the lazyness of people transcends all logic. Despite the standardized format actually being faster, people are so lazy that they refuse to make the switch, and continue using the less short older shorthand notation to this day. You essentially have this effect.

 

The bottomline is: Yes, in this case, "log" is equal to "ln", because this is about maths and programming. Programmers are closely affiliated with mathematicians, so the natural logarithm is "their" logarithm without a specific base notation. Hence, when the programmer created that mathematics library and implemented the logarithm function, he implemented the natural logarithm and just called it "log" out of sheer lazyness and inertia (even though ln would be shorter). Your only chance of knowing this is understanding that the natural logarithm is used more in computer programming and mathematics than any other logarithm is.

(The function may even be overloaded, allowing you to pass a second argument as the base or something, but default to ln without being provided a base. Again, you would only know this if you're into programming yourself.)

 

Edited November 10, 2016 by Streetwind
Typos, typos everywhere!

[Nefrums]

the log function from the math python lib can use any base.  the default is natural logarithm

Quote

math.log(x[, base])

With one argument, return the natural logarithm of x (to base e).

ref

[kurja]

Ah. My old pocket calculator that I've used since my school years has a "log" button that defaults to base 10 - and a separate "ln" button. So, all this time I've assumed that log is base ten unless specified otherwise

 

Edit - I believe ms excel, and most other spreadsheets too, behave similarly.

Edited November 10, 2016 by kurja

[wumpus]

7 hours ago, Streetwind said:

The bottomline is: Yes, in this case, "log" is equal to "ln", because this is about maths and programming. Programmers are closely affiliated with mathematicians, so the natural logarithm is "their" logarithm without a specific base notation. Hence, when the programmer created that mathematics library and implemented the logarithm function, he implemented the natural logarithm and just called it "log" out of sheer lazyness and inertia (even though ln would be shorter). Your only chance of knowing this is understanding that the natural logarithm is used more in computer programming and mathematics than any other logarithm is.

I'm rather surprised that log₂ isn't baked more into computers.  I'd expect it to come in handy while programming more than ln() (there is another thread pointing out how rarely actual math is used during programming.  But ln() happens more often in trying to handle the data, and would also work for any log-based DSP work.  Not sure if it is any easier to compute in hardware.

[Steel]

Just now, wumpus said:

I'm rather surprised that log₂ isn't baked more into computers.  I'd expect it to come in handy while programming more than ln() (there is another thread pointing out how rarely actual math is used during programming.  But ln() happens more often in trying to handle the data, and would also work for any log-based DSP work.  Not sure if it is any easier to compute in hardware.

Quick off topic correction: we in the other topic are not saying that there is rarely maths in programming, just that knowledge of advanced mathematics is not required to learn and that any maths you do end up having to do tends to be fairly simple

Also, log₂ isn't used so much simply because, on the whole, humans (who mostly do the programming) don't work well in base two. Also, most of the time you're ever going to use a logarithm in any high level language, it will be a natural one.

[Kerbart]

On 3/17/2015 at 9:13 AM, Feradose said:

if celestialBody_number==0:

g=1.746

print "You have selected Kerbol"

if celestialBody_number==1:

g=0.275

print "You have selected Moho"

if celestialBody_number==2:

g=1.7

print "You have selected Eve"

8< snip ---------------------------

A bit more Pythonic would be:

body_data = {
  0:{'name':'Sun','g':1.746},
  1:{'name':'Moho','g':0.275},
  2:{'name':'Eve','g':1.7},
  3:{'name':'Gilly','g':0.005},
  etc, etc
}

and then:

celestialBody_number=int(raw_input("Choose celestial body "))
print('You have selected {}.'.format(body_data[celestialBody_number]['name']))
g = body_data[celestialBody_number]['g']

It would be easier to maintain, easy to extend with other data (say, the radius of the body) and reduces the amount of code.

On a side note, raw_input suggests you're using Python 2.7 (well, Python 2.x but I'm guessing 2.7). Python 3 has matured a lot these days and it's not like a couple of years ago where a lot of popular libraries were P2 only. If you're starting out with Python I would highly recommend switching over to Python 3. There are very few differences (for beginners most notably print being a function and not a statement, and / no longer being an integer division for integers, and input replacing raw_input, obviously) but I suspect that you're going to be running rapidly into a situation where some things don't work as expected as examples online are more and more written for Python 3, and not Python 2. Besides, it's the future!

Edited November 10, 2016 by Kerbart