Aerodynamics in SFS

[Fwgunner]

I ran a few tests to check that myself...
View attachment 101786

And I found that drag behaved very strangely!
Curve set to 0 generates no drag at all indeed, but with a small value (even 0.1) some drag is generated. What is strange is that higher values of curve lead to a higher drag, it should be the opposite since curve is basically a coefficient that tells how fast density decreases with altitude.

I'll check the code to see if there's anything strange in the drag calculation. But I'm really surprised, I made the gliding heat shields mod a while ago, it gave the expected results so I don't know what's going wrong

10^-16 is the minimum curve value i get before drag becomes zero. 10^-17 is broken

 

[Fwgunner]

Altaïr do you know how to calculate temperature change due air resistance and engine overheat?

 

[Altaïr]

Altaïr do you know how to calculate temperature change due air resistance and engine overheat?

I don't know much about that. From what I know, heating is generated on each tick, and the heat generated is proportional to density, and to speed to the power 2.5. In the same time, there's a cooling process that gradually lowers the temperature. The final temperature is the result of those two processes combined and is calculated in real time. But to calculate this in practice would be complicated.

 

[Fwgunner]

Altaïr i gave up temperature stuff. Instead, i started to wrote a program from beginning. It isnt designing rockets to simulate but i tried something a little bit different. First program simulates in one dimension. Stage 1 was only vertical and stage 2 was only horizontal and they were simulated separately. So it was pretty easy. Now im trying to simulate in two dimension. Im stranger to two dimensional stuff. I mean, we did calculations 2D in physics class in university. Even we did in high school but it was on a flat surface and object was moving on a flat surface, not around a circle. Oh god, what am I doing? Computer teacher taught us only if commands and loops. Now, im trying to simulate something with a few command

Anyways. Enough crying. I was wondering if there are forces other than centripetal, gravitational and thrust forces? I added them all but still it fails. New program handles vertical flights but when i add a horizontal force, every second it spends while moving horizontal, error is getting bigger and bigger

 

[Altaïr]

Hello,

Sorry for the delay, I had to think a little about it. And my conclusion is that you can't just add centripetal acceleration. It works with a purely horizontal flight, but not in a general way. Regarding the forces you have to add, it all depends on how you're working. I'll assume you work in a frame of reference attached to the center of Earth. For the coordinates system, if you work in cartesian coordinates (x, y), then you only have to take into accounts your forces: thrust and gravity (I suppose you neglect drag). If you work in polar coordinates (r, θ), then you have to take into accounts some sorts of artificial forces (which include the centripetal acceleration) because the vectors that define your frame of reference rotate too.

From now on, I'll assume we are working in cartesian coordinates since this is the simpler option. You can work with forces as usual, without adding anything. For example, for the x coordinates, let's say an horizontal force Fx is applied at time t. The resulting acceleration is Ax = Fx/m because of the Newton law. Then by supposing that this force is constant during a small amount of time dt, you can deduce the velocity:
Vx(t+dt) = Vx(t) + Ax × dt

And then the position:
X(t+dt) = X(t) + Vx(t) × dt + Ax × dt²/2

You have similar formulas for the y coordinates. Then, starting from a known position and a known velocity, by iterating over small amounts of time, you can calculate position and velocity over time.

This is the simplest approach, but when taking into account gravity, you have to calculate g (gravity) as a sum of components oriented along x and y, so there's an extra calculation here. The result is also less intuitive as x and y are not the horizontal and vertical coordinates.

Note also that the integration method I used is a simple one, it does the job, but it's not the best. It's possible to get better results by using methods such as Runge-Kutta.

I don't know how you wrote your program though, is this similar to the logic you applied?

 

[Catalyst_Kh]

I did used centripetal acceleration in my calculations and it was total success, results showed me how to make the most efficient launcher. And it was very easy for me, since i am playing at Realistic level.

Because of Realistic level i can ignore circle shape of Earth, since at any given moment in fly the curvature is so tiny, that i can simple neglect it. I am almost like taking off horizontally all the time.

First i made calculations like without drag.

Thus i first calculated what would be resulting horizontal acceleration efficiency at each stage of taking off, so i could devide entire launcher into correct number of stages and more important - to find out best mass for each stage, when it is time to drop previous stage and when it is not yet beneficial.

For example, we can burn last fuel of the first stage and thus my TWR increased and i use only +10° vector above "pure horizontal" line to account for (to beat it) current "gravity-centripetal" remaining pull (to keep this altitude, no more and no less). That 10° is super efficient, because we are losing only 1/66 of our vector acceleration, 65/66 still goes to horizontal, but for that 1/66 we are buying 11.5/66 of vertical push, thus i am having like high efficiency, what can be wrong?

But i am still pushing a lot of that extra weight of first stage. If i were to drop first stage and use 2nd instead, i would need to use for example 26° instead of 10° to keep up vertically. With 26 i would lose 10% of entire horizontal speed to beat "gravity-centripetal" pull, but since my launcher became much lighter in mass and engines efficiency improved, now can push for 120% more acceleration for the same amount of fuel burned in comparison to first stage still active. Then 120%*0.9 = 108%. While 65/66 is only 98.5% of efficiency

So the conclusion is, that i could significantly improve my overall efficiency, if i dropped first stage much earlier, exactly on that point, where efficiency of stages were equal. Since after that point 2nd stage's efficiency will only rise and 1st stage's efficiency will only get lower.

Thus i easily calculated when to switch stages, and also what TWR each stage must have exactly to be the most efficient.

Then when i got my first optimal result and rebalanced my launcher, i added drag calculations to see how much i can trade off, how much i can lose fuel early on to take higher altitude before major horizontal acceleration, how much will i get for this lost fuel later instead using it right now for immediate horizontal acceleration. And calculations gave surprising results - the lower the better, the best would be to accelerate right from the launchpad horizontally.

Thus this part was easily done - i need to gain minimum altitude, where my rocket will simply not explode from overheating, any extra altitude above that is a wasted fuel.

Then i simply looked at which speed my rocket will overheat at each altitude, approximately +-, so i could start horizontal acceleration right immediately at lowest altitude possibe and simply gaining altitude little by little as i speed up, to avoid overheating.

Gaining altitude slowly means i need not only beat "gravity-centripetal", but to add extra vertical vector to it, and then i got my final idea - i can simply store vertical thrust in advance at the end of each stage (where twr is high and i can use small angle difference) to be able to switch to next stage prematurely, to get better efficiency of the next stage with having less weight for longer time, even if this stage have too low twr to keep up with "gravity-centripetal" pull requirements (at a reasonably low azimuth to horizontal vector).

Then this overloaded next stage simply eats up stored pull and when all stored pull was eaten away this stage already have much higher TWR since it burned a lot of fuel, and now it can keep up with "gravity-centripetal" pull for a good rate (like 8+ vertical units for only 1 horizon unit lost) and store new reserve in advance to switch to next stage prematurely again.

This allowed to overload each next stage without drawbacks, only with benefits.

And then final results were produced, which showed exactly how much twr each stage needs, how much angle i need to take, how much vertical thrust it would be most optimal to store in advance (extra would be counterproductive, since it would eat more from horizontal acceleration for no benefit), and when exactly to switch stages.

And then my launcher immediately brought to orbit a much bigger payload, than the same launcher brought before. I can bring more than 270 tons to orbit now, with totally fair launcher - not a single clipping, not a single edited or custom parts, not a single cheat, no ion engines, no bp editing, and default blueprint size.

This type of calculations also allowed some fun thing like those: link1, link2.

But of course, all this becomes much less useful if we play at Normal game difficulty, where Earth is so small then when you launch horizontally you immediately start to get vertical direction simply because Earth already got curved beneath you like almost in seconds.

Plus atmosphere at Normal level is 6 times higher and overheating is set to very big value, so there is no way you can make a lot of horizontal acceleration in atmosphere, at least below 25 km, thus it is more beneficial to simply go to Karman line very early, but not vertically of course. It is better to keep rocket as low as possible for as long as possible, as long as overheating permits, gaining altitude only when you accelerated too much for this altitude.

More horizontal speed early beats any drag a lot, like in several times (if rocket have good aerodynamics), so you can forget about drag. But that totally changes when you take off from Venus, especially after setting correct atmospheric density for Venus. Defaul value in stock game world is 0.025, and most custom worlds simply copying it, while correct value is 0.285 and it is 11.4 times higher than default value. More links on Venus: Link3, Link4.

With this realistic atmosphere it is already beneficial to take off from Venus ground purely vertical and tilt to the side somewhere later. But i don't know how to calculate when exactly later.

 

[Altaïr]

If you fly purely horizontally by compensating for gravity, simply adding the centrifugal acceleration does the job indeed. And yes, drag becomes quickly negligible, in practice you're more constrained by overheating. That's especially true in realistic mode in which drag becomes quickly very weak in practice.

I like to use the same trick as you too, which is to overload the second stage, then I use the very high TWR of the first stage in the end of its burn to raise my apoapsis, to buy some time and some potential energy. The second stage is too heavy at first, but it's on an ascending trajectory, and by the time it reaches the top of its trajectory it will have burnt enough fuel to have a correct TWR. It's a good trick to switch earlier to efficient engines.

On another topic, I finally found an explanation about your drag problem Fwgunner

rho(h) = density × exp(-curve × h/height)
is h/height means (instant altitude)/(atmosphere height) ?

Actually that formula is no longer valid. While browsing the game files, I saw that the formula was now:

ρ(h) = ρ(0) × (exp(-curve × h/height) - exp(-curve))

The part in blue is what changes. That corresponds to the atmospheric density at max height. In short, Stef substracted what was needed to nullify the density when you reaches the maximum height.

That explains what you noticed, setting curve to 0 makes density equal to 0 all the time. Unfortunately it's no longer possible to measure the cross sectional area that way, based on limit speed in a constant atmosphere. The most viable method I can think of right now is to make a mod to display the values of internal variables.

 

[Fwgunner]

Hello,

Sorry for the delay, I had to think a little about it. And my conclusion is that you can't just add centripetal acceleration. It works with a purely horizontal flight, but not in a general way. Regarding the forces you have to add, it all depends on how you're working. I'll assume you work in a frame of reference attached to the center of Earth. For the coordinates system, if you work in cartesian coordinates (x, y), then you only have to take into accounts your forces: thrust and gravity (I suppose you neglect drag). If you work in polar coordinates (r, θ), then you have to take into accounts some sorts of artificial forces (which include the centripetal acceleration) because the vectors that define your frame of reference rotate too.

From now on, I'll assume we are working in cartesian coordinates since this is the simpler option. You can work with forces as usual, without adding anything. For example, for the x coordinates, let's say an horizontal force Fx is applied at time t. The resulting acceleration is Ax = Fx/m because of the Newton law. Then by supposing that this force is constant during a small amount of time dt, you can deduce the velocity:
Vx(t+dt) = Vx(t) + Ax × dt

And then the position:
X(t+dt) = X(t) + Vx(t) × dt + Ax × dt²/2

You have similar formulas for the y coordinates. Then, starting from a known position and a known velocity, by iterating over small amounts of time, you can calculate position and velocity over time.

This is the simplest approach, but when taking into account gravity, you have to calculate g (gravity) as a sum of components oriented along x and y, so there's an extra calculation here. The result is also less intuitive as x and y are not the horizontal and vertical coordinates.

Note also that the integration method I used is a simple one, it does the job, but it's not the best. It's possible to get better results by using methods such as Runge-Kutta.

I don't know how you wrote your program though, is this similar to the logic you applied?

my program's to do list is respectively like this:

1. Gravitational acceleration (g)
1-Find magnitude of gravitational acceleration
2-Find its x and y component and their direction

2. Centripetal acceleration (ca)
1-Find instantaneous coordinate
2-Use this coordinate and previous two coordinates to find an imaginary circle where it passes through these three coordinates
3-Find distance between instantaneous position and position of the center of the imaginary circle which we are spinning around it in assumption.
4-Calculate centripetal acceleration using velocity magnitude and distance.
5-Find its components and their direction

3. Acceleration due to thrust (at)
1-Calculate weight (because fuel weight decreases due to working boosters)
2-Calculate acceleration magnitude (a=T/W*9.8)
3-Finds its components and their directions

Rest is:
a_x = g_x + ca_x + at_x
a_y = g_y + ca_y +at_y

x = x + v_x * dt + 1/2 * a_x * dt^2
y = y + v_y * dt + 1/2 * a_y * dt^2

v_x = v_x + a_x * dt
v_y = v_y + a_y * dt

 

[Fwgunner]

2. Centripetal acceleration (ca)
1-Find instantaneous coordinate
2-Use this coordinate and previous two coordinates to find an imaginary circle where it passes through these three coordinates
3-Find distance between instantaneous position and position of the center of the imaginary circle which we are spinning around it in assumption.
4-Calculate centripetal acceleration using velocity magnitude and distance.
5-Find its components and their direction

i calculated centripetal acceleration like this, because due to change of velocity, we follow a path like the black one. For each 3 position, we can find a circle passes through them like red, green, blue and yellow circles. Since dt is so small, these calculated circles must be quite accurate. Then i calculate centripetal acc. like rocket is spinning around them

 

[Altaïr]

my program's to do list is respectively like this:

1. Gravitational acceleration (g)
1-Find magnitude of gravitational acceleration
2-Find its x and y component and their direction

2. Centripetal acceleration (ca)
1-Find instantaneous coordinate
2-Use this coordinate and previous two coordinates to find an imaginary circle where it passes through these three coordinates
3-Find distance between instantaneous position and position of the center of the imaginary circle which we are spinning around it in assumption.
4-Calculate centripetal acceleration using velocity magnitude and distance.
5-Find its components and their direction

3. Acceleration due to thrust (at)
1-Calculate weight (because fuel weight decreases due to working boosters)
2-Calculate acceleration magnitude (a=T/W*9.8)
3-Finds its components and their directions

Rest is:
a_x = g_x + ca_x + at_x
a_y = g_y + ca_y +at_y

x = x + v_x * dt + 1/2 * a_x * dt^2
y = y + v_y * dt + 1/2 * a_y * dt^2

v_x = v_x + a_x * dt
v_y = v_y + a_y * dt

I see. Actually you don't need to add centripetal acceleration in this case. I should have been more clear about this, but centrifugal acceleration has to be added when you work in polar coordinates, noted usually (r, θ). r is the radial direction, which corresponds to the local vertical direction, while θ is the argument, and its variation is directly tied to tangential velocity (along the local horizontal direction). That system of coordinates has its advantages (like g is always oriented along the r direction, or circular orbits are simply modelized as "r = constant"), but the vectors that define its axes are not fixed. Unlike in cartesian coordinates they rotate. In this case you have to add the centrifugal acceleration to take this into account.

But in cartesian coordinates you can simply remove it.

 

[Fwgunner]

I see. Actually you don't need to add centripetal acceleration in this case. I should have been more clear about this, but centrifugal acceleration has to be added when you work in polar coordinates, noted usually (r, θ). r is the radial direction, which corresponds to the local vertical direction, while θ is the argument, and its variation is directly tied to tangential velocity (along the local horizontal direction). That system of coordinates has its advantages (like g is always oriented along the r direction, or circular orbits are simply modelized as "r = constant"), but the vectors that define its axes are not fixed. Unlike in cartesian coordinates they rotate. In this case you have to add the centrifugal acceleration to take this into account.

But in cartesian coordinates you can simply remove it.

When you said centrifugal, i checked dictionary and noticed which is which all the time i was talking about centrifugal acceleration, not centripetal. Anyways, i already added centrifugal acceleration but still it doesnt work. I have to write from scratch but i have midterms next week until friday but i'll be here on saturday with new program and hopefully accurate results

 

[Altaïr]

That's my fault to be honest, I'm the one who started talking about centripetal acceleration. It's centrifugal in this case. Technically, the centripetal acceleration is just gravity itself.

But as I said, just remove it, you only need to add it when working in polar coordinates.

 

[Fwgunner]

Catalyst_Kh can you send me your program in a text file? I wrote the program second time but still it fails unless its a vertical launch. I dont know what went wrong

 

[Catalyst_Kh]

I don't have program, i made all calculations in excel cells just by entering data and formulas.
Then, when i realized, that there is side criteria, which automatically verifies fuel distribution, i stopped using even excel sheets.

So the criteria is now - how much i need to change my azimuth between stages to keep up with best storing of vertical speed in advance for next stage. Zero changes in angle during all flight automatically means that everything is the most optimal. Small changes in angle are totally fine, since we have plateau of function's maximum and it is very wide. Thus if there are no big changes in angle required - it verifies that everything is good and there is nothing to improve (except aerodynamics and starting twr). Only one single starting angle should be picked up and once again - simple overheating restriction dictates, what this starting angle would be.

Thus i stopped all calculations long ago, because there is now simple criteria-indicator and natural pointers in which direction to improve things.

And last stage simply slowly inclines to prograde with more speed, since extra angle is not needed anymore, due to very low pull down on high speed.

And if starting angle is too high (big azimuth to prograde), then it would be better to add some twr, while if starting angle is too low (closer to prograde), then clearly it is better to replace some extra engines with more fuel instead. And that finishes all "calculations" for any kind of launcher of any size.

 

[Fwgunner]

I found something interesting



vx = x component of velocity

R = earth radius

h = altitude

g0= 9.8



vx = ((R+h)*g0/(1+h/R)^2)^0.5;



This formula gives me required velocity to orbit at a spesific altitude, as you said. It works properly. However, although we included centrifugal force to calculate required velocity, when i include centrifugal force to simulation, it fails. But if i remove centrifugal force from calculations, simulation results are accurate. But i have to mention that everything i said applies only when rocket is orbiting. If it’s an angled launch, simulation fails. It doesnt matter if centrifugal force is included or not. About vertical launches, there is no force other than thrust or gravity, so it works fine. What i didnt understand is I included centrifugal force to calculate orbit velocity but removed centrifugal force from simulation to get accurate results. I doesnt make any sense. Do you have any idea Altaïr ?

By the way, is it okay to discuss these topics? I am no longer talking about aerodynamics

 

[Fwgunner]

Orange circle is earth, blue line is the path that rocket followed from t=0 s to t=1000 s

The left graph is the result comes from the simulation including centrifugal force, the right graph is the result that comes from the simulation not including centrifugal force.
Centrifugal force is calculated using this formula:
a_cf=v^2/(R+h)

a_cf=acceleration due to centrifugal force
v=velocity
(R+h)=distance between the center of the earth and the rocket

 

[Fwgunner]

I dont even know what i did different but it doesnt matter i guess. Simulation works better than i thought. Now i can do some research and build better rockets. At least i hope

 

[Catalyst_Kh]

That is great result!

 

[Fwgunner]

That is great result!

Thanks! If you gain access to use matlab, i could share my file with you gladly. Normally you have to pay to use this program but if you are an engineering student, probably you can get it for free and that's how i get it. But I dont know if they give it for free to departments other than engineerings or to highschool students and others.

 

[Fwgunner]

Altaïr hey its me again Do you know the current air density formula? My experiments show that our old friend rho=density*exp(-curve........) does not work right now

 

[Altaïr]

Altaïr hey its me again Do you know the current air density formula? My experiments show that our old friend rho=density*exp(-curve........) does not work right now

Hello

I've just had a look, it seems you're correct:

I'll use the following notations:
- h: current height
- h_max: maximum height of atmosphere
- ρ(h): density at current height
- ρ0: density at ground level

The new formula reads out as:
ρ(h) = ρ0 * exp(-curve * h/h_max) - ρ0 * exp(-curve)

The first part corresponds to the original formula, and the second part (after the minus sign) corresponds to what would be the density at h_max. It's that second part that has been added. Or substracted more precisely.
Apparently this was to ensure that density was 0 at the atmosphere limit. Before, the formula gave a small density at h_max, but it was not null. That was probably changed so that there's not a sudden change in density when you cross the atmosphere limit.

 

[Axiom]

Small question, do intestages protect the parts inside them from drag?

 

[Fwgunner]

Altaïr do we know how to calculate temperature? I want to upgrade my simulation to build a stage 1 rocket with re-entry skills and need to know how does temperature changes and what it does depend on. I think i could do experiments under different air density conditions with different rockets that have different aerodynamics and try to find a connection between them but it will be more difficult than using your formula knowledge

 

[Altaïr]

Small question, do intestages protect the parts inside them from drag?

I don't know for sure but probably not since the interstages have no collider.

Altaïr do we know how to calculate temperature? I want to upgrade my simulation to build a stage 1 rocket with re-entry skills and need to know how does temperature changes and what it does depend on. I think i could do experiments under different air density conditions with different rockets that have different aerodynamics and try to find a connection between them but it will be more difficult than using your formula knowledge

I'll have to have a look into the code but this will be much more complicated. In theory, the heating power is proportional to ρ×v³, but I believe that Stef uses "only" 2.5 for the exponent.
From what I remember, on each tick, the temperature of any exposed part is increased proportionally to density × speed^(2.5). And in the same time, there's a cooling process that allows the temperature to go down: on each tick, the temperature is lowered by a certain amount.

I don't remember the details, but you see that it will be much harder to simulate.

 

[Fwgunner]

I don't know for sure but probably not since the interstages have no collider.


I'll have to have a look into the code but this will be much more complicated. In theory, the heating power is proportional to ρ×v³, but I believe that Stef uses "only" 2.5 for the exponent.
From what I remember, on each tick, the temperature of any exposed part is increased proportionally to density × speed^(2.5). And in the same time, there's a cooling process that allows the temperature to go down: on each tick, the temperature is lowered by a certain amount.

I don't remember the details, but you see that it will be much harder to simulate.

how about calculating the velocity point which causes temperature rise from zero under a specific air density value? A function like this: F(rho)=v

rho: air density
v: velocity value that temperature rises after that point

And by the way, does temperature rise depend on aerodynamics or is it just velocity and air density?