[Isocops] Help with orbit compares?

Geoffrey B. Crew gbc at space.mit.edu
Mon Aug 2 10:15:55 EDT 2010


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