Search results

Yep. Thanks. Now fixed. (I generally write these notes in a LaTeX-friendly Markdown script before transcribing them to OF. Because of OF limitations, this entails a manual editing of each and every LaTeX line and sometimes my editing isn't quite perfect). Here's my C code snippet that I...

Introduction In the thread in the Maths & Physics section J4 - J5 perturbations, it was pointed out that that the gravitational perturbation calculations needed to be carried out in the Earth-centred Earth-fixed (ECEF) reference - i.e., one that is centred on the Earth but rotates along with the...

Thanks for the link. It's useful to have a record of where the data files can be found. A quick glance at the EGM2008 files suggests that aside from a slight change in format the coefficient normalisation is the same as for the EGM96 model parameter data file - so, the same core calculations...

The purpose of this post is to explain the derivation of the C code used to calculate the gravity perturbation in the 'EGM96' Earth Gravity Model. As such, it is mathematical 'backfill' and a 'for the record' contribution to this thread. Part of this thread's earlier dialogue included: In...

For those following this thread, you will undoubtedly have seen some Mathematica, Python and C code for calculating the perturbation terms of a body's gravitational force. And it may well have seemed that the force calculations in these notes seemed to have been manufactured 'from thin air' and...

Yay! :)

Fixed - not a memory allocation problem but updating the FS matrix wasn't indexed properly. My bad. Again, the code has been updated in the above. Output should now read; 0.0017603492 0.0018629822 -0.0109476821 Program ended with exit code: 0 I'll check against the GeographicLib results...

For the time being, I've commented out the 'free' statements in the above C code. I'm getting: 0.0017397646 0.0018737419 -0.0108815201 Program ended with exit code: 0 Give me a few hours and I should be able to sort out the memory allocation problem. ---------- Post added at 10:47 AM...

Yes, it is - but does the prime meridian of the SPICE's equivalent of an ECEF frame have a prime meridian that always passes through Greenwich? It should - but it's worth checking. Yes, they are outside the m-cycle, but inside the n-cycle. Just a brief note on Python quirks: for n in...

Probably not. The EGM96 model expresses the gravity perturbations in terms of coefficients of a class of functions called the 'fully-normalised Associated Legendre Functions'. As far as I can work out, the reason for doing this is to avoid overflow/underflow problems at high expansion orders...

Yes, give me a few days to get the recursion scheme right and I can upgrade the code to a full gravity model (a la EGM2008) ---------- Post added 05-08-18 at 07:37 AM ---------- Previous post was 05-07-18 at 10:48 AM ---------- Well, here (in Python!) is the expanded recursion scheme for...

I've tided up the code a little for the core function call. Here it is: #include <stdio.h> #include <stdlib.h> #include <math.h> int perturbations( // inputs double x, // the x-coordinate of the spatial point (earth-centric equatorial)...

In case this is useful, here is a short C code snippet that calculates the x, y and z components of the perturbative forces for the 'zonal' contributions as per the above up to a maximum order 'nmax' (currently, 5). #include <stdio.h> #include <stdlib.h> #include <math.h> /* Define the...

cristiapi: The wikipedia article that you referenced (Geopotential model) contains the following expression for the Earth's gravitational potential: u = -\frac{\mu}{r} + \sum_{n=2}^{N}\frac{J_n\,P_n(\sin\theta)}{r^{n+1}}+\dots where \sin\theta = z/r and r^2 = x^2 + y^2 + z^2. All of the J_n...

ADSWNJ The solar perturbation is primarily a tidal contribution. Tidal contributions fall off very fast (1 / r^3) so unless we are quite close to a body, they are going to be very small. in the Earth-Moon-Sun system, the Sun's tidal contribution is only significant because it is so massive...

OK, I've made a short youtube video of a transfer to L1. The transfer was designed using the Lambert Solver - but it isn't optimal. Just a 'short' (6 day), simple transfer to demonstrate the fidelity of the Solver solution. See: Don't forget to turn the captions 'on' if you watch the video...

This is the fourth in a series of posts about developing a Lambert Solver for Lagrange points. I've spent the best part of a week testing the accuracy of the Solver in the Elliptic Restricted Three-Body Problem (ER3BP) model of Lagrange points and have verified that, if we ignore assorted...

This post is the third part in a series focusing on the development of a Lambert Solver for trajectories in the vicinity of the Lagrange points of the restricted three-body model. A Lambert Solver solves the two-point boundary problem of determining the trajectory of getting from point 'A' to...

In a recent post, Lambert Solver for Lagrange points I introduced the possibility of building a Lambert Solver tailored to trajectory planning in the vicinity of Lagrange points of, say, the Earth-Moon system or the Sun-Earth system. That post focused on the calculation of trajectories using a...

For Pluto-Charon system, as you say, L2 is indeed heavily perturbed. Basically, trying to calculate the location of L2 is fairly meaningless here. L1 for Pluto-Charon ought to behave a little better, though. But still, because the mass of the other moons aren't negligible, a satellite parked...