Duna Aerocapture Analysis

[Geschosskopf]

What kind of transfers are you using, to get such large variations of speed at arrival to Duna?

While I did want SOME spread to avoid all the ships arriving simultaneously when I can only control 1 at a time, the extreme spread in this example for the short trip just next door to Duna was largely a result of errors during the ejection burns. The main problem was that I was pretty drunk at the time and so on 2 ships I forgot to do the throttle blip upon refocusing on them when it was their turns to go, so their burn-time calculations were WAY off, which meant the burns weren't properly centered about the nodes . NOTE: the need to blip throttles applies whether you're going manual or MJ.

Yesterday while stone sober, I sent a flotilla of 5 ships to Duna and remembered to blip the throttles for each one, so all my burn times were correct and the burns properly centered around the nodes. These will arrive over a span of just 4.5 days with the shortest interval between arrivals being 16 hours. I figure that's about as tight a spacing as you can get going to Duna, given the slight differences in their starting orbits at Kerbin and their departures being spaced 20-30 minutes apart.

When they get to Duna, they'll have roughly similar speeds so you'd think they'd need pretty much the same Pe for aerocapture. But this brings up the 2nd major variable affecting choice of Pe: the desired Ap afterwards. I mean, the whole point of doing aerocapture is to eliminate or at least minimize the burn needed to establish the desired orbit afterwards, so you keep "running F5/F9 simulations" until you get the Ap close to your target. Then all you need to do is circularize at Ap. In the case of this sober flotilla, I want it to end up like this:

• 1st (fastest) ship: final orbit ~300km
  
• 2nd ship: final orbit ~50km
  
• 3rd ship: final orbit ~200km
  
• 4th ship: final orbit ~50km
  
• 5th (slowest) ship: final orbit ~150km
  

Given the differences in desired Ap's and speeds, I expect them all to need rather different Pe's, so all will have to be "simulated".

#2 will be especially interesting because it's a spaceplane with an insane amount of wing to be able to fly in Duna's thin air. This greatly complicated getting it off the ground at Kerbin and might pose similar problems with aerocapture, especially because it will have to go pretty low given its relatively high speed and low desired Ap. So this one might have to do a capture burn and then several higher, slower, gentler aerobraking passes to settle in. Thus, there's potentially a 3rd major variable in Pe selection: aerodynamics. But however it turns out, it's going to be fun .

[Meithan]

The main problem was that I was pretty drunk at the time and so on 2 ships I forgot to do the throttle blip upon refocusing on them when it was their turns to go, so their burn-time calculations were WAY off, which meant the burns weren't properly centered about the nodes .

LOL, KSPing while drunk, now that's something I haven't tried.

When they get to Duna, they'll have roughly similar speeds so you'd think they'd need pretty much the same Pe for aerocapture. But this brings up the 2nd major variable affecting choice of Pe: the desired Ap afterwards. [...]Given the differences in desired Ap's and speeds, I expect them all to need rather different Pe's, so all will have to be "simulated".

Yep, this is where it gets very sensitive. A difference in a few tens of m/s, for instance, can move your final Ap by hundreds of kilometers. If you need more precision, then one's forced to (a) simulate each case individually and ( F5/F9 anyway when the simulation turns out not to be precise enough.

Do let us know how that flotilla aerobraking turns out, it'll certainly be very interesting.

[Eric S]

It just seems that aerocapture is so gentle in KSP that you need less protection for the payload than the actual launch from Kerbin, so simple fairings (flimsier and so lighter than actual launch fairings) should be enough to survive aerocapture.

That shouldn't come as too big of a surprise. Because of the scaling of the solar system, reentry velocities tend to be quite a bit slower. For example, LKO orbital velocity is less than a third of LEO orbital velocity.

[NeoMorph]

One thing that I keep wondering about is the shape of your craft. KSP doesn't seem to take this into account when aerobraking. I made a ship with big aerobraking inflatable modules (like in the 2010 movie) but it didn't make any difference if I did or if I didn't inflate. The path was identical.

[Eric S]

One thing that I keep wondering about is the shape of your craft. KSP doesn't seem to take this into account when aerobraking. I made a ship with big aerobraking inflatable modules (like in the 2010 movie) but it didn't make any difference if I did or if I didn't inflate. The path was identical.

What part did you use for your inflatable modules? If it doesn't change it's drag coefficient, then the overall drag isn't going to change unless you've got FAR installed.

[Geschosskopf]

LOL, KSPing while drunk, now that's something I haven't tried.

That's strange. Given the responses to the thread about what controls you use, I got the impression we were all drunks .

Yep, this is where it gets very sensitive. A difference in a few tens of m/s, for instance, can move your final Ap by hundreds of kilometers. If you need more precision, then one's forced to (a) simulate each case individually and ( F5/F9 anyway when the simulation turns out not to be precise enough.

KSP is rather strange in letting you do near-future rocketry with no more in-game instrumentation than the a WW1 aircraft. While this works for doing burns and docking, there are 2 main areas of the game where this is totally inadequate: the editors not given you any delta-V information and the whole map view/maneuver node system totally ignoring atmospheric effects. Due to the latter, there is no way at all to know in advance of actually doing it what you'll end up with after an aerocapture/braking pass. Thus, there is simply no recourse but to F5/F9 however many times it takes until you get more or less what you want out of it.

While I don't mind SOME trial-and-error (this is KSP, after all), in this case it gets aggravating very quickly because it eats a lot of real time repeatedly re-doing your passes, and each time you run the risk of totally hosing your whole mission by forgetting to F5 at the right time or accidentally hitting F5 when you meant to hit F9 (especially common when you've been drinking).

Do let us know how that flotilla aerobraking turns out, it'll certainly be very interesting.

It'll be added on to this on-going mission report. You seem to be the 2nd person interested in it .

http://forum.kerbalspaceprogram.com/showthread.php/43871-The-Kethane-Travelling-Circus-EPISODE-11-Duna-2nd-Wave-Departs-(D-OH-Included)

[Meithan]

It'll be added on to this on-going mission report. You seem to be the 2nd person interested in it .

http://forum.kerbalspaceprogram.com/showthread.php/43871-The-Kethane-Travelling-Circus-EPISODE-11-Duna-2nd-Wave-Departs-(D-OH-Included)

Whoah, my mind is blown. I feel such a noob compared to what guys like you are building and launching. I'm even a mod noob. The only mod I've tried is MechJeb!

But anyway, it would be very interesting to compare your results with predictions from the simulation. Could you log the following as your mission unfolds?

The orbital parameters (current altitude, current speed and periapsis altitude) of:

1) the initial orbit as they enter Duna's SOI (I want to see how much they differ)

2) the final pre-aerobraking trajectory after your course corrections

3) the orbital parameters of the "final" orbit after the aerobraking pass

[alterbaron]

Excellent analysis Meithan!

Aerobraking is a really fun problem .

It's great to see others working on it (and it's good for verification of results as well).

Couple questions about your simulation:

Are you simulating the hard cutoff for atmosphere? Nvm, from initial post it looks like you are.

What numerical integration scheme are you using? Time step?

Ideas for further experimentation (no idea if these are any good or not):

Can you find approximate equations for aerobraking periapsis for the different planets? Something that could be used with a pocket calculator would be really cool. Would be a function of altitude, velocity, .etc How precise can this be?

Similar to above: predicting max gee force as a function of stuff you can compute using data in-game. Would be useful for mission planning.

Edited September 18, 2013 by alterbaron

[Meithan]

Excellent analysis Meithan!

Aerobraking is a really fun problem .

It's great to see others working on it (and it's good for verification of results as well).

I was about to "invite you" to the thread, since I really wanted to see what you think of this. Your aerobraking calculator is a fine piece of programming, sir.

Couple questions about your simulation:

Are you simulating the hard cutoff for atmosphere? Nvm, from initial post it looks like you are.

Yep, as you guessed, I am. I cut off the atmosphere when pressure goes below 1e-6 times the pressure at sea level. The KSP Wiki suggests the game does this, but to be honest I haven't verified it ingame.

I was under the impression that density is so low at the cutoff altitude that the transition should be quite smooth. However, Specialist290 has been toying with my program and we just had a look at the orbital parameters just 1 km after atmospheric contact on Kerbin. Orbital energy is practically unchanged from its initial value, but angular momentum changes by 4%. This means that the direction of motion changed a bit with respect to the direction the craft would have in the absence of atmosphere. Could the minute atmospheric force at this altitude do this? Or do you think there's some sort of numerical spike at the atmospheric interface?

What numerical integration scheme are you using? Time step?

I had just programmed a 4th/5th-order embedded Runge-Kutta method with adaptive timestep for something unrelated (it's the one by Cash and Karp, which is the one recommended by the authors of the Numerical Recipes), so I thought this could be a great application. The timestep is adaptive, so it adjusts itself to keep truncation error below a certain threshold. It's typically around some fractions of a second in these simulations

To be honest using this solver is quite overkill. I had a look at your code, and the Velocity Verlet you're using is definitely more than sufficient for this (and it conserves energy better, so you can afford larger timesteps). My program is considerably slower, probably because of this.

Ideas for further experimentation (no idea if these are any good or not):

Can you find approximate equations for aerobraking periapsis for the different planets? Something that could be used with a pocket calculator would be really cool. Would be a function of altitude, velocity, .etc How precise can this be?

That sounds like a very interesting idea. I could have the program automatically make a series of runs, starting from a fixed initial orbit but changing the periapsis altitude, and then compute a regression formula for final apoapsis (if the aerobraking succeeds) as a function of initial periapsis.

However, as the more experienced players have pointed out in this thread, it seems the results of aerobraking in general are quite sensitive to the details of the initial orbit, and those can change widely in normal play. This implies the parameter space has many variables, and would be hard to explore unless we could reduce it to perhaps two variables. We could maybe fix distance to SOI radius, vary speed and current periapsis, and compute a two-dimensional fit for those?

Similar to above: predicting max gee force as a function of stuff you can compute using data in-game. Would be useful for mission planning.

Would be interesting indeed. Again, the problem might be sensitivity to initial orbit parameters. What's true is that Duna aerobraking seems to be pretty mild as far as gee forces go. But Eve might be another story.

The picture that seems to be forming here is that there is too much variation in initial orbit parameters during typical play to have accurate rules of thumb for aerobraking, and that simulation on a case-by-case basis is required. Hence the usefulness of tools like your calculator.

By the way, have you considered expanding your calculator to 3D so that the effects of orbital inclination can be included? I suspect the largest source of error in my program is in the atmospheric drag calculation, as I still don't quite get the exact same figures as MechJeb reports (do you? should we trust MechJeb as being exact?). My air density is very precise, and the coefficient of drag should be exact, so this leaves a slight error in the airspeed calculation (amplified by the quadratic dependence), which could be due to orbital inclination. But the effect is perhaps too little for inclinations of ~1°, so I don't know.

[alterbaron]

I was about to "invite you" to the thread, since I really wanted to see what you think of this. Your aerobraking calculator is a fine piece of programming, sir.

Thanks!

I had just programmed a 4th/5th-order embedded Runge-Kutta method with adaptive timestep . . .

Very interesting. Thanks for the info!

However, Specialist290 has been toying with my program and we just had a look at the orbital parameters just 1 km after atmospheric contact on Kerbin. Orbital energy is practically unchanged from its initial value, but angular momentum changes by 4%.

That's a surprising amount of change. If you post your initial conditions, I can run it through my MATLAB scripts (the online calculator's a translation of these) to check for agreement.

. . . it seems the results of aerobraking in general are quite sensitive to the details of the initial orbit, and those can change widely in normal play.

That's true, but you can get a pretty nice function to work with if you parameterize the problem well:

Replacing velocity with specific orbital energy (easily calculated from in-game data) would allow such a formula to be initial-altitude independent.

By the way, have you considered expanding your calculator to 3D so that the effects of orbital inclination can be included?

Might be something to consider adding, though I'm worried about making the calculator too complicated/daunting to newcomers. On that note, I've been thinking about adding some sort of "expert mode" with a bare-bones interface that takes your orbital data and spits out a bunch of encounter info, such as max gee forces, time in atmosphere, orbital energies, .etc. A full 3D simulation would fit this sort of tool well.

I still don't quite get the exact same figures as MechJeb reports (do you? should we trust MechJeb as being exact?).

Are you using the same value of Kp = 1.2230948554874 ? (I scraped this number from Mechjeb Source.) Also, are the discrepancies within the margin of error of your input? It's hard to make any conclusions without source code.

Edited September 24, 2013 by alterbaron

[Geschosskopf]

The orbital parameters (current altitude, current speed and periapsis altitude) of:

1) the initial orbit as they enter Duna's SOI (I want to see how much they differ)

2) the final pre-aerobraking trajectory after your course corrections

3) the orbital parameters of the "final" orbit after the aerobraking pass

I didn't get the 1st thing you wanted I'm afraid, because 4 of the 5 ships arrived too closely together to note that. So all I got was the velocity at 90km altitude and the Pe height set there, plus what the Pe ended up being when I actually got to it, and the resulting Ap after aerocapture. This is in the thread referenced above.

The 5th ship got a really bad encounter and had to do the capture from really far away using engines, so just did aerobraking, not aerocapture (lowering Ap from 43 Mm to 886 Km). At its AP, after the capture burn, it was only doing 46m/s relative to Duna but got up to 1226 at 90km. For the other 4, I seem to recall them all being about the same (they arrived within a few hours of each other), somewhere in the 600s IIRC.

The spaceplane was the one that had to capture on engines and as expected, aerodynamics proved troublesome. I ended up aerobraking it rather higher than I would have liked because it was getting unstable.

[Meithan]

That's a surprising amount of change. If you post your initial conditions, I can run it through my MATLAB scripts (the online calculator's a translation of these) to check for agreement.

This is the simulation in question. You should be able to derive the necessary parameters from this:

Initial orbit:
Primary body: Kerbin
Orbit type: elliptic
Specific energy:    -2.01e+06 J/kg
Specific ang. mom.: 1.70e+09 Js/kg
Periapsis altitude:  45.48 km
Apoapsis altitude:  509.68 km
Semi-major axis:    877.58 km
Eccentricity:        0.264
Periapsis speed:    2630.23638 m/s
Apoapsis speed:     1529.95706 m/s

Simulation initial conditions:
x= -1099.32 km, y= -129.69 km, dist= 1106.94 km
vx= 243.71 m/s, vy= 1515.63 m/s, speed= 1535.10 m/s

Running simulation ...

>> Simulation complete <<
Result:  SUCCESS
time= 654.71 s
x= -202.67 km, y= 637.58 km, dist= 669.02 km
vx= 2555.84 m/s, vy=  24.48 m/s, speed= 2555.96 m/s

Final orbit parameters:
Primary body: Kerbin
Orbit type: elliptic
Specific energy:    -2.01e+06 J/kg
Specific ang. mom.: 1.63e+09 Js/kg
Periapsis altitude: -48.34 km
Apoapsis altitude:  603.42 km
Semi-major axis:    877.54 km
Eccentricity:        0.371
Periapsis speed:    2962.92071 m/s
Apoapsis speed:     1358.23231 m/s

In this test, the simulation starts some distance away and stops just after breaching the atmosphere. The "final" orbit is then computed at that point. The change in angular momentum seems to be moving the periapsis below ground. Note the semi-major axis is almost unchanged, though.

However, I should mention that since we did these tests I've been made aware that my program occasionally calculates incorrect initial conditions after computing the orbit from the input parameters. As you know there are some ambiguities in calculating the position and velocity vectors, and I suspect my program's messing up sometimes (something like inverting the velocity vector).

Do run these numbers to see what kind of orbit you get. I think the correct orbit is supposed to crash into the surface (too low a periapsis).

That's true, but you can get a pretty nice function to work with if you parameterize the problem well ...

Yes, I had exactly something like this in mind, but I haven't got down to it. It'd be interesting to produce a two-variable fit of those numbers (final apoapsis as a function of initial periapsis and specific energy would be great), for the more technical players.

[3D] might be something to consider adding, though I'm worried about making the calculator too complicated/daunting to newcomers.

In fact, doing it in full 3D might not be necessary. In the end, we're not interested in the full details of the orbit's orientation in space. The only "3D effect" I'm interested in accounting for is the small difference in calculated airspeed in non-equatorial orbits. This might be included in our codes using a simple approximation without going 3D. For instance, we could ask for the orbital inclination as additional input and assume the periapsis is equatorial (e.g., an argument of periapsis of zero). From that, I think it should be possible to calculate the current latitude as a function of position along the orbit, and then use that to subtract the correct rotation speed. I'm still not entirely sure this is the largest outstanding source of error, though.

On that note, I've been thinking about adding some sort of "expert mode" with a bare-bones interface that takes your orbital data and spits out a bunch of encounter info, such as max gee forces, time in atmosphere, orbital energies, .etc. A full 3D simulation would fit this sort of tool well.

That'd be awesome. I love looking at all the numbers.

Are you using the same value of Kp = 1.2230948554874 ?

I'm using exactly 1.223094855. Close enough to the one MechJeb uses. I'll try to find an example of the said discrepancy between my numbers and MechJeb's. We could then cross-check with your code.

Also, are the discrepancies within the margin of error of your input? It's hard to make any conclusions without source code.

This might be the explanation. I'll try to estimate the margin of error in the input and how it propagates in the calculations to see if this is it. But I feel the air drag figure is off by more than it should be.

[Meithan]

I didn't get the 1st thing you wanted I'm afraid, because 4 of the 5 ships arrived too closely together to note that. So all I got was the velocity at 90km altitude and the Pe height set there, plus what the Pe ended up being when I actually got to it, and the resulting Ap after aerocapture. This is in the thread referenced above.

The 5th ship got a really bad encounter and had to do the capture from really far away using engines, so just did aerobraking, not aerocapture (lowering Ap from 43 Mm to 886 Km). At its AP, after the capture burn, it was only doing 46m/s relative to Duna but got up to 1226 at 90km. For the other 4, I seem to recall them all being about the same (they arrived within a few hours of each other), somewhere in the 600s IIRC.

The spaceplane was the one that had to capture on engines and as expected, aerodynamics proved troublesome. I ended up aerobraking it rather higher than I would have liked because it was getting unstable.

Thanks for logging the data! I'll have a look at the numbers and report back when I can.

By the way, since the forum went down I completed an aerocapture and two aerobraking passes around Eve. This is how the predictions of the program compared to what happened in the game:

[Geschosskopf]

By the way, since the forum went down I completed an aerocapture and two aerobraking passes around Eve. This is how the predictions of the program compared to what happened in the game:

Looks like your numbers are crunching pretty accurately. Congrats . Did you actively change your Pe between passes or just let nature take its course?

What I would like to see come out of all this is a mod to provide in-game instrumentation on the map screen. IOW, make it so the future path predicted on the map screen includes the effects of both atmosphere and gravity instead of the way it is now with just gravity. That way, folks could eyeball aerocapture/braking the same way they do other orbital maneuvers. Just go to the map view, tweak the Pe up and down, watch the predicted orbit grow and shrink on the far side, and stop when they get what they want. This would save all the potentially dangerous F5/F9 (as in hitting F5 when you meant to hit F9) repetition or having to use something outside the game.

One thing I've noticed in general about KSP orbital predictions is that their accuracy decreases as distance increases. Thus, a Pe set using prograde or retrograde burns at long distance will surely wander up or down a noticeable amount as you near the planet. Because of this, I do my final Pe adjustment as late as possible. And I make these final corrections with radial burns because they provide finer control than those along the path of travel. Now, I noticed above that you mentioned using the initial energy as a starting point for your predictions, but it occurs to me that radial burns increase velocity due to vector addition. Would that throw the predicted results off?

[Meithan]

Looks like your numbers are crunching pretty accurately. Congrats . Did you actively change your Pe between passes or just let nature take its course?

Because the predictions can be slightly off, I updated them before each aerobraking episode, inputting the actual orbit produced by the last.

For the first aerobraking after aerocapture, the prediction was that the current periapsis was still good, so I just let nature take its course. For the second, the simulation predicted a crash if I followed my current trajectory. So I had to do a minor correction burn to raise the periapsis from 62.987 km to 68.063 km. Five kilometers made the difference between mission failure and a nice low Eve orbit!

That and the previous burn to place the periapsis within the atmosphere for aerocapture was the only delta-v expenditure I needed for the insertion. It was almost free!

What I would like to see come out of all this is a mod to provide in-game instrumentation on the map screen. IOW, make it so the future path predicted on the map screen includes the effects of both atmosphere and gravity instead of the way it is now with just gravity. That way, folks could eyeball aerocapture/braking the same way they do other orbital maneuvers. Just go to the map view, tweak the Pe up and down, watch the predicted orbit grow and shrink on the far side, and stop when they get what they want. This would save all the potentially dangerous F5/F9 (as in hitting F5 when you meant to hit F9) repetition or having to use something outside the game.

That would certainly be awesome. Using alterbaron's simpler numerical solver and keeping calculations to the minimum necessary, I believe the prediction could be calculated in real time (alterbaron's calculator is nearly instantaneous). I have no modding experience, however. I wonder how complicated that is.

One thing I've noticed in general about KSP orbital predictions is that their accuracy decreases as distance increases. Thus, a Pe set using prograde or retrograde burns at long distance will surely wander up or down a noticeable amount as you near the planet. Because of this, I do my final Pe adjustment as late as possible. And I make these final corrections with radial burns because they provide finer control than those along the path of travel. Now, I noticed above that you mentioned using the initial energy as a starting point for your predictions, but it occurs to me that radial burns increase velocity due to vector addition. Would that throw the predicted results off?

Like alterbaron's, my program actually takes as input numbers that are readily available in vanilla KSP: current speed, altitude and periapsis. However, you're correct in that a radial burn (when not at periapsis or apoapsis) will change the orbital energy a bit. Alterbaron's calculator is clever in that it outputs a maneuver that will leave your speed unchanged so as not to alter your orbital energy (it's simple: just thrust perpendicular to your direction of travel). The only thing that changes then is the specific angular momentum (and thus, the periapsis).

However, in my experience, if the periapsis change is small, the prediction will still be accurate enough. What I've done in the past to be sure is: (1) start with a periapsis slightly above the atmosphere (I usually try set it at the midcourse correction); (2) calculate the required periapsis change using the simulator, (3) perform the correction (usually at arrival to the planet's SOI), (4) re-calculate the prediction with the new orbital parameters to be sure it's still good (and to account for the fact that the precision of the orbital maneuver is limited, especially when using the main engine, so the actual final periapsis might be a couple hundred meters off).

I think the biggest error in the calculated orbital trajectories in the game occurs when doing SOI switches. I've found that once i'm inside the SOI, the calculated trajectory is pretty accurate. I can set my aerobraking trajectory from SOI arrival and then just ride along from that point.

[Geschosskopf]

That would certainly be awesome. Using alterbaron's simpler numerical solver and keeping calculations to the minimum necessary, I believe the prediction could be calculated in real time (alterbaron's calculator is nearly instantaneous). I have no modding experience, however. I wonder how complicated that is.

Maybe put out some feelers to some modders to see if they'd be interested in a collaborative effort?

I think the biggest error in the calculated orbital trajectories in the game occurs when doing SOI switches. I've found that once i'm inside the SOI, the calculated trajectory is pretty accurate. I can set my aerobraking trajectory from SOI arrival and then just ride along from that point.

Yeah, when SOI changes, all bets are off . But even so, I usually find at Pe set out at the edge of SOI will move several kilometers before I get near it. I guess it depends on where you are.

[pa1983]

I always go for 10.5Km with my spaceplanes on Duna at about 1500-1600m/s peek velocity and wings make a big difference, I usually end up at 12km periapsis because of the 20 or so degree nose up.

[alterbaron]

This is the simulation in question. You should be able to derive the necessary parameters from this:

<SNIP>

...

I tried running this simulation. However, the initial trajectory is suborbital. I've verified this with hand calculations as well.

Here's the initial orbital parameters I get using your x,y,vx,vy values:

=> ep: -2012142.246324
=> ec: 0.371383
=> h: -1634555621.700000
=> a: 877572.151386
=> rpe: 551657.201923
=> rap: 1203487.100848
SS1 (initial suborbital)

(Note distances relative to Kerbin center).

I get the same value of specific orbital energy as you do. However, the value for the specific angular momentum h in your previous post is incorrect.

It looks to me that you calculated h by simply multiplying the magnitudes of the position and velocity vectors (I get your value of about -1.70e9 this way).

This only works if the two vectors are perpendicular, which is not the case in this example.

Rather, h = rx*vy-ry*vx, giving h=-1.63e9.

Edited September 28, 2013 by alterbaron

[Meithan]

I tried running this simulation. However, the initial trajectory is suborbital. I've verified this with hand calculations as well.

[...]

I get the same value of specific orbital energy as you do. However, the value for the specific angular momentum h in your previous post is incorrect.

Yes, I apologize for this example. As I mentioned, my program's been occasionally calculating incorrect initial conditions from the provided input parameters. It's unfortunate that I chose one of these cases as an example. The sudden change of angular momentum was due to the incorrect position/velocity determination. Please disregard that post.

Since then, Specialist290 has been running more tests, doing aerobrakes ingame and comparing to my program's predictions. I still don't know what's causing the bug in my program, but I've found starting the simulation at atmospheric contact seems to be avoiding it.

Right now we're trying to determine if the drag calculation in my program can be made more accurate.

Edit: here are my calculations, in case you want to check them:

Orbit determination from position and velocity vectors

Edited September 28, 2013 by Meithan

[alterbaron]

Yes, I apologize for this example. As I mentioned, my program's been occasionally calculating incorrect initial conditions from the provided input parameters. It's unfortunate that I chose one of these cases as an example. The sudden change of angular momentum was due to the incorrect position/velocity determination. Please disregard that post.

...

Edit: here are my calculations, in case you want to check them:

Orbit determination from position and velocity vectors

From a quick read-through, your derivations look good. Just a couple of comments:

In your formula for eccentricity, the specific angular momentum H0 should be squared.

Edit: I see you did this later in the document, so this first instance is just a typo.

Otherwise, the only thing I'd say is to be careful when taking sin(phi) = sqrt(1-cos^2(phi) ). Depending on phi you might need the negative root.

Edited September 28, 2013 by alterbaron

[Meithan]

From a quick read-through, your derivations look good. Just a couple of comments:

In your formula for eccentricity, the specific angular momentum H0 should be squared.

Edit: I see you did this later in the document, so this first instance is just a typo.

Otherwise, the only thing I'd say is to be careful when taking sin(phi) = sqrt(1-cos^2(phi) ). Depending on phi you might need the negative root.

Yes, it's a typo. Thanks for pointing that out.

I'm almost sure the occasional error in my program is due to a sign ambiguity like that. The program juggles around a lot with these equations (going from (rpe,v,r) to orbital parameters, then from orbital shapeto position and velocity vectors given an angle, then back from new vectors to parameters, from a distance to an angle given the orbit shapte, etc.).