You are not logged in.
This topic is a companion to the 2-body topic created earlier.
The distinction is that 2-body problems can be solved.
n-body problems ( I understand ) cannot be "solved" but computer approximations can come pretty close.
In any case, this topic is available if NewMars members would like to collect links, images or text relating to this issue.
I would like to see practical computer solutions that will run on the personal computers of members.
However, web sites that offer animations of various scenarios would be appreciated.
The immediate opportunity for current NewMars members is to find a solution that allows study of the approach of an asteroid to a planet. There are two obvious possibilities, and one that I would like to see for study.
1) The asteroid will approach the planet and collide with it.
2) The asteroid will approach the planet but fly past it
The scenario I am interested in is the capture scenario. This can (and does) happen when the combination of velocities and directions permit the gravitational pull of the planet to pull the asteroid into an ellipse.
Update: A factor in the ability of a body to attract another is the strength of the gravitational field compared to the inertia of the passing object.
(th)
Offline
Like button can go here
This post is reserved for an index to posts that may be contributed by NewMars members over time.
Index:
Post #3: kbd512
https://newmars.com/forums/viewtopic.ph … 04#p232204
Discussion of numerical methods for flight planning (description is a first guess)
(th)
Offline
Like button can go here
tahanson43206,
There are only numerical methods for solving 3-body problems using the equations of motion, and despite the fact that we're dealing with a chaotic system, the accuracy of the solution is generally increased by increasing the number of time steps used by the numerical solver, so this sort of solution will always be computationally-intensive.
However, I would propose a hybrid approach that provides a "good enough" approximation to use for mission planning:
1. For a fixed set of bodies (Sun, Earth, Mars) Create a multi-dimensional table of coefficients describing the gravitational acceleration vector values for the bodies involved, based upon distance from the surface of the planet. This should be feasible because we're only going to launch from certain places, along specific trajectories, the orbits of planetary bodies about the Sun are periodic in nature. The planets are so far apart from each other that their gravitational interactions are quite small, which is at least part of why the orbits are stable to begin with, although the overwhelming mass of the Sun obviously has the greatest influence.
We're not trying to store all the coefficients for every possible trajectory or point in space between all bodies involved, merely the ones describing the net acceleration effect along practical intercept trajectories (a "corridor of space" similar to a shipping lane) from orbits accessible from actual launch sites (KSC, Boca Chica, Vandenberg).
There's no fuel burn optimizer to tell a ship's Captain how to optimally power itself and what course to plot to go from Port of New York to Port of London, via the Pacific Ocean, for example, because no real world fuel burn shipping optimization problem involves doing such an asinine thing. In reality, you're going to sail through a part of the Atlantic Ocean that helps reduce your ship's fuel burn rate by using the current to its advantage, or minimizing losses when fighting against the current. The same constraining of stored data applies here to reaching Mars from Earth. A 3BP optimization involving a direct ascent trajectory, launching from the North Pole towards Mars, is of academic interest only.
Applying that restriction to the stored data reduces the quantity of data contained in the lookup table from an infinite number of values to a highly constrained set of values. We would use the coordinates for these "assigned blocks of 3-dimensional space" and applicable gravitational acceleration vector coefficients to plot our minimum energy trajectory from Earth to intercept Mars.
2. For a given initial starting point in time, use those "lookup values" to compute their effect on the velocity of the spacecraft to approximate their effect on vehicle acceleration magnitude and direction. Anything that veers outside of the stored table of coordinates either requires a spacecraft Delta-V input (trajectory adjustment using onboard propulsion systems), or it doesn't, in which case that solution is "more optimal" because it requires no Delta-V increment applied by the propulsion system. Set limits on how much total Delta-V you're willing to devote to mid-course correction burns, so you can reject any solutions that exceed your onboard propulsion capabilities.
3. With the range of potential solutions appropriately restricted, you're now left with something that ceases to attempt to derive a solution the moment established onboard propulsion limits are exceeded. Better still, you no longer need to compute the results for a series of differential equations because you've already derived that output. That should drastically reduce the computational power required. If relevant parts of the table data are loaded into memory only as required, that also tends to improve execution time.
What do I actually mean we should do here to arrive at potential solutions with personal computing hardware?
For points in space inside the Lagrangian Plane associated with the planetary body in question, compute and store the results from the differential equations required to describe the effect on the trajectory of the vehicle as a result of the 3BP. For points in space outside of the Lagrange Point, where gravitation from the Sun has the greatest effect on the motion of the vehicle, revert back to solving a 2BP since that is easily determined using analytic methods. If/when the vehicle trajectory arrives at the Lagrangian Plane associated with the destination body, then revert back to using the table lookup values to reduce the compute-intensity of a 3BP.
Assuming you intend to minimize future Delta-V input using your onboard propulsion system (propellant consumption from mid-course correction burns), your initial trajectory also has the greatest overall effect on where you end up at the time step coinciding with breaking the Lagrangian Plane upon arrival near the target body since there are an ever decreasing number of time steps remaining to intercept (or miss) as you proceed along your outbound flight trajectory. If you're going to bother with continuing to compute the results for a 3BP past the Lagrangian Plane, then that should probably only be done on the outbound portion of the flight trajectory while you're still relatively near Earth, assuming the target body is a planet with the mass of Mercury / Mars / Venus. That probably doesn't hold true for a much more massive body such as Jupiter / Saturn / Neptune / Uranus.
GW,
If that seems like a reasonable approach, please let me know. I know very little about orbital mechanics. This is just an idea for reducing the computing power and time required. If there's some reason this won't work, please let me know.
Offline
Like button can go here
If anyone not currently a member of NewMars would like to help to fill out this topic, please see Recruiting topic for procedure.
I would like to see GMAT in use by members. GMAT is a free package supported by NASA (to some extent.... it may be NASA employees volunteering)
The feature of GMAT that folks should be aware of is that while the package is free and it runs on Linux (and other OS) the MATLAB component requires a license. The license cost for a non-student non-commercial user is modest, but it is not zero.
There may be other navigation solutions that will run on personal computers and which do not require MATLAB.
(th)
Offline
Like button can go here