> From: Carl Murray [mailto:c.d.murray@qmul.ac.uk]
> Sent: Monday, November 24, 2003 8:52 AM
> To: Mitch Gordon
> Subject: Re: Saturn Satellite Astrometry Archive
>
> Hi Mitch,
>
> I passed the info on the satellites on to Mike Evans and Nick Cooper
> and asked for their feedback as the *real* experts. Below are their
> responses. These were provided to me before Bob Jacobson's email and
> so can be considered independent of his views.
>
> Mike and Nick were happy for me to pass on their emailed comments to
> you.
>
> Best wishes,
>
> Carl.
>
> ======================================================================
> =
>
> Mike Evans:
> ----------
>
> Carl,
> I've had a good look at this and as Mitch suggested I've even
> fitted an orbit to some of the data (the Prometheus observations
> naturally). Two comments I'd make are:
>
> 1. In the label (*.LBL) files e.g. INDEX/INDEX.LBL,
> DATA/EASYDATA/PROMETHEUS.LBL, where the time format of the midpoint
> time of the observation is described e.g.
>
> DESCRIPTION = "The time at the midpoint of the
> observation in yyyy-mm-ddThh:mm:ss.sss format."
>
> it doesn't say whether this is UTC, TDB, TDT etc. Dick's papers, e.g.
> French et al. 2003. Icarus 162, 143-170, make it quite clear that the
> observation midtimes are in UTC.
Done.
> 2. In 100 years time I'm sure finding ephemerides for Saturn, Earth
> and the Sun won't be a problem. I'm not so sure about an ephemeris for
> Hubble though. The one I'm using, hstTo26Feb1999.bsp, is the only one
> I've been able to easily find (from the naif ftp site). Including some
> ephemeris info for Hubble might be useful.
We have included a pair of
SPICE SPK files for the ephemeris of HST covering the period of this data.
> Actually this turns out to be a minor issue. I fitted an orbit to
> the Prometheus data using the centre of the Earth as the observation
> point instead of Hubble and the elements were effectivly the same as
> using Hubble as the observation point. The differences in the derived
> orbital elements are much smaller than the associated errors.
Thanks for providing the
verification of DickÕs initial assessment. Your results have been included in
the DATAINFO.TXT file.
> Apart from these two comments I found the archive well structured and
> the data very easy to use.
>
> As I mentioned I ran Dick's Prometheus data through my code (only the
> 94-99 observations though, my Hubble ephemeris only goes up to 1999)
>
>
> Dick's fit to the 1994-2000 Prometheus observations (Table 5 in the
> 2003
> paper)
>
> a = 139,377.6249 0.0087 km
> n = 587.28747 0.00005 deg/day
> lambdazero = 339.155 0.057 deg
> e = 0.00192 0.00021
> curlypizero = 257 10 deg
> i = zero inclination assumed
>
>
> My fit to the 94-99 Prometheus observations
>
> a = 139,377.53 0.012 km
> n = 587.28751 0.00008 deg/day
> lambdazero = 339.12 0.05 deg
> e = 0.00184 0.00030
> curlypizero = 256 2 deg
> i = 0.03 0.02 deg
>
> for both fits all errors are 3 sigma (because thats what Dick does).
>
> I'm very pleased with the level of agreement. This is the first time
> I've got a successful fit to ground based (O.K. Earth orbit) data and
> not from a spacecraft actually orbiting the relevant gas giant. With
> the ground based data the code is VERY sensitive to the initial value
> chosen for the mean motion, apart from that it works fine. Some
> judicious tweaking of the code seems called for, especially if I'm
> going to combine ground based and spacecraft observations.
>
> Mike
>
> ======================================================================
> =
>
> Nick Cooper:
> -----------
>
> Hi Carl,
>
> The layout looks fine. Very useful background information about the
> instruments. Nothing much to add to Mike's comments about the 'time
> definition' and the origin of the observations for the HST data. You
> might remember we also talked about the origin issue with the HST data
> and I was curious to see whether Mitch had any clarification of this.
> It wasn't clear either from Dick's 2003 paper or from the text files
> he emailed to me whether these were geocentric or HST-centred
> ('hubblecentric'?!) observations. I had raised the issue with Bob when
> I as at JPL and he was treating them as geocentric, basically through
> lack of a suitable HST ephemeris. Interesting to know from Mike's
> results that it doesn't make a significant difference, at least to a
> precessing ellipse fit. I wonder about an integration though. Only one
> way to find out ...
The calculations are
geocentric. A comment to this effect, along with MikeÕs assessment of the
significance has been included in a new DATAINFO.TXT file in the DATA directory.
> Talking of precessing ellipse fits, I thought I'd also have a shot at
> fitting the Prometheus data using my own code. I've assumed the
> observations are geocentric. I get an rms of 22 mas, which seems OK.
> I've also just used the '94 to '99 data, for comparison with Mike. The
> results are as follows, for comparison (epoch is 2449940. JED, 3*sigma
> uncertainties):
>
> Dick Mike Nick
> a (km) 139377.62400.0087 139377.53 0.012 139377.720.01
> e 0.00192 0.00021 0.00184 0.00030 0.0018 0.0003
> i (deg) 0 0.03 0.02 0.02 0.03
> Omega (deg) - - 156 21
> curly (deg) 257 10 256 2 251 9
> lamda (deg) 339.155 0.057 339.12 0.05 339.18 0.05
> n (deg/day) 587.28747 0.00005 587.2875410.00008
> 587.287480.00006
>
> As you can see, the node and apse are poorly defined. We seem to be
> fairly consistent though, generally.
>
> Nick
>
> (Nick sent me another email last Friday)
>
> Carl,
>
> Mitch's database contains 2 formatted lists for each set of
> observations.
>
> One is in the original format supplied by the observer (I obtained the
> same files for Prometheus and Pandora, minus the control characters,
> by email from Dick French a while back). The other list is in what is
> referred to as EASYDATA format.
>
> I've done a comparison fit for Prometheus, firstly using my original
> emailed files from Dick and then using the EASYDATA version. I get
> absolutely identical results. Thought you might want to pass this on
> to Mitch.
Thanks very much for the confirmation.
> Nick