This e-mail sent to Dr Anthony C. Cook,  Center for Earth and 
Planetary Studies, National Air and Space Museum, Smithsonian
Institution, Washington D.C. 20560-0315. Tel. (USA) 202 633 9748
described the contents of this directory.

BVS/NAIF, June 26, 2002.

--------------------------------------------------------------------------------

Tony --

It turned out that Alex has saved all setups needed for Clem trajectory runs. Yesterday, he re-ran his magic s/w and produced a set of trajectory files, which I then converted to SPK format. The resultant file containing his solution is "clem_ask020625.bsp".

After I got it, I looked for Clem SPKs on our workstations. The search returned only the two files that we had on the naif server all along -- "SPKMERGE_940219_940504_CLEMV001b.bsp"  and "clemdef.bsp".

I moved all three files in one place and I ran a set of SPK comparion/validation tools that I use for MGS. The results left me with mixed feelings. They showed there is an obvious problem with "clemdef.bsp" (NRL solution) that you and I have been using (I'll explain it later), but this problem only affected a few short periods in the file coverage ... and the image we looked at, LUB3982J.064, is NOT inside one of them.

-------------------------------------

I've put everything I looked at together and copied it to naif's anonymous FTP server for you. The files are here:

   ftp://naif.jpl.nasa.gov/pub/naif/CLEMENTINE/misc/tcook


The following files are present in this directory:

SPKs:
=====

   SPKMERGE_940219_940504_CLEMV001b.bsp   -- GSFC solution (from 1994)
   clem_ask020625.bsp                     -- Alex's solution
   clemdef.bsp                            -- NRL solution (from 1994)

I'll refer to these SPKs are GFSC, Alex's and NRL solutions.


SPK segment boundary discontinuities summary files, one for each SPK:
=====================================================================

   SPKMERGE_940219_940504_CLEMV001b.bsp.sbrk
   clem_ask020625.bsp.sbrk
   clemdef.bsp.sbrk

Each of .sbrk file contains a table which lists discontinuities at the boundaries of  overlaping/adjacent SPK segments, each discontinuity is broken down into down-track, radial and out of plane components. While GSFC and Alex's files have very small numbers at all boundaries except 1994-02-21 and 1994-03-26 (when trajectory maneuvers were done), NRL file has HUGE!!! numbers.


Orbit number file:
==================

   clem_spks.orb

THis file is listing orbit numbers and periapsis times. I arbitrarily choose first orbit's pericenter to be on 1994 FEB 19 20:50:46. If you know of official numbering convention for Clem, let me know. Each line in the orbit number table gives the orbit number, periapsis time as UTC and SCLK, and sub-solar and sub-s/c lon, lat and alt in Moon body-fixed frame.


SPK comparison summary files:
=============================

   clem_spks.diff_absav
   clem_spks.diff_av
   clem_spks.diff_max

Each of these files contains a table giving average (.diff_av), average of absolute value (.diff_absav), or maximum (.diff_max) down-track, radial and out-of-plane components of difference for each orbit -- as defined by orbit number file -- between each pair of SPK files.

----------------------------------------------------

Some observations:

-- GFSC and Alex's solutions did not model maneuvers, which resulted in large errors, ~10 km, on 1994-02-21 and 1994-03-26 in both SPKs;

-- Each (!) NRL segment has some bad data at the very end (or the very beginning) which causes HUGE errors, HUNDREDS of km, around these times. Good news is that probably only very short periods are affected by this and there are very few of such periods (about 10)

-- at all other times (almost all the time) all three trajectory solutions agree quite well, to better than 100 meters.

-----------------------------------------------------

I'm not sure where this leaves us. You should certainly try to re-run your processing with GSFC or Alex's file for any images that fall near NRL SPK "bad" periods (clemdef.bsp.sbrk lists these.) But my guess is that most of the images that resulted in offsets wrt to USGS data would not fall in these intervals.

On my side, I'll try to document all SPKs and comparison results. We had it on our PDS-archiving plate for a long time and it's a shame that I have done it earlier.

Let me know if I can help with anything else in regards to this issue.

Sincerely,
Boris