Prediction Format Study Group
Minutes
9 April 2003, 10:30 - 12:00
EGS/AGU, Nice, France

Agenda

Early this year, email went out to the laser ranging community and to the current and previous prediction centers announcing the availability of the preliminary prediction format and soliciting comments. So far, 4 groups have responded. The issues raised have resulted in some changes to the proposed format while others were more logistical in nature. A response to the latest review is still being formulated.

At the previous study group meeting last fall, an action item was created to investigate the ability of the new format and sample integrator to produce normalpoints of sufficient accuracy. Werner Gurtner reported on his investigations in which he used Lagrange polynomials of order 6 with the time of interpolation always being in the central interval of the polynomial. Test subjects were LAGEOS, Starlette and Stella. The first conclusion is that interpolating in geocentric space (x, y, z) produces orders of magnitude better results than interpolating in topcentric space (az, el, range). Interpolating the predictions over a pass gave deviations from the reference orbit of about 1 mm for LAGEOS and worse for other satellites. However, breaking the pass into segments the length of a normalpoint and fitting these segments gave much smaller deviations. If this is still, for some reason, inadequate, the order of the interpolation can be increased with little cost. The practical matter of insuring that a satellite can be interpolated in the center of the polynomial for any time during the day can be accomplished by letting the predictions start some time before the start of the day and end some time after the end of day, depending on step size. A copy of the overheads is attached.

The sample code is still a work in progress, although it has progressed far in the last few months. Tests are being conducted using slr, llr, and mars spacecraft predictions. Some of the responses from the community have made it clear that people will not all wish to use the sample code except in cases where they have no interest in or capacity for writing their own code. Therefore, the use of the sample interpolator and other sample code will set a minimum standard for prediction accuracy. To insure proper interpretation of the predictions fields will require very thorough and careful documentation of the algorithms.

There were a number of format changes required as a result of the format reviews and the sample code tests. These will be documented in the next version of the format. Several of the proposed changes were brought to the group to discuss. This included the following:

1. The date of creation of the prediction set (as well as its sequence number) will be included in the header.
   
2. EOP values used in the predictions may optionally be supplied in new records. If included, these should appear more than once a day, perhaps with each prediction record to insure that the applied values are reproduced.
   
3. There had been a suggestion that the record length be fixed, so that the file could be used for random access. It was felt that some upper limit to a record size (beyond the previously-proposed 72 characters) should be defined, but that users who wanted fixed length records could preprocess the files to produce them. No one was concerned about email width requirements limiting the line length.
   
4. The predictions will normally be provided in the body-fixed, true of date frame of reference. However, the format will include the ability to handle inertial vectors in case there becomes a need for them. Likewise, rotational angles for objects orbiting or on the surface of another solar system body can be provided. This would reduce the number of prediction files needed to describe all the reflectors and offset guiding features on the moon.
   
5. There should be some way to specify how reliable the accuracy of prediction field are. It was felt that these should represent peak to peak rather than RMS errors. There was also a feeling that we will really never know how good the accuracy of the predictions are ahead of time, although this would be useful for automated stations.
   
6. Along these same lines, it was proposed that the date of last observation be included in the prediction file header. This was rejected, since the last observation may not be high quality. The accuracy of the last observation should also be taken into account in the predicted accuracy fields.
   
7. The tracking restriction records will be eliminated. Since we cannot guarantee that people will implement this in their software, it would be worse than no restriction information at all. In addition, ADEOS II restrictions were quite complicated and would not lend itself to this format.
   
8. The prediction center identifier will be decreased from 10 to 4 characters and clearly labeled as an ID.
   
9. There was discussion of referring predictions and ranging data to the 4-digit SIC rather than to the COSPAR ID. The reason is that the COSPAR (and NORAD) ID's are not known until after launch, while the SICs are defined prior to launch. The late availability of the COSPAR ID creates a nuisance for the stations and prediction centers that correct the ID's on data taking immediately after a satellite launch. Changing to SIC in the acquired data will be bought up as a proposal to the DF&P W/G. This change could cause some problems for the analysts, however.

The next steps for this study group are to revise the formats, work on sample code, document the algorithms, and start field tests. RGO will create and test slr predictions. MLRS will produce and test llr predictions and RGO's slr predictions. [HTSI may also produce new format predictions for internal use.]

Thanks to Peter Shelus for taking notes.

Submitted,
R. Ricklefs, P. Shelus

Responsible Government Official: Carey Noll
NASA's Privacy Policy and Important Notices

Send us your comments

Last modified date: Friday, November 05, 2004
Author: Randy Ricklefs
Author: Peter Shelus
Maintained by: Carey Noll