Fridger,
Thanks for the physics perspective...
t00fri wrote:
What can straightforwardly be treated is the gravitational potential arising from a sum of gravitational point charges.
That is essentially the aim of (at least the first version) of this addon. It might be possible to cater for some of the more advanced calculations in future, but at least for the first iteration, the aim is to keep it simple.
The basic idea is:
On each iteration of the ScriptedOrbit....
-- re-calculate the direction and distance to each "influence" which is being considered
-- calculate velocity adjustment to the trajectory in the form of a small vector for each "influence"
-- the sum of all these vectors gives the overall deltaV (for the timeslice)
-- calculate the new position by extension from the prior position and velocity.
The critical functions not shown in the code above (but, I'm sure everyone will recognize) are of course:
Quote:
GravitationalConstant = 6.67E-11
-- GRAVITY
-- calculate acceleration in m/s/s due to the force exerted
-- by the mass (m) in kg, at the range (r) in meters
function gravity( m, r )
return GravitationalConstant * m / r / r;
end
-- KINEMATICS
-- calculate change in velocity as a result of
-- acceleration (a) in m/s/s over time (t) in seconds
function deltav( a, t )
local v = a * t;
return v
end
-- calculate distance traveled as a result of
-- acceleration (a) in m/s/s over time (t) in seconds
-- with initial velocity (v) in m/s
function distance( v, a, t )
local d = (v * t) + (0.5 * a * t * t);
return d
end
t00fri wrote:
You surely remember that already the (non-factorizable) gravitational 3-body problem has no closed solution. In some corners of the celestia(.Sci) Universe the conditions for a decent approximative implementation are presumably met. But there are many regions where the opposite is true...and it is hard to know the boundaries!
Agreed. However, the aim for version 1 is to be able to do a reasonably accurate job of simulating interplanetary trajectories (eg. Hohmann transfers), and gravity assists. For the first of these aims, at interplanetary distances I think we can certainly assume
most "attractors" to be gravitational points.
In the case of gravity assists, these generally require getting rather close to the "attractor", and I expect that perturbations due to the non-spherical nature of the body may become significant (although these generally are of a periodic nature, so maybe for a fast encounter at low latitudes, where we're not in a highly inclined and/or low orbit for a long period, we can reasonably get away with ignoring these effects.) -- It all depends on how large these perturbations are? ... and how much error we are willing to live with. (This is surely a more serious issue with the gas giants than with the smaller rocky objects.)
Likewise, I'm not planning on modeling the effects of atmospheric drag, or differences in gravity due to geologic features. (So no aero-braking scenarios possible. Sorry!
)
t00fri wrote:
Just think of travelling with your spaceship across the Jovian system, with Jupiter deviating substantially from a spherical shape (<->big gravitational charge without spherical symmetry!). The Saturn system with its very large number of fast-moving moons is another cracker...
Yes, I have thought of such scenarios, and the lack of spherical symmetry is I'm sure a significant factor in any trajectory which is significantly inclined from the planet's equator. And of course the gas giants are popular targets for gravity assists, so I will probably need to model these effects at some point.
As far as the fast moving moons are concerned, I think this addon can handle that scenario OK by virtue of the fact that the code will constantly (i.e. on every iteration) re-calculate the direction and magnitude of the vector from the spacecraft to each "influence":
Code:
local ivector = testpos:vectorto(attractorpos)
t00fri wrote:
What can and has long been implemented is mostly a gravitational analog of the Hartree-Fock method in Electrodynamics. In our context, it is called VSOP87 and part of celestia(.Sci). Here one lumps many gravitational charges into a phenomenological gravitational background "cloud" and then calculates the movement of a body of interest in the resulting static field.
I'm assuming of course that the VSOP87 implementation is not exposed to the LUA API.
To sum up, I expect that this addon will initially be capable of doing a reasonably accurate simulation of interplanetary trajectories, and may require some further refinement to handle accurate gravity assists as well.
If I want a spacecraft to go into a close orbit, then a Timeline can always be used to insert it into an EllipticalOrbit implementation. (But then, that's not necessarily any more accurate than this technique, anyway, as EllipticalOrbit's do not access VSOP87 do they?)
Thoughts?
Cheers
CC
PS. All of the above is moot at this point, as I'm still struggling with the limitations of the LUA API (and my own limitations) to get a proof-of-concept up and running.
Login
Register
FAQ
Search
