[Isocops] Help with orbit compares?
Nathan Schwadron
nschwadron at mac.com
Mon Aug 2 11:46:05 EDT 2010
Thanks Geoff
That's perfecto.
I think I needed to know some of those details and to be reminded that this was already documented (sorry to be lame!).
Concerning the delegation, yes, I want to do that.
Mark, could you add the details about the spice ephem's from Geoff's previous message?
Cheers
Nathan
On Aug 2, 2010, at 10:15 AM, Geoffrey B. Crew wrote:
> Hi Nathan,
>
> Mark managed to do this in the past, so you may want to delegate
> and play along.
>
> isoc/src/doc/help/HowToAdd.txt
> isoc/src/doc/help/HowToAdd.texi
> https://ibex-web.bu.edu/ibexhome/ops/docpit/isoc-manual.html/HowToAdd.html#HowToAdd
> Sec. 5.4 of the PDF.
>
> provides some readable instructions, the texi source and the html
> it got turned into.
>
> The main thing you need to know is that texinfo is similar to LaTeX
> in that it uses a stripped down set of primitives to channel what TeX
> can do to make it more manageable. The first line of the source includes
> something that changes the escape from \ to @ so it's e.g. @section instead
> of \section, @include not \include, &c.
>
> The second thing is that the source is common across info/pdf/html
> and (being lazy) I used the info @menu .. @end menu construct to
> organize most of the document--every chapter/section/subsection
> division gets a corresponding info node mentioned in a menu.
>
> The final thing is that all all the sources are .texi but these are
> stripped to equivalent .txt files (as described in the HowToAdd) so
> that Roland's original help mechanism still works. (I.e. if you
> create/modify a .texi file, you'll want to make keep the corresponding
> .txt file equivalent to it.)
>
> In this instance, 6.11.1.6 has a simpler simliar example. You'll
> probably want to just add a following section with the meat of this
> email. As with TeX/LaTeX, all the fooling around ends up with
> @smallexample .. @end smallexample or @verbatim .. @end verbatim
> trying to get it to print usefully in all the media.
>
> --
>
> Geoff (gbc at space.mit.edu)
>
> On Sat, Jul 31, 2010 at 02:17:07PM -0400, Nathan Schwadron wrote:
>> 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