You are right, there are no way to use custom Love numbers, and this would be a great improvement!
2 Likes
Some more findings,
I tried to add some additional force models (relativity, Moon albedo, Moon solid tides k3, modelling GRAIL-A with solar array + box model, adding spherical harmonics for Earth up to 4x4), and most of these either had a very modest effect compared to the still remaining position error, or improved error modestly at some times during the propagation run but made it worse during others (which to me seemed to somehow suggest it was not addressing really the underlying cause for error).
I doubled propagation time to ~3.5 hours and then noticed the total position error seemed to have 2 components, one always growing at a constant rate and another oscillatory one. So for the constant growing component I wondered if it still would be due to some small error in either Moon gravity model or small frame misalignment. I tried to use different GM value for Moon (so far I was always using the value provided with GRGM1200B), trying also the DE430 and DE421 values. Interestingly, both of these made a modest improvement in propagation error, seemingly reducing the constantly growing error.
So I decided to try a sweep of slightly modified GM values (up to around 50 ppb smaller than GRGM1200B’s Moon GM), and the results showed that it’s possible to reduce the position error greatly in this way, see the below plot:
Then I wondered if reducing GM value just was an overfit to this specific part of the trajectory or really made things improve, so I tried propagation for ~10 hours flight time with the same setup. And for this run I’ve also plotted radial, in-track and cross-track components of position error:
This was quite interesting:
- It seems that indeed using the lower GM value was not just an overfit to that part of the trajectory, since it maintains a similar total position error when going from 3.4 hours to 10 hours propagation
- The continuously increasing error component seems to be in-track, and still seems like there is a bit left (blue line), which maybe could be completely removed by more finely “tuning” the GM value
- The periodic error is cross-track, and the period is just under 2 hours, which seems to match closely with GRAIL-A orbit period. So probably related to SRP?
Of course, I think fine-tuning GM value is not good 
But doing so must somehow be compensating for some error during the setup likely related to Moon’s gravity field. Maybe some frame misalignment, small error in Moon’s position relative to Earth (since this transformation is used to construct the Moon-centered ICRF used during propagation) or some small timescale conversion error?
I wonder if that could not be related to relativity. In Orekit, we work internally in TAI, and we often use UTC for input/output. Both of these time scales are based on the flow of time at Earth surface, which depends on the local gravity. As we go further from Earth, time flow changes (see Relativistic Clock Correction in navipedia). This is the reason the base frequency of the on-board clock in MEO GNSS satellites is very slightly below 10.23MHz so the signal on Earth is based on 10.23MHz. I think this is also the reason we use GM=398600.4415km³/s² for Earth near the body but the value for interplanetary computation in DE files is rather GM=398600.4329km³/s².
I know that for future GNSS constellations around the Moon, there is one specific problem which is to set up a proper Moon time scale. You can see for example GNSS-based Lunar Orbit and Clock Estimation With Stochastic Cloning UD Filter section C.1. We should perhaps add TCL (Lunar Coordinate Time) into Orekit? If so, I guess we could still work in TAI but add a relativistic correction for Moon orbits.
1 Like