X-Sympa-To: ids.analysis.forum Received: from hector.cls.fr (osis.cls.fr [62.161.32.21]) by hermes.cls.fr (8.9.3/8.9.3) with ESMTP id NAA22346 for ; Fri, 24 Mar 2006 13:00:01 +0100 Received: by hector.cls.fr (Postfix) id 10FC2EEACA; Fri, 24 Mar 2006 11:01:54 +0000 (GMT) Delivered-To: ids.analysis.forum@cls.fr Received: from CLS-SOUDARIN.cls.fr (orange-102.cls.fr [62.161.32.13]) by hector.cls.fr (Postfix) with ESMTP id A2A8BD9994 for ; Fri, 24 Mar 2006 11:01:53 +0000 (GMT) Message-Id: <6.1.1.1.2.20060323112940.021d08f8@pop.cls.fr> X-Sender: lsoudarin@pop.cls.fr X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Thu, 23 Mar 2006 11:29:44 +0100 To: ids.analysis.forum@cls.fr From: jean-michel lemoine -grgs-61332 (au lieu de Laurent Soudarin ) Subject: Re: Fwd: Re: estimating DORIS pole motion rates? 1-week preliminary results Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Validation-by: laurent.soudarin@cls.fr Hello to you all, I react to the mail exchange that was forwarded to me by Laurent. I will try to make it very clear how we compute pole motion with GINS, for IERS CRC as well as for the IDS: We use IERS EOPC04 as "input series" (either the original EOPC04 with a point every 24 h, or a densified EOPC04 with a point every 6 h, obtained by lagrange interpolation from the original EOPC04). During orbit computation, when we need the pole position at a time t, we compute it by interpolation from the nearest values of the "input series" (at 24 or 6 h interval). In order to adjust the pole position in a subsequent step, we compute the partial derivatives of the pole position. This involves a linear sharing of the partial derivatives at time t between the nearest values of the "input series". So, when we compute the pole position as well as when we compute the partial derivatives to adjust it, we always imply that the pole is located on the broken line connecting the points of the "input series". These points, either given every day or at 0, 6, 12 and 18 h, are the summits of this broken line. In other words, we do not take the pole motion as constant over a certain time span, nor as a daily value + drift (line segments without connection between them), but as a continuous, broken line. Since the solution every 6 hours would be too noisy, we provide a solution every 24 h by applying a reasonably weighted constraint which states that the points at 6, 12 and 18 h should align on the straight lines linking the points at 0h. "reasonably weighted" means "sufficient so that the points more or less align on the line, with a tolerance of, say, 10%". The result is equivalent to a daily value + drift, but with the additional condition that the drifts have to be compatible with the point values; which doesn't seem unreasonable... At this stage we can solve for the points every 6 hours, and the result will be very close to a broken line with summits at 0 h, or we can make some points disappear from the normal equation by reducing them, in order to provide a solution every 24 hours. In the first case, if the constraint is correctly weighted, we have exactly the same solution as the one we would have obtained using the EOPC04 with a point every 24 h (at 0h). In the second case, if we keep the points at 0h and reduce the others, we will have again the same solution. If we keep the points at 12h and reduce the others, we are able to provide a solution that is less noisy, because the 12h values are in the middle of the line segments, whereas the 0h values are at the summits. Providing the middle of the segments instead of their summits reduces the short term noise. In response to Zuheir's worries, I would like to stress that this method does not impose linearity contraints at day boundaries and is not either sensitive to the "input series" used. Laurent has just conducted a test, perturbating the EOPC04 series by random quantities, and obtaining consistent results, whatever the "input series" was. He will probably send a mail on this test. Best regards, Jean-Michel > Date: Mon, 20 Feb 2006 15:43:53 +0100 > To: Jean-Michel.Lemoine@cnes.fr > From: Laurent soudarin > Subject: Fwd: Re: estimating DORIS pole motion rates? 1-week preliminary results > Mime-Version: 1.0 > > > >X-Sieve: CMU Sieve 2.2 > >Date: Mon, 20 Feb 2006 15:03:57 +0100 > >From: Zuheir Altamimi > >User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr; rv:1.6) > >Gecko/20040113 > >X-Accept-Language: en, fr > >To: Pascal Willis > >Cc: Laurent Soudarin , > > Frank Lemoine , > > Daniel Gambis , > > Richard Gross , > > Gilles Tavernier , > > Jean-Jacques Valette , > > Jayles Christian , > > Ron Noomen , > > Markus Rothacher > >Subject: Re: estimating DORIS pole motion rates? 1-week preliminary results > >X-Mailcontrol-Inbound: cGPge!eAbNPH17e25XjZH3oDPsTYQRh+Te5TjebCxnQ= > >X-Scanned-By: MailControl A-06-00-03 (www.mailcontrol.com) on 10.68.0.111 > >X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on surcouf.cnes.fr > >X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 bayes=0.0000 > > autolearn=ham version=3.0.4 > > > >Dear Pascal, > > > >Thank you for making these tests that I personally wanted to > >see in order to evaluate DORIS performance in EOP determination. > > From your tests (thought it is over one week), it appears > >clearly that DORIS is just too week to be able to accurately > >estimate polar motion rates (and may be LOD). In my opinion, > >it is up to IDS to decide on the appropriate strategy to be > >adopted. Note that for similar reasons, ILRS decided not > >to estimate polar motion rates, but ILRS ACs do estimate > >LOD. It would be worth then to test if estimating LOD > >would change your results or not. > > > >On the other hand, I think it is worth testing over a longer > >time span to have more convincing conclusion as you said. > > From the ITRF2005 pre-analysis, using LCA new submission > >where polar motion rates and LOD are not estimated, I got > >similar RMS as yours wrt IGS EOP series. But Laurent imposed > >some linearity constraints at sub-day and day boundaries, and > >he should absolutely test and demonstrate that these > >linearity constraints do not somehow force EOPs to the a > >priori values. > >In any case FIXING polar motion rates to external values should > >be prohibited and I don't think that you or Laurent fix polar > >motion rates. > > > >Best regards > >Zuheir > > > > > >Pascal Willis wrote : > > > >>dear Laurent and Frank, > >>here is a discussion that Frank could initiate at the next IDS meeting in > >>Venice. > >>Just to start the discussion, I recomputed the most recent week of DORIS > >>data (Jan 1 to Jan 7, 2006) in 2 different ways: > >>A) usual IGN/JPL: estimating daily pole motion + daily polar motion rate > >>+ daily UTC-UT1 rate > >>B) usual LEGOS/CLS: estimating daily pole motion > >>First, I don't see any change in the station coordinates results for both > >>cases. To test for any improvement, I compute RMS of comparison for all > >>stations with IGN04D02 solution (long-term solution) after a 7-parameter > >>transformation. > >> N(mm) E(mm) V(mm) > >>case A 18.5 21.5 12.7 > >>case B 18.4 21.1 13.0 > >>However, I see some significant improvement in the polar motion itself. > >>To test for improvement, I do daily difference of polar motion at 12:00 > >>with JPL/GPS and compute a RMS of the 7 values without removing any bias. > >>I use Bulletin B as a priori in my DORIS computations: > >> XP(mas) YP(mas) sqrt((XP**2)+(YP**2)) > >>case A 1.01 0.40 1.09 > >>case B 0.68 0.54 0.87 > >>it also removes the asymmetry I usually see between XP and YP and that > >>Laurent does not see at all in his results. It could be related to the > >>estimation of the daily polar motion rates that are not totally > >>observable with DORIS. > >>So, if we want to go from typically 1 mas polar motion results for DORIS > >>to 0.5 mas that may be an easy way to go. The other possibility is also > >>to add more smoothing to our daily results (imposing continuity or > >>linearity at day boundary). > >>Is any of these choices useful and desirable? > >>I am ready to stop estimating polar motion rate for DORIS, but I would > >>like to be 100% sure that nothing will be lost for IERS EOP, IERS CPP, > >>future ITRF, IDS combination,... I would also like to be sure that all > >>IDS groups will follow the same rules. > >>Do you think I should do some additional tests on a longer time span to > >>get a more reliable and convincing conclusion? Then it could make sense > >>to enlarge the distribution list to the IDS Analysis Forum and ask for > >>feed-back. > >>What is your opinion? > >>Thanks in advance > >>Pascal > > > >-- > > > >---------------------------------------------------------------------- > >Zuheir Altamimi Email : altamimi@ensg.ign.fr > >Institut Geographique National Phone : 33 1 64 15 32 55 > >ENSG/LAREG FAX : 33 1 64 15 32 53 > >6-8 Avenue Blaise Pascal > >77455 Champs-sur-Marne, FRANCE > >---------------------------------------------------------------------- > > >