[WIN/MAC/LINUX] KSP Trajectory Optimization Tool v1.6.10 [Major LVD Improvements!]

[billeinstein]

Yep, thanks for explaining that. Very interesting as always.

About SoI radius, agreed. I know they are just an assumption, if true multi-body gravitational fields computing was feasible, we would treat SoI just as an indicator of the relative gravitation force. That was the approach with the Orbiter Space Sim, at least that had 3-body computing and SoI was given with a percentage of the relative strength. With the limit of 2-body computing that KSP has, a SoI is really an artificial boundary, suddenly the gravity a craft is subject to wholly changes from one to another center of mass. But then, you mean KSPTOT, instead of using SoI to switch to a different center of gravity, is using true newtonian gravity with all the centers of mass along a trajectory?

When calculating the transfer trajectory, the gravity of source and target planets are ignored. Only the central body(sun) counts. With this transfer trajectory, we can get the difference of V between it and the source or target planet orbit. That's the V(infinity) of the escape or insert trajectory. That's the way KSPTOT and some MFDs(IMFD, TransX) in orbiter work. SOI radius shall be large enough, or it will become a Rendezvous and docking problem.

It's some difference between ksp and real world physics in calculating the Multibody gravity. So does this conic path method. That's why we need mcc during the transfer.

[billeinstein]

Additionally, the SOI in Orbiter (where the reference body is changed) is not the same SOI in astrodynamics and in KSP.

http://en.wikipedia.org/wiki/Sphere_of_influence_(astrodynamics)

Actually, the moon get more gravity from the sun than the earth. But it's still in the earth's SOI.

The SOI problems in KSP can be something like an Elliptical orbit with its Apoapsis just outside the SOI (an elliptical escape trajectory). But this is not important in interplanetary transfer.

[diomedea]

Actually, most if not all you said, I already know. You don't actually answer the question, that is about other centers of mass along a trajectory, not the source or target bodies. Orbiter and its navigation tools I used for quite a long time, so those are known as well. From what I wrote before, you may note that I put a clear distance in the way Orbiter and KSP compute SoI influence. About astrodynamics, it depends. KSP computes SoI exactly the same as the formula in that Wikipedia page (I do use that formula in my own calculations, and found already it matches with KSP); I can't say if that is different in Orbiter as I never checked the accuracy, but the results with the SoI in Orbiter are impressively realistic.

Anyway, the following sentence I believe is a mismatch:

Actually, the moon get more gravity from the sun than the earth. But it's still in the earth's SOI.

If the gravitational field of the sun was really greater than Earth's at the Moon - Earth distance, Moon would escape from Earth's gravity and become another "planet" orbiting Sun. The SoI limit, as really defined in astrodynamics, is where the gravitational field is greater from the body at its center than from any other. That is the reason why no satellites exist outside of the SoI of any of the planets in reality. To give crude numbers, Earth's SoI at 925,000 Km easily includes the Moon, orbiting at a distance between 363,295 and 405,503 Km from Earth (though, more correctly, both Earth and Moon orbit around their common center of mass).

[Arrowstar]

Diomedea, could you repeat your question? I can try answering it then.

[billeinstein]

Anyway, the following sentence I believe is a mismatch:

Just try and calculate it.

[diomedea]

Diomedea, could you repeat your question? I can try answering it then.

Yes, the question was:

... you mean KSPTOT, instead of using SoI to switch to a different center of gravity, is using true newtonian gravity with all the centers of mass along a trajectory?

That question arises to me as you wrote that KSPTOT uses infinitesimal SoI radius. Now, that may mean what I put in the question (true multibody computation along the trajectory, that makes the SoI not relevant) or the opposite, discard any other body (solving for 2-body only) as those infinitesimal SoI are never entered along the trajectory. The question is, really, about the correctness of KSPTOT solution in the case of a third body along the trajectory.

[diomedea]

Just try and calculate it.

What you mean, you did the calculation wrong and are trying to demonstrate what is a physical impossibility?

[billeinstein]

What you mean, you did the calculation wrong and are trying to demonstrate what is a physical impossibility?

Earth-Moon gravity is about 2.0E+21N, and Sun-Moon gravity is about 4.4E+21N.

[diomedea]

Earth-Moon gravity is about 2.0E+21N, and Sun-Moon gravity is about 4.4E+21N.

I see. I suspected you were making that mistake, and now i have that confirmed. You did not consider that Sun gravitation acts on the Earth-Moon as a system. While Sun gravity acts on the Moon, it acts also on Earth, and the two move (fall) towards the sun together.

The correct way to calculate Sun gravitation acting on the Moon is as the difference with respect to the gravitation affecting Earth. This difference is greater when Moon is closest to Sun (new moon) than Earth, and the distance Earth-Moon is greatest (405000 Km): the differential gravity is 2.37E+18, against Earth gravity on Moon at that same distance of 1.784E+20

[billeinstein]

I see. I suspected you were making that mistake, and now i have that confirmed. You did not consider that Sun gravitation acts on the Earth-Moon as a system. While Sun gravity acts on the Moon, it acts also on Earth, and the two move (fall) towards the sun together.

The correct way to calculate Sun gravitation acting on the Moon is as the difference with respect to the gravitation affecting Earth. This difference is greater when Moon is closest to Sun (new moon) than Earth, and the distance Earth-Moon is greatest (405000 Km): the differential gravity is 2.37E+18, against Earth gravity on Moon at that same distance of 1.784E+20

This is not the gravity between Sun and Moon, but the Tidal force(axial). And it should be about ~E+19 at the distance of the moon.

http://en.wikipedia.org/wiki/Tidal_force#Mathematical_treatment

[billeinstein]

And this is why I point out the SOI in Orbiter is not the same one in KSP.

[Arrowstar]

Yes, the question was:

That question arises to me as you wrote that KSPTOT uses infinitesimal SoI radius. Now, that may mean what I put in the question (true multibody computation along the trajectory, that makes the SoI not relevant) or the opposite, discard any other body (solving for 2-body only) as those infinitesimal SoI are never entered along the trajectory. The question is, really, about the correctness of KSPTOT solution in the case of a third body along the trajectory.

KSP TOT is using a two-body model of gravitation. In Mission Architect, that model is exactly the same as Kerbal Space Program's model, including SoI radii. In every other function, local gravity fields around a central body (such as Kerbin around the Sun) are assumed to be "small", by which I mean to say "can be approximated as infinitesimal." In neither case am I using N-body gravity, the purpose of the tool being to model orbits in KSP.

The question is, really, about the correctness of KSPTOT solution in the case of a third body along the trajectory.

The KSP TOT solutions are a near approximation of the motion with mathematical simplifications included to ease calculations and CPU run time. They are correct enough for most mission/maneuver planning purposes.

If a third body shows up, it only becomes relevant if it's part of the problem. That is, if it's a destination or departure point, it's included in the calculations. If it's not, them it's ignored, and rightly so.

Does that answer the question?

Also, billeinstein and diomedea, while I appreciate the conversation, let's make sure we stay on topic here, please.

EDIT: And here's a nice image of the optimizer observer mock up I put together tonight:

Edited February 6, 2014 by Arrowstar

[diomedea]

Does that answer the question?

Yes, that answered my question perfectly. No third body is considered along the trajectory, and that fits completely with KSP model. Correct enough for most maneuvers, instead of any maneuvers. But certainly the best approach for fast solution and, given the limits of KSP universe, adequate to the task.

The real issue is with the KSP model, while ships go "on rails" their trajectories are stored instead of updated, and that is not only in regard of eventual third bodies, there is no aerobraking either when periapsis is lower than the atmospheric height. In KSP (for what I can observe) the trajectory of a ship when loaded diverges from the trajectory stored when the same ship is "on rails".

BTW, nice Mission Optimizer mock up.

[diomedea]

This is not the gravity between Sun and Moon, but the Tidal force(axial). And it should be about ~E+19 at the distance of the moon.

http://en.wikipedia.org/wiki/Tidal_force#Mathematical_treatment

I totally agree with Arrowstar, this discussion has taken out of context. Until it was something related to the SoI dimensions and how they effect computations, it could be fine. Now, you have put it on tidal effects (that are within the same body, due to its mass not being concentrated in a single point, so a very different thing) instead of gravitation applied to a system. Also, my formulas don't have some G=9,81 factor too much.

But this discussion must be taken apart. If you like to continue on this subject, better to have it somewhere else. I believe we both can learn something keeping on this, but not here.

[billeinstein]

Sorry for the mistake of G, I used E-10. It shall be E-11.

[Arrowstar]

The real issue is with the KSP model, while ships go "on rails" their trajectories are stored instead of updated, and that is not only in regard of eventual third bodies, there is no aerobraking either when periapsis is lower than the atmospheric height. In KSP (for what I can observe) the trajectory of a ship when loaded diverges from the trajectory stored when the same ship is "on rails".

It's a computational simplification they made. Maybe not the most accurate, but it's good for 99% of all cases.

But this discussion must be taken apart. If you like to continue on this subject, better to have it somewhere else. I believe we both can learn something keeping on this, but not here.

Thanks guys, this is what PMs are for.

[Specialist290]

Well, looks like this app has some nifty new features since I last took a look at this thread The new KSPTOTConnect and Mission Architect look like they should be most handy -- no more bouncing between three or four different programs or screens to get everything set for my mission plan.

[Galane]

So if you're concerned about your trajectory coming close to Duna on the way out to Jool, fly some other ship as it goes past and KSP will ignore the effect a Duna flyby should have?

[Arrowstar]

Well, looks like this app has some nifty new features since I last took a look at this thread The new KSPTOTConnect and Mission Architect look like they should be most handy -- no more bouncing between three or four different programs or screens to get everything set for my mission plan.

Thanks! I look forward to hearing about what you think of them. As a heads up, Mission Architect is still under heavy development and has not been release yet. It's coming in v0.12.

So if you're concerned about your trajectory coming close to Duna on the way out to Jool, fly some other ship as it goes past and KSP will ignore the effect a Duna flyby should have?

Err, what? No, KSP handles the trajectory of each spacecraft independently.

So I got the optimizer viewer window set up this evening. It's pretty slick. Here's a screenshot:

Barring no major bugs, I suspect the only thing between me and an initial pre-release is some more investigation into why the code runs as slowly as it does in some places. I suspect it has to do with finding SoI transitions downward in the celestial body hierarchy (Sun -> planets, planet -> moons). In any event, this calls for some SCIENCE (and a profiler)!

[tavert]

Would need to look at the time break down, but MATLAB is doing the gradients in parallel. MATLAB is doing finite differencing; there is no analytical gradient for this problem. Optimization variables for this run is a true anomaly for departure burn and the right ascension, declination, and magnitude of the burn (better than three rectilinear components for optimization).

Why would there not be a gradient? SoI transitions are discontinuous, but with a lifted formulation adding additional variables and constraints there should be a way to express the whole problem in a differentiable way. It's generally better to have more variables with a simpler nonlinearity structure than trying to do finite differencing on a smaller number of variables with all functions as black boxes.

I agree that I probably just screwed it up somewhere. I vectorized the functions that convert to and from Keplerian orbital elements to position/velocity vectors. These are fairly complex functions with a fair bit of logic in them, plenty of room for error. If you'd like to take a look, shoot me a PM and I'll send you what I've got.

I imagine the logic could be difficult to do correctly, it's easy to resort to a couple of "find" functions that will absolutely kill your speed. Logical indexing usually works nicely, but requires some care. I can look at things if you want some Matlab profiling help, are there similar functions or test cases in the released version of KSPTOT that would run the existing implementation?

[Arrowstar]

Why would there not be a gradient? SoI transitions are discontinuous, but with a lifted formulation adding additional variables and constraints there should be a way to express the whole problem in a differentiable way. It's generally better to have more variables with a simpler nonlinearity structure than trying to do finite differencing on a smaller number of variables with all functions as black boxes.

Ah. My problem isn't so much the SoI transition problem, I have that fairly well figured out. It's more the general case of "modify these delta-v locations and vectors to achieve such and such an objective subject to these constraints." How would I go about formulating an analytical gradient to a problem such as this?

I imagine the logic could be difficult to do correctly, it's easy to resort to a couple of "find" functions that will absolutely kill your speed. Logical indexing usually works nicely, but requires some care. I can look at things if you want some Matlab profiling help, are there similar functions or test cases in the released version of KSPTOT that would run the existing implementation?

Cool. Mind if I send you a PM with the .m file functions?

[Iron4venger]

Hi dude, I was wondering if you have time to craft a little tutorial for gravity assists, using this little wonder of yours

Thanks for your time!

[tavert]

Ah. My problem isn't so much the SoI transition problem, I have that fairly well figured out. It's more the general case of "modify these delta-v locations and vectors to achieve such and such an objective subject to these constraints." How would I go about formulating an analytical gradient to a problem such as this?

That question reduces to, can you formulate the problem in such a way that the objective function and constraints are differentiable? Logic and switching could make that rather complicated, but it depends on the specifics of the objective and constraint functions. If you can write Matlab code to evaluate them in the first place, then you should have enough information for an automatic differentiation library to do the rest of the work. It's not something I would try to do symbolically, I would use an AD library. For C++ ADOL-C and CppAD are very good, I'm not so sure if there are any good open-source tools for doing the same thing entirely within Matlab. This page http://www.i2c2.aut.ac.nz/Wiki/OPTI/index.php/Advanced/Deriv1 looks like a pretty good reference on the topic. I'll frequently use Matlab or Python to put the problem together in the first place but then output an optimization problem representation that a compiled solver can read and do AD on - either OSiL which is XML-based, or .nl which is used by AMPL and not really human-readable (but Pyomo knows how to write them).

Cool. Mind if I send you a PM with the .m file functions?

Sure, go for it. Some test inputs would help too, I imagine you already know where the bottlenecks are and what's most important to look at.

[ANWRocketMan]

@ArrowStar, this has probably been asked before but I haven't kept up to date with the forums at all:

Would your TOT for Orbiter work for Real Solar System? Does it take into account N-Body physics and such?

[Arrowstar]

Hi everyone:

I'd like to announce the (pre-)release of KSPTOT v0.12. This is a pre-release edition. The application may be unstable, features will be missing, and no source code is included. The principle new feature in KSPTOT 0.12 is Mission Architect, which I've been showing off for a while now. The download link for this pre-release is here:

KSPTOT v0.12 Pre-Release 1

I would encourage everyone interested in testing the new software to please go ahead and do so. All I ask is that if you find bugs or have feature requests, you please let me know in this thread so I can handle them.

Mission Architect is accessible from the main KSPTOT GUI by going to Tools -> Mission Planning -> Mission Architect.

Okay, enough of the serious talk: go at it, everyone, and let me know what you think!

Also, to everyone who posted above, I will get to responding to you shortly.