I created a new configuration file and AbstractOrbitDetermination subclass, following the pattern for the Lageo2 test, but modified to use input ephemeris (PV) data.
I find that using the DSSTBatchLSModel against PV data does not seem to work correctly. Specifically,
It converges to a solution without difficulty, but a solution with large residuals. Even if I use only one data point a few seconds after the initial guess from the config file, the residual is unexpectedly large.
The DSSTPropagator is doing something I don’t understand, because with a PVT in the .in file used to initialize the estimated orbit, and a PVT data value a few seconds later, I would expect very small residuals for that data value (a few mm), but the residuals are surpringly large (100s of m and 10s of m/sec). This is true whether or not drag, radiation pression, sun/moon third body forces, etc., are turned on. Residuals are much larger (100s of km) when hours of data are used.
For example, I am providing all data in EME2000 coordinates and UTC (data comes from precision Grace ephemeris. As provided, the Grace ephemeris is in ITRF coordinates and modified GPS seconds - I am pretty sure that all PVT conversions to EME2000 and UTC are done correctly).
More notes:
mu is correct. Switching from central body degree/order 12 to 70 does not significantly change the results.
Using iers.conventions=2010. Switching from WGS-84 to CIO/2010 doesn’t change the results significantly.
Latest test using propagator.min.step = 0.1 propagator.max.step = 100.0 propagator.position.error = 0.0001 but using other step sizes does not siginicantly change the results.
Modifying DSSTBatchLSModel from
parallelizer.propagate(firstDate.shiftedBy(-1.0), lastDate.shiftedBy(+1.0));
to
parallelizer.propagate(firstDate.shiftedBy(-1.0e-3), lastDate.shiftedBy(+1.0e-3));
does not significantly change the results (but why was a shift of 1 sec chosen?? If the propagation region in this code line needs to strictly include the requested time range, shouldn’t the extensions be configurable? What if propagating backwards in time is impossible for some reason?).
Bottom line - something seems wrong with the physics model, but I am unable to determine what. I am aware that because I don’t have perfect knowledge of atmospheric drag, solar radiation forces, vehicle attitude, etc., the orbital predictions cannot be perfect. Nevertheless, I would expect accuracy in the mm range when I am propagating forward only 5 seconds. I am not achieving that. Suggestions please and thanks in advance!