Message-ID: <35583.58.169.55.239.1161070331.squirrel@puuoo.gsfc.nasa.gov>
Date: Tue, 17 Oct 2006 07:32:11 -0000 (GMT)
Subject: [Fwd: Jason models]
From: "Frank Lemoine" <Frank.Lemoine@gsfc.nasa.gov>
To: ids.analysis.forum@cls.fr
Reply-To: Frank.Lemoine@gsfc.nasa.gov
User-Agent: SquirrelMail/1.4.7-4.fc4
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal


---------------------------- Original Message ----------------------------
Subject: Jason models
From:    "John C. Ries" <ries@csr.utexas.edu>
Date:    Mon, October 16, 2006 10:18 pm
To:      jean-paul.berthias@cnes.fr
         Frank.Lemoine@gsfc.nasa.gov
         Scott.B.Luthcke@nasa.gov
         "Nikita Zelensky" <nzelensky@sgt-inc.com>
         "Dr. Erricos C. Pavlis" <epavlis@umbc.edu>
         Bruce.J.Haines@jpl.nasa.gov
         "Pascal Bonnefond" <Pascal.Bonnefond@obs-azur.fr>
         "Cerri Luca" <Luca.Cerri@EXCHANGE.CST.CNES.FR>
         "Mercier Flavien" <flavien.mercier@cnes.fr>
         "Laurent Soudarin" <Laurent.Soudarin@cls.fr>
         Richard.Biancale@cnes.fr
--------------------------------------------------------------------------

Hi Everyone,

I'm forwarding you all what I presented at the recent GRF2006 meeting
in Munich. It distills much of my results over the last few months. I
note a few important points below. Feel free to forward to anyone you
think would be interested. The PDF has reduced the quality of the
figures, but the original PPT is well over 12 MB and I had problem
sending it out.

TRF

1) It is clear that ITRF2005 needs to be rescaled to be consistent
with the SLR data (Lageos and Jason-1), by around 1 to 1.5 ppb. The
exact re-scaling needs to be revisited since I'm told by Zuheir that
ITRF2005 as published is slightly different from ITRF2005p, which is
what we were looking at. An ITRF whose scale is inconsistent with SLR
would not be my first choice, but it is beyond the point where we can
influence the result and it is a trivial change to make.

We may also need to 'augment' this solution with selected sites (both
SLR and DORIS) where the station is missing from ITRF2005 or still
has some problem. We'll need some activity much like what we did for
DPOD2000 to provide a complete and internally consistent set of
coordinates.

2) I believe the ITRF2005 coordiantes for DORIS should also be
rescaled; there was a measurable improvement when DORIS was scaled
along with SLR. Unfortunately, the GPS frame is likely to be aligned
to ITRF2005 scale, but I don't believe this will be a problem. With
the good GPS distribution, a scale difference in the GPS network
should have no impact on the POD.

3) The rescaling is a little different if Mendes-Pavlis refraction is
adopted for SLR. I recommend using the newer model. LAGEOS clearly
demonstrates an improvement by replacing the refraction model, and it
was very easy to replace. If Marini&Murray is retained, the scaling
increases by another 0.2 ppb. Since this is at the 1-mm level, it is
not particularly critical, but it is what I plan to use. Do we want
to make this a Jason-1 standard?

4) I need to look into whether ITRF2005 needs the scale-rate also
adjusted (it is currently tied to VLBI). It may sound 'heretical',
but I am inclined to trust the VLBI scale-rate simply because of the
longer time span and more stable network configuration, but I will
look for any inconsistencies. I encourage others to look for evidence
of any scale-rate problem with ITRF2005. The estimated scale rate
between ITRF2000 and ITRF2005 is about 0.5 mm/yr in the vertical, but
the uncertainty in this is nearly as big as the rate.

5) Please note the (to me, surprising) sensitivity that the Jason
(and T/P) orbit has to C21/S21. This can cause several-mm-level
correlated errors that look just like miscentering. We have to ensure
we are all handling this right, or at least the same, or we will see
orbit variations that will look like centering variations (but are
not).

I propose

1) We adopt the IERS2003 values for C21/S21 at epoch 2000.0 as well
as the rates. These are consistent with the mean pole and rates
adopted for the pole tide, also in the standards. Because the rates
were not used  for EIGEN-GL04C, this is the only way I see to ensure
consistency with the pole tide model.

2) We need to all adopt the most recent solid-earth and ocean pole
tide models, since these could create seasonal orbit variation that
could look like a seasonal centering variation.

3) The time variable gravity that we adopt should be made to be
consistent with this modeling. If the pole tide was not modeled, or
was incompletely modeled (does everyone have the ocean pole tide
implemented and full iers2003 solid earth tide modeled?), then the
TVG model would have a component that has absorbed the mismodeling.

If this is not handled correctly, we're going to see orbit variations
that give the impression of a miscentering that has nothing to do
with the reference frame.

Open issue:

IERS2003 has no specified rate for C30 and C40. GRACE processing at
GFZ (and now CSR) have adopted rates. These rates were used for
EIGEN-GL04C, the adopted model for Jason, which then implies an epoch
value for the mean values. Do we choose to adopt these rates for
reprocessing? The uncertainties in these rates are small enough
relative to the rates to warrant their adoption, in my opinion, even
if they are not in the IERS2003 standards yet. We may wish to make a
recommendation that they be adopted, since they have become part of
the standard GRACE processing. This is probably not as critical since
I don't believe they can cause the same sorts of issues in the orbit
as C21/S21.

My conclusions:

Other than C21/S21, any of the GRACE models look fine and reduce the
correlated error to the mm-level. Similarly, other than having to
rescale the positions, ITRF2005 seems to perform very well.

JR


                           Cliquez sur l'url suivante 
https://www.mailcontrol.com/sr/Cyb6WCPlhbcYH+EX4Y7YQ3k6wdQPTD5mjhEboBQ!qS26IrIJPtUVPWZzKyldprEnwPNBbAcsGHcbaNLFERUb+5qlxXWk30aSAZuF76buGIqDeku!glhhVwtRQQM2!gRwHAG0MumADUERer!gG+oZvYBDRBZzznKEuR!huesUMuvXndaTjFriYW4hBS!ghOcsIUtJr2yB5avQEjumoRQQiR5o8tYZyLb+  
                    si ce message est indésirable (pourriel).