[Isocops] Help with orbit compares?
Geoffrey B. Crew
gbc at space.mit.edu
Sat Jul 31 10:36:07 EDT 2010
Hi Mark,
[Long message; you may want to put some of this in the manual somewhere.]
I take it no one from ADS replied. I'll edit some of the command
responses to make this more readable--you should be able to play
along online. First, what do we have on disk:
[gbc at ena ~]$ ls -latr $IBEX_ANC/isoc | tail -30
-rw-r----- 1 gbc isoc 169984 Jun 30 16:21 isoc_ephem_v320.bsp
...
-rw-r----- 1 gbc isoc 160768 Jul 20 16:21 isoc_ephem_v330.bsp
-rw-r----- 1 gbc isoc 44749824 Jul 20 16:21 isoc_ephem_v331.bsp
...
-rw-r----- 1 gbc isoc 45073408 Jul 28 16:21 isoc_ephem_v335.bsp
...
lrwxrwxrwx 1 gbc isoc 19 Jul 20 16:21 IBEX_series_0.bsp -> isoc_ephem_v331.bsp
...
lrwxrwxrwx 1 gbc isoc 19 Jul 28 16:21 IBEX_series_5.bsp -> isoc_ephem_v331.bsp
lrwxrwxrwx 1 gbc isoc 19 Jul 28 16:21 IBEX_series_2.bsp -> isoc_ephem_v335.bsp
0 (331) is the current ephemeris, 5 (331) is an I'm afraid copy of the
link and 2 (335) is what just got built out of the recent pieces.
Let's see:
[gbc at ena admin]$ svn diff -r'{2010-07-20T20:21:00}' \
/home/gbc/IBEX/ops/config/idsup/IBEX_[SEg]*
gives us some context.
The +'s are the new lines (and it all looks pretty reasonable.
The comparison in the email is between OLD (0,1 or 5) and NEW (2)
and from the ganglist:
+331 vlist 329 319 303 286 273 260 247 231 216 194 164 152 131 121 114 073 062 045 031 028 023 022 027 330 241 CAT
+335 vlist 333 319 303 286 273 260 247 231 216 194 164 152 131 121 114 073 062 045 031 028 023 022 027 334 241 CAT
these are the same except for recent definitive (329 v 333)
the new predictive (330 v 334) which triggered the install.
So the edges of these are the most likely source of the problem.
319 range 2010.142.00.03.06 2010.181.13.38.21
+329 range 2010.171.00.03.06 2010.201.08.08.16
+333 range 2010.174.00.03.06 2010.208.12.13.06
+330 range 2010.200.11.42.18 2010.304.09.53.15
+334 range 2010.208.01.37.06 2010.311.21.27.22
As an aside I'll comment that you can see the stitching process
isn't perfect--the switch from 329 to 333 means that days 171..174
will come from will come from 319 rather than the more recent 333.
At the ISOC we have no good way of knowing which piece 319 v 329
actually is more correct, and from our perspective they're both
probably as good.
The wakeup mechanism calls $IBEX_CRON/scripts/ephem_hack.sh drep 2 5
which you can rerun:
[gbc at ena admin]$ cd $IBEX_CRON
[gbc at ena admin]$ ./scripts/ephem_hack.sh drep 2 5
2010-07-01T13:52:37.651
Ephemeris check time [+/- 30d] 2010-07-31T13:52:37.652
2010-08-30T13:52:37.653
Down track (km) 182.299 -1690.98 (fail 150)
In orbit plane (km) 9.18738 48.2615 (pass 10)
Normal to orbit plane (km) 2.1617 -0.321087 (pass 15)
RMS delta time down track (sec) 113.376 -263.932 (pass 120)
Greatest deviation at 2010-AUG-27-05:50:40.823
There is a 4th argument (true|false, defaulting to the latter) which
shows you what spice call is being used to do the comparison:
[gbc at ena admin]$ ./scripts/ephem_hack.sh drep 2 5 true
spkdiff -t stats -n 12000 -k /home/gbc/IBEX/sw/i686-4.1/share/isoc/spice/naif0009.tls -b 2010 Jul 1 14:02:25.042 TDT -e 2010 Aug 30 14:02:25.044 TDT /home/gbc/IBEX/anc/isoc/IBEX_series_2.bsp /home/gbc/IBEX/anc/isoc/IBEX_series_5.bsp | grep [35][a-df])
2010-07-01T14:01:33.855
Ephemeris check time [+/- 30d] 2010-07-31T14:01:33.856
2010-08-30T14:01:33.857
Down track (km) 182.302 -1691.15 (fail 150)
In orbit plane (km) 9.18891 48.2725 (pass 10)
Normal to orbit plane (km) 2.16252 -0.316738 (pass 15)
RMS delta time down track (sec) 113.41 -263.862 (pass 120)
Greatest deviation at 2010-AUG-27-05:52:24.992
The "drep" action here is to run spkdiff and then a (nasty) awk script
that produces this readable thing and do the pass/fail tests. You can
certainly find that piece and break it out and play with it. (This is
quite possibly something to do for the future.)
In any case, the -b and -e options tell spkdiff what interval you care
about. It's output format is somewhat verbose--the grep on the end
pulls out the lines that get massaged. You can skip the grep and match
up the numbers to make more sense of it.
In any case it's the RMS position differences that are being tested here
over today +/- a month:
# from '2010 JUL 01 14:02:25.042 TDB' (331264945.04210 TDB seconds)
# to '2010 AUG 30 14:02:25.042 TDB' (336448945.04265 TDB seconds)
(The email would have used +/- from the time of the email.) The -b
and -e times are in something SPICE can understand doing minor edits
on the dates:
... Jul 1 .. Aug 30 ...
3a) Down track (km): 182.30238465809
... Jul 31 .. Aug 30 ...
3a) Down track (km): 257.77726400853
... Jul 1 .. Jul 31 ...
3a) Down track (km): 4.3266481608146
suggests that they've made a substantial change in where IBEX will
be in their predictions.
+330 range 2010.200.11.42.18 2010.304.09.53.15
+334 range 2010.208.01.37.06 2010.311.21.27.22
The overlap is:
[gbc at ena admin]$ ibex_time -c tdt -O 2010.208.01.37.06
2010 Jul 27 01:37:57.184 TDT
[gbc at ena admin]$ ibex_time -c TDT -O 2010.304.09.53.15
2010 Oct 31 09:54:06.184 TDT
(Spice is a pain when it doesn't have data, so I +/- 8 hours):
[gbc at ena admin]$ spkdiff -t stats -n 12000 -k /home/gbc/IBEX/sw/i686-4.1/share/isoc/spice/naif0009.tls -b 2010 Jul 27 09:37:06.000 TDT -e 2010 Oct 31 01:53:15.000 TDT /home/gbc/IBEX/anc/isoc/isoc_ephem_v330.bsp /home/gbc/IBEX/anc/isoc/isoc_ephem_v334.bsp | grep [35][a-df]
3a) Down track (km): 633.02708420343
3b) In orbit plane (km): 16.577110078223
3c) Normal to orbit plane (km): 6.0453818140684
3d) RMS delta time down track (sec): 405.05285601182
5a) Down track (km): 3443.9532588857
5b) In orbit plane (km): 155.13490394014
5c) Normal to orbit plane (km): -0.3646777197990
5d) Delta time down track (sec): 595.81394271568
5f) Epoch (TDB, calendar format): 2010-OCT-19-05:30:32.890
0.1 Re over the next 3 months! Could be; don't really know.
[gbc at ena admin]$ spkdiff -t stats -n 12000 -k /home/gbc/IBEX/sw/i686-4.1/share/isoc/spice/naif0009.tls -b 2010 Jul 27 09:37:06.000 TDT -e 2010 Jul 31 01:53:15.000 TDT /home/gbc/IBEX/anc/isoc/isoc_ephem_v330.bsp /home/gbc/IBEX/anc/isoc/isoc_ephem_v334.bsp | grep [35][a-df]
3a) Down track (km): 6.2172058136474
3b) In orbit plane (km): 9.1232106907818
3c) Normal to orbit plane (km): 2.5267329825424
3d) RMS delta time down track (sec): 7.8660134802387
5a) Down track (km): 20.510814153923
5b) In orbit plane (km): 0.2749101352650
5c) Normal to orbit plane (km): -0.1592302286699
5d) Delta time down track (sec): 4.7494209256179
5f) Epoch (TDB, calendar format): 2010-JUL-27-09:37:05.999
6 km over the past 4 days as a prediction. Yeah, I believe that.
The "diff" option of ephem_hack.sh gives you perhaps an easier way
to do this, if you believe that the files were stitched together
correctly. (I do at this point.):
# Absolute differences in state vectors:
#
# maximum average
#
[gbc at ena admin]$ ./scripts/ephem_hack.sh diff 2 5 -10d -7d | grep km
Position (km): 2.9574643645647E+00 1.4874939558524E+00
Velocity (km/s): 1.6492204050560E-05 1.0465938957459E-05
[gbc at ena admin]$ ./scripts/ephem_hack.sh diff 2 5 +7d +10d | grep km
Position (km): 1.4579669393920E+02 7.4287783078483E+01
Velocity (km/s): 1.1661556635578E-03 5.2931040300851E-04
I.e. the two ephemerides agree about where we were a week ago.
The have us diverging by about the length of Massachusetts next week.
I'd try once more to get some assessment from the ADS folks about their
projection. If they can confirm that yeah, IBEX is taking a left turn
then you're safe to install. If they remain silent, I suppose you can
install anyway....
The install commands are buried in scripts/ephem_wakeup.sh following
the "passpasspasspass" result:
$IBEX_CRON/scripts/ephem_hack.sh copy 2 1 &&
$IBEX_CRON/scripts/ephem_hack.sh copy 2 0
$IBEX_CRON/scripts/ephem_hack.sh haso &&
$IBEX_CRON/scripts/ephem_hack.sh hcmp
--
Geoff (gbc at space.mit.edu)
On Fri, Jul 30, 2010 at 06:39:12PM -0500, Mark Tapley wrote:
> Geoff or whomever,
> here's the suspicious-looking lines from the CRON email:
>
>
> 2010-06-28T20:21:21.108
> Ephemeris check time [+/- 30d] 2010-07-28T20:21:21.109
> 2010-08-27T20:21:21.110
> Down track (km) 173.623 -1691.04 (fail 150)
> In orbit plane (km) 8.80683 48.267 (pass 10)
> Normal to orbit plane (km) 1.90472 -0.320469 (pass 15)
> RMS delta time down track (sec) 97.7304 -263.922 (pass 120)
> Greatest deviation at 2010-AUG-27-05:50:55.938
>
> drepresult had failpasspasspass
>
>
> Is there a way we can get better information on
>
> 1) when the maximum difference happened?
>
> 2) Which solutions were being compared when it differed?
>
>
> --
> - Mark 210-379-4635
> -----------------------------------------------------------------------
> Large Asteroids headed toward planets
> inhabited by beings that don't have
> technology adequate to stop them:
>
> Think of it as Evolution in Fast-Forward.
>
> Please restrict discussions on this email list to non-ITAR sensitive topics.
> ______________________________________________
> Isocops mailing list
> Isocops at lists.sr.unh.edu
> http://lists.sr.unh.edu/mailman/listinfo/isocops
More information about the Isocops
mailing list