[Isocops] Help with orbit compares?
Nathan Schwadron
nschwadron at mac.com
Sat Jul 31 14:17:07 EDT 2010
Hi Geoff
Thank you. That's good stuff. I would like to be able to add this to the manual. If this is too lengthy a request, then forget it, but I am wondering if you could provide some quick feedback about how to update the manual. I do know LaTeX and can provide add content if I could get an overview of the process.
Cheers
Nathan
On Jul 31, 2010, at 10:36 AM, Geoffrey B. Crew wrote:
> 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
>
> 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