SpaceX Falcon Mission Simulations

[ChrisC]

[Moderator Note:  This was split off from the Iridium Next Flight 1 Discussion thread.  Several of the participants in this discussion mentioned creating a more general simulation thread, so here it is.  If anyone thinks I split off too much I could always stick some of it back in the Iridium thread, just let me know.  -gongora]

Here's the webcast paired with some great animations. I really like the charts showing the altitude and velocity of both stages for the duration. I didn't realize it took soooo long for the first stage to get back down to the altitude it had at MECO.  https://youtube.com/watch?v=CGL2FEMxDE0

That's really interesting, especially to see the velocity changes (e.g. how much each burn slows down S1).

Note how S1 resumes accelerating after the entry burn completes, but only for a few seconds and then starts decelerating again, WITHOUT engines burning, due to descending into thicker atmosphere.  It's slowing down during nearly the entire atmospheric descent because it's going faster than terminal velocity.

This needs to get paired with the graph (video?) that someone here produced that inferred the ACCELERATION data from the velocity data shown on the webcast screen.  Although, as I recall, only S2 data was shown.  SpaceX, are you listening?  Give us S1 data (from telemetry) on the screen as well, and the community will produce cool graphics for you ...

[meekGee]

Here's the webcast paired with some great animations. I really like the charts showing the altitude and velocity of both stages for the duration. I didn't realize it took soooo long for the first stage to get back down to the altitude it had at MECO.  https://youtube.com/watch?v=CGL2FEMxDE0

That's really interesting, especially to see the velocity changes (e.g. how much each burn slows down S1).

Note how S1 resumes accelerating after the entry burn completes, but only for a few seconds and then starts decelerating again, WITHOUT engines burning, due to descending into thicker atmosphere.  It's slowing down during nearly the entire atmospheric descent because it's going faster than terminal velocity.

This needs to get paired with the graph (video?) that someone here produced that inferred the ACCELERATION data from the velocity data shown on the webcast screen.  Although, as I recall, only S2 data was shown.  SpaceX, are you listening?  Give us S1 data (from telemetry) on the screen as well, and the community will produce cool graphics for you ...

I was looking at the atmospheric portion too.

My interpretation is that it is at terminal velocity very quickly, but that the terminal velocity is of course decreasing with density.

It's not the same thing as being above terminal velocity. It means they are always at equilibrium, and there's no residual of the speed they've been traveling at 2 seconds ago.

[OneSpeed]

My interpretation is that it is at terminal velocity very quickly, but that the terminal velocity is of course decreasing with density.

It's not the same thing as being above terminal velocity. It means they are always at equilibrium, and there's no residual of the speed they've been traveling at 2 seconds ago.

If you watch this sim of the Iridium launch, you can see that the g forces peak at 4.6 at the 7:20 mark, purely due to aerodynamic forces. The rocket is travelling at 686 m/s, or about Mach 2, way in excess of terminal velocity. If it was in 'equilibrium' the g forces would be close to 1.

[meekGee]

My interpretation is that it is at terminal velocity very quickly, but that the terminal velocity is of course decreasing with density.

It's not the same thing as being above terminal velocity. It means they are always at equilibrium, and there's no residual of the speed they've been traveling at 2 seconds ago.

If you watch this sim of the Iridium launch, you can see that the g forces peak at 4.6 at the 7:20 mark, purely due to aerodynamic forces. The rocket is travelling at 686 m/s, or about Mach 2, way in excess of terminal velocity. If it was in 'equilibrium' the g forces would be close to 1.

That's the sim.

If you look at this video of the real thing, you see a smooth drop in velocity from the end of the last burn, almost along a straight line

(Skip forward to approx second 460, similar to your 7:20 mark)

[mme]

My interpretation is that it is at terminal velocity very quickly, but that the terminal velocity is of course decreasing with density.

It's not the same thing as being above terminal velocity. It means they are always at equilibrium, and there's no residual of the speed they've been traveling at 2 seconds ago.

If you watch this sim of the Iridium launch, you can see that the g forces peak at 4.6 at the 7:20 mark, purely due to aerodynamic forces. The rocket is travelling at 686 m/s, or about Mach 2, way in excess of terminal velocity. If it was in 'equilibrium' the g forces would be close to 1.

That's the sim.

If you look at this video of the real thing, you see a smooth drop in velocity from the end of the last burn, almost along a straight line

(Skip forward to approx second 460, similar to your 7:20 mark)

https://www.youtube.com/watch?v=NT50R2dLht8?t=459

I'm pretty sure those first stage numbers where generated by the FightClub.io "trajectory visualizer."  Space X did not provide them on the webcast.  I think this is a matter of competing simulations and I'm suspicious of FightClub's smooth deceleration.

[meekGee]

My interpretation is that it is at terminal velocity very quickly, but that the terminal velocity is of course decreasing with density.

It's not the same thing as being above terminal velocity. It means they are always at equilibrium, and there's no residual of the speed they've been traveling at 2 seconds ago.

If you watch this sim of the Iridium launch, you can see that the g forces peak at 4.6 at the 7:20 mark, purely due to aerodynamic forces. The rocket is travelling at 686 m/s, or about Mach 2, way in excess of terminal velocity. If it was in 'equilibrium' the g forces would be close to 1.

That's the sim.

If you look at this video of the real thing, you see a smooth drop in velocity from the end of the last burn, almost along a straight line

(Skip forward to approx second 460, similar to your 7:20 mark)

https://www.youtube.com/watch?v=NT50R2dLht8?t=459

I'm pretty sure those first stage numbers where generated by the FightClub.io "trajectory visualizer."  Space X did not provide them on the webcast.  I think this is a matter of competing simulations and I'm suspicious of FightClub's smooth deceleration.

Well FC is a simulator, but he managed to get the timing of all events to within a few seconds, and then tweaked the sim parameters to match reality. I think that's pretty good.

I'm using it to estimate trends, not nail down precise numbers.

[OneSpeed]

I'm pretty sure those first stage numbers where generated by the FightClub.io "trajectory visualizer."  Space X did not provide them on the webcast.  I think this is a matter of competing simulations and I'm suspicious of FightClub's smooth deceleration.

Well FC is a simulator, but he managed to get the timing of all events to within a few seconds, and then tweaked the sim parameters to match reality. I think that's pretty good.

I'm using it to estimate trends, not nail down precise numbers.

Flight Club is a launch and landing trajectory visualiser, not a simulator. It is replaying the velocity and altitude data gleaned from the SpaceX broadcasts, where it is available. Where it is not, they appear to be interpolating as best they can to match the video they have.

SpaceSim is an n-body simulation of the solar system. The simulation takes account of all of the forces acting on the rocket, including mass, thrust, drag (including skin friction) and lift. The process of matching the broadcast data to the flight profile is extremely manual and time consuming. But when they do match, it is quite revealing. For example we know that for return to flight, the first stage must have been throttled to between 90 and 95% of the FT spec.

[meekGee]

I'm pretty sure those first stage numbers where generated by the FightClub.io "trajectory visualizer."  Space X did not provide them on the webcast.  I think this is a matter of competing simulations and I'm suspicious of FightClub's smooth deceleration.

Well FC is a simulator, but he managed to get the timing of all events to within a few seconds, and then tweaked the sim parameters to match reality. I think that's pretty good.

I'm using it to estimate trends, not nail down precise numbers.

Flight Club is a launch and landing trajectory visualiser, not a simulator. It is replaying the velocity and altitude data gleaned from the SpaceX broadcasts, where it is available. Where it is not, they appear to be interpolating as best they can to match the video they have.

SpaceSim is an n-body simulation of the solar system. The simulation takes account of all of the forces acting on the rocket, including mass, thrust, drag (including skin friction) and lift. The process of matching the broadcast data to the flight profile is extremely manual and time consuming. But when they do match, it is quite revealing. For example we know that for return to flight, the first stage must have been throttled to between 90 and 95% of the FT spec.

I thought so too initially, but he appears to be visualizing his simulation, based on some of the comments he's left in the conversation threads.

However - if he has a robust simulation, and he tweaks the underlying parameters to match reality, then that's even better than just blindly reading numbers from the SpaceX feed.

You can look at his results for different missions and see how well it works.

[OneSpeed]

I thought so too initially, but he appears to be visualizing his simulation, based on some of the comments he's left in the conversation threads.

However - if he has a robust simulation, and he tweaks the underlying parameters to match reality, then that's even better than just blindly reading numbers from the SpaceX feed.

You can look at his results for different missions and see how well it works.

Fair enough, so I've added a couple of lines of code to SpaceSim to output Velocity, Acceleration and Altitude of just the first stage to a .csv file. The output is attached below, and is similar in many respects to the Flight Club S1 profile. One observation I would make is that the drag should drop quite suddenly as the stage goes subsonic, but only SpaceSim appears to be taking account of this.

My interpretation is that it is at terminal velocity very quickly, but that the terminal velocity is of course decreasing with density.

It's not the same thing as being above terminal velocity. It means they are always at equilibrium, and there's no residual of the speed they've been traveling at 2 seconds ago.

Going back to your original point though, both profiles, however they are obtained, confirm that the g forces are only in 'equilibrium' very briefly, at around the 7:03 mark, and that the stage is well above terminal velocity at the 7:20 mark.

Edit: fixed stage numbering

[meekGee]

I'm not following.  Shouldn't the acceleration be the derivative of the velocity?  (Are you always doing dS - along the path?)

Altitude of course is unrelated, but why is the acceleration at 0 over so much of the time?

How do you define aerodynamic equilibrium?  And should that only be relevant only between the entry burn and the landing burn starts?

I thought so too initially, but he appears to be visualizing his simulation, based on some of the comments he's left in the conversation threads.

However - if he has a robust simulation, and he tweaks the underlying parameters to match reality, then that's even better than just blindly reading numbers from the SpaceX feed.

You can look at his results for different missions and see how well it works.

Fair enough, so I've added a couple of lines of code to SpaceSim to output Velocity, Acceleration and Altitude of just the second stage to a .csv file. The output is attached below, and is similar in many respects to the Flight Club S2 profile. One observation I would make is that the drag should drop quite suddenly as the stage goes subsonic, but only SpaceSim appears to be taking account of this.

My interpretation is that it is at terminal velocity very quickly, but that the terminal velocity is of course decreasing with density.

It's not the same thing as being above terminal velocity. It means they are always at equilibrium, and there's no residual of the speed they've been traveling at 2 seconds ago.

Going back to your original point though, both profiles, however they are obtained, confirm that the g forces are only in 'equilibrium' very briefly, at around the 7:03 mark, and that the stage is well above terminal velocity at the 7:20 mark.

[OneSpeed]

How do you define aerodynamic equilibrium?  And should that only be relevant only between the entry burn and the landing burn starts?

In this case I take aerodynamic equilibrium to mean that for a free falling object, gravitational and aerodynamic forces are equal and opposite, and so it does not accelerate. If we are discussing your interpretation of whether or not the stage is at terminal velocity, then yes, that should only be relevant between the entry burn and the landing burn.

I'm not following.  Shouldn't the acceleration be the derivative of the velocity?  (Are you always doing dS - along the path?)

Altitude of course is unrelated, but why is the acceleration at 0 over so much of the time?

Drag between the initial boost and the boostback burns is nearly zero because of the altitude, and so therefore is the acceleration. Acceleration between the boostback and entry burns is also near zero for the same reason.
However acceleration in the initial boost phase also appears to be zero in the plot I've posted. This is clearly not correct.

Sorry for the long winded explanation, but SpaceSim uses a parent / child relationship to determine the effect of thrust of a stage on any parent stages. At launch, the parent object is the payload. Its child is the second stage, and its grandchild is the first stage. The first separation event changes that relationship. The payload now has only the second stage as a child, and the first stage becomes a parent with no children. Once separated, calculations are performed separately, as you'd expect. In SpaceSim the acceleration is only known for parent objects, so when I plotted the first stage acceleration, that value was skipped while it was still a grandchild, i.e. in the boost phase, and only plotted once it became a parent object.

Anyway, I've attached a plot of velocity, acceleration and altitude for the payload, and the acceleration in the boost phase is what the first stage would also experience.

[MikeAtkinson]

I'm not following.  Shouldn't the acceleration be the derivative of the velocity?  (Are you always doing dS - along the path?)

Altitude of course is unrelated, but why is the acceleration at 0 over so much of the time?

Drag between the initial boost and the boostback burns is nearly zero because of the altitude, and so therefore is the acceleration. Acceleration between the boostback and entry burns is also near zero for the same reason.
However acceleration in the initial boost phase also appears to be zero in the plot I've posted. This is clearly not correct.

I think he meant that acceleration due to gravity is missing.

[meekGee]

I'm not following.  Shouldn't the acceleration be the derivative of the velocity?  (Are you always doing dS - along the path?)

Altitude of course is unrelated, but why is the acceleration at 0 over so much of the time?

Drag between the initial boost and the boostback burns is nearly zero because of the altitude, and so therefore is the acceleration. Acceleration between the boostback and entry burns is also near zero for the same reason.
However acceleration in the initial boost phase also appears to be zero in the plot I've posted. This is clearly not correct.

I think he meant that acceleration due to gravity is missing.

Well it's hard to separate out once you're in air, since the direction of motion is not known.

[OneSpeed]

I think he meant that acceleration due to gravity is missing.

Well it's hard to separate out once you're in air, since the direction of motion is not known.

Yes, the internal term in SpaceSim is RelativeAcceleration, acceleration relative to gravity, which is calculated later. Gravity is not considered a constant because it is a n-body simulation of the solar system.

[meekGee]

I think he meant that acceleration due to gravity is missing.

Well it's hard to separate out once you're in air, since the direction of motion is not known.

Yes, the internal term in SpaceSim is RelativeAcceleration, acceleration relative to gravity, which is calculated later. Gravity is not considered a constant because it is a n-body simulation of the solar system.

I understand that - but where is it coming from?

The velocity is along the path (I assume) so if you differentiate that, you get the full acceleration. (in vector form)

You can subtract 1 g in the "Z" direction, but this only makes sense when in free fall.  (Is that what you did?)

Once you hit the atmosphere, the aerodynamic forces can be in any direction.  So you can't define "equilibrium" as just "0 g".

It's trickier to tease this out than it appears at first blush.

[mme]

I think he meant that acceleration due to gravity is missing.

Well it's hard to separate out once you're in air, since the direction of motion is not known.

Yes, the internal term in SpaceSim is RelativeAcceleration, acceleration relative to gravity, which is calculated later. Gravity is not considered a constant because it is a n-body simulation of the solar system.

I understand that - but where is it coming from?

The velocity is along the path (I assume) so if you differentiate that, you get the full acceleration. (in vector form)

You can subtract 1 g in the "Z" direction, but this only makes sense when in free fall.  (Is that what you did?)

Once you hit the atmosphere, the aerodynamic forces can be in any direction.  So you can't define "equilibrium" as just "0 g".

It's trickier to tease this out than it appears at first blush.

Sorry, I'm being hand wavy and should let OneSpeed explain since he really knows what he is talking about and I'm just expressing my understanding of what the graphs represent.

The acceleration that is being graphed (after the initial boost and separation [1]) is in the stage's reference frame, not Earth's.  There is no subtraction of the 1 g going on.  The "RelativeAcceleration" is relative to free-fall in the n-body space.

I'm probably not right, but in my mind it is summing all the forces on the stage (gravity, thrust, drag) and expressing the resulting "g-force" that is being experienced by the stage. It is not expressing dV/dT relative to an observer on Earth.  It is dV/dT relative to the stage in free-fall and what "free-fall" means is calculated in realtime (so it's not a fixed 9.8 m/s^2).

[1] Before first stage separation, the calculation is done for the payload because that's how the software models the problem and since everything is connected at that point it's a reasonable simplification.

[meekGee]

I think he meant that acceleration due to gravity is missing.

Well it's hard to separate out once you're in air, since the direction of motion is not known.

Yes, the internal term in SpaceSim is RelativeAcceleration, acceleration relative to gravity, which is calculated later. Gravity is not considered a constant because it is a n-body simulation of the solar system.

I understand that - but where is it coming from?

The velocity is along the path (I assume) so if you differentiate that, you get the full acceleration. (in vector form)

You can subtract 1 g in the "Z" direction, but this only makes sense when in free fall.  (Is that what you did?)

Once you hit the atmosphere, the aerodynamic forces can be in any direction.  So you can't define "equilibrium" as just "0 g".

It's trickier to tease this out than it appears at first blush.

Sorry, I'm being hand wavy and should let OneSpeed explain since he really knows what he is talking about and I'm just expressing my understanding of what the graphs represent.

The acceleration that is being graphed (after the initial boost and separation [1]) is in the stage's reference frame, not Earth's.  There is no subtraction of the 1 g going on.  The "RelativeAcceleration" is relative to free-fall in the n-body space.

It's probably not right, but in my mind it is summing all the forces on the stage (gravity, thrust, drag) and expressing the resulting "g-force" that is being experienced by the stage. It is not expressing dV/dT relative to an observer on Earth.  It is dV/dT relative to the stage in free-fall and what "free-fall" means is calculated in realtime (so it's not a fixed 9.8 m/s^2).

[1] Before first stage separation, the calculation is done for the payload because that's how the software models the problem and since everything is connected at that point it's a reasonable simplification.

Right.

And with that in mind, the ambiguity arises.

If it is showing zero when free floating in space, then it shouldn't show zero when in aerodynamic equilibrium.

But what it SHOULD show depends on how things are defined.

Is this only in Z axis, for example?   Because the velocity seems to be in the dS direction.

(But the altitude of course isn't)

What is the source of the acceleration graph?  Is it derived from the velocity curve? Seems like it isn't, since it doesn't match.

So what are we looking at, before we draw conclusions from it?

[OneSpeed]

It's trickier to tease this out than it appears at first blush.

Absolutely!

The acceleration that is being graphed (after the initial boost and separation [1]) is in the stage's reference frame, not Earth's.  There is no subtraction of the 1 g going on.  The "RelativeAcceleration" is relative to free-fall in the n-body space.

I'm probably not right, but in my mind it is summing all the forces on the stage (gravity, thrust, drag) and expressing the resulting "g-force" that is being experienced by the stage. It is not expressing dV/dT relative to an observer on Earth.  It is dV/dT relative to the stage in free-fall and what "free-fall" means is calculated in realtime (so it's not a fixed 9.8 m/s^2).

[1] Before first stage separation, the calculation is done for the payload because that's how the software models the problem and since everything is connected at that point it's a reasonable simplification.

That's a great summary of what I've tried to express so far. Thanks.

SpaceSim is open source, and if you want to see the code, or just run it for yourself, it's at https://github.com/zlynn1990/SpaceSim . zlynn1990 has done a fantastic job, writing the vast majority of the program. I've added mostly aerodynamic enhancements starting July 2016. If you happened to download SpaceSim before that date, the drag calculation would have been different. If you then happened to use it to model the Iridium 1 launch, and put a couple of lines of code in the F9S1 and DemoSat classes to output the velocity and altitude, you'd end up with plots that did not take account of the step change in drag in the transonic region.

Also, those couple of lines of code would have problems correctly outputting acceleration, as meekGee has identified. The RelativeAcceleration parameter is a vector, but I am only printing its magnitude. If it has any horizontal component, aerodynamic equilibrium would not be achieved when the magnitude of the RelativeAcceleration equals the magnitude of gravity. In other words, my two lines of code are a hack.

However, SpaceSim does correctly take account of gravity. The data in the spreadsheet I attached upthread suggests that equilibrium is reached at second 426 (7:06), but the vertical (z) component of the velocity vector is smaller than its magnitude, and so equilibrium is reached in the simulation earlier, at second 423 (7:03), when drag is less.

[TheVehicleDestroyer]

Hey folks, I'm late to the party. I'm the guy who made Flight Club

I'm pretty sure those first stage numbers where generated by the FightClub.io "trajectory visualizer."  Space X did not provide them on the webcast.  I think this is a matter of competing simulations and I'm suspicious of FightClub's smooth deceleration.

Well FC is a simulator, but he managed to get the timing of all events to within a few seconds, and then tweaked the sim parameters to match reality. I think that's pretty good.

I'm using it to estimate trends, not nail down precise numbers.

Flight Club is a launch and landing trajectory visualiser, not a simulator. It is replaying the velocity and altitude data gleaned from the SpaceX broadcasts, where it is available. Where it is not, they appear to be interpolating as best they can to match the video they have.

SpaceSim is an n-body simulation of the solar system. The simulation takes account of all of the forces acting on the rocket, including mass, thrust, drag (including skin friction) and lift. The process of matching the broadcast data to the flight profile is extremely manual and time consuming. But when they do match, it is quite revealing. For example we know that for return to flight, the first stage must have been throttled to between 90 and 95% of the FT spec.

Flight Club is a simulator. Myself and zlynn1990 (of SpaceSim fame) collaborated a bunch on tweaking our atmospheric models and such when we were independently building our simulators. Just wanted to clear that up. Let me know if you have any questions about how Flight Club does things - happy to help in any way.

[mme]

Hey folks, I'm late to the party. I'm the guy who made Flight Club

I'm pretty sure those first stage numbers where generated by the FightClub.io "trajectory visualizer."  Space X did not provide them on the webcast.  I think this is a matter of competing simulations and I'm suspicious of FightClub's smooth deceleration.

Well FC is a simulator, but he managed to get the timing of all events to within a few seconds, and then tweaked the sim parameters to match reality. I think that's pretty good.

I'm using it to estimate trends, not nail down precise numbers.

Flight Club is a launch and landing trajectory visualiser, not a simulator. It is replaying the velocity and altitude data gleaned from the SpaceX broadcasts, where it is available. Where it is not, they appear to be interpolating as best they can to match the video they have.

SpaceSim is an n-body simulation of the solar system. The simulation takes account of all of the forces acting on the rocket, including mass, thrust, drag (including skin friction) and lift. The process of matching the broadcast data to the flight profile is extremely manual and time consuming. But when they do match, it is quite revealing. For example we know that for return to flight, the first stage must have been throttled to between 90 and 95% of the FT spec.

Flight Club is a simulator. Myself and zlynn1990 (of SpaceSim fame) collaborated a bunch on tweaking our atmospheric models and such when we were independently building our simulators. Just wanted to clear that up. Let me know if you have any questions about how Flight Club does things - happy to help in any way.

Thanks for clearing that up and thanks for creating FlightClub!  I wonder if the apparent differences are more to do with the model or the assumptions for various inputs.  I was also starting to feel like maybe we should create a simulation thread for these topics if people wanted to continue debating the implications of different simulations.