[RADS] TOPEX Side A/B bias ... again
fenoglio at ipg.tu-darmstadt.de
Wed Oct 15 12:21:32 CEST 2008
I am a bit confused.
Following your info, I synchronised RADS again and recomputed the global
I obtain the same results as before.
The data were updated. I wonder if I made a mistake.
Can you please send me the actual curve in comparison with the old one?
Please have a look to my results.The white dots are the result of the new
computation and they are exactly (or almost exactly) over the red (old)
Thanks for your opinion.
On Monday 06 October 2008 17:26, Remko Scharroo wrote:
> Dear RADS users,
> Eric Leuliette and I worked on the TOPEX data again and had to
> conclude that the change made at the end of June was premature. Then
> we decided that there was a 6 mm bias between Side A and Side B. We
> determined this bias by trying to remove a discontinuity between the
> last cycles of Side A operation and the first cycles of Side B
> However, we figured out now that I made an error in the way the SSB is
> applied during the period of degradation of Side A. I first corrected
> SWH, and then recomputed the SSB. However, reports from NASA/WFF show
> that the degradation of Side A not only affects SWH, but also the
> range. And that the effect on the range more or less counterbalances
> the effect on SSB (through SWH). Hence, it is better to base the SSB
> on the original (corrupted) SWH.
> Doing this, the average sea level increases to about 6 mm at the end
> of side A operations, more or less the bias that we computed for side
> B. This means that Side A and Side B were, in fact, unbiased.
> In the current data that were uploaded at the beginning of the
> weekend, the TOPEX degradation is handled as follows.
> - Compute SSB based on the original SWH, also during the period of PTR
> - Afterwards, apply a bias to the SWH as per Queffeulou 
> - Do NOT apply any range bias for Side B
> This effectively raises sea level trend again by about 0.4 mm/year.
> As a result all the reference frame offsets of the other satellites
> needed to be adjusted.
> All of these are minor changes to the data files, so rsyncing should
> go relatively fast.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 9137 bytes
Desc: not available
Url : http://www.deos.tudelft.nl/pipermail/rads/attachments/20081015/12b2fc8f/attachment.gif
More information about the RADS