Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.gao.spb.ru/english/personal/malkin/publ/zm03e.pdf Дата изменения: Mon May 21 17:33:18 2007 Дата индексирования: Tue Oct 2 03:07:11 2012 Кодировка: Поисковые слова: п п п п п п п п п п п п п п п п п п п п п п п п п п п п

Some Problems in the IERS Products from User's Point of View
Zinovy Malkin
Institute of Applied Astronomy RAS, St. Petersburg, Russia

These notes do not pretend IERS which are well known like only to draw attention to day work and that should be IERS products.

indeed to discuss all the problems confronting to the IERS organizers and community. I would several points which we faced during our everysolved for better quality of individual ACs' and

EOP products
· There are two main EOP products provided by two IERS Product Centers on Earth Orientation (Earth Orientation Center (EOC) and Rapid Service/ Prediction Center (RSPC)). Most of scientific users not connecting with (near-)real-time applications use EOC's series, and those who need operational data use RSPC's products (NEOS). It's evident, that these products should be highly consistent. However, this is not always the case. Systematic differences between two series are in some cases rather large, in particular in UT1 and especially in nutation (sometimes more than 100 microarcseconds in bias and/or seasonal terms). These systematic discrepancies between two EOP series can (and really do) yield differences in results obtained by users using different EOP products. In particular, that may affect input series provided by ACs submitting their results for the IERS combination. This does not matter for processing of `24h' VLBI series, but may be substantial for processing of VLBI Intensives and satellite observations, especially SLR ones. Perhaps, solution of this problem is not evident due to various scientific approaches used by EOC and RSPC for generating their products, but it should be found, in my opinion. · A scientific user who wishes to analyze the IERS EOP series is interested in knowledge of more details concerning methods of computation of combined EOP series. However, some of these details are not available. In particular, systematic corrections and weights applied to input series are not always reported. Without that it is sometimes difficult to understand sources of systematic errors of individual series. · For most accurate applications, users may need as accurate nutation model as possible. Such a model includes both determined IAU model and un-predictable components, in the first place FCN. However, the latter is not provided by the IERS. It seems to be important to compute and distribute this data including prediction.

ITRF
· Using ITRF in computation of EOP series produced by various ACs seems to be a necessary condition to provide the consistency between the IERS products. However, it is not always possible for several reasons: - Coordinates of some stations included in the ITRF are computed from relatively short period of observations and degrade with time. - With time, new stations start to operate after ITRF is issued. - Some events occurred at or near site (earthquake, landslip, telescope repair or modification, etc.) may cause change in station reference point position.

207


IERS Technical Note

No. 30

Some Problems in the IERS Products from User's Point of View

Under those circumstances ACs are forced to estimate station coordinates for some stations to provide accurate results. As a result, ACs used different TRF realizations for computation of EOP that leads to systematic disagreement between solutions. To remedy this situation, it is very desirable to establish a procedure for timely update of ITRF. Evidently, there is no need to re-compute whole ITRF solution, but only to tie new stations to the current ITRF realization, introduce jumps, etc. Such a strategy would hopefully provide better consistency between individual solutions and make the IERS EOP products more stable. · It is important to bear in mind that a user maybe actually needs not so much the accuracy of the ITRF catalog itself as the accuracy of coordinates of a given station at a given epoch. From this point of view, to properly use ITRF in practical applications without loss of accuracy one needs also to know in detail geophysical models corresponding to the used ITRF version. Such a model should include, reference temperature and atmospheric pressure for each station, mean pole (to be used in modelling of rotational deformations), atmospheric and ocean loading, tides, etc. Use of improper models can cause errors in station positions at the centimeter level bringing to nothing the original accuracy of ITRF. In turn, ACs providing input solutions to ITRF must use the same models (preferably defined by the IERS Conventions). If it's not the case, it seems crucially important that IERS ITRS Center, compiling the ITRF catalog, applies corresponding corrections to input series to provide maximum consistency and accuracy of the final product. To encourage ACs to provide such an information, it seems to be reasonable to include corresponding blocks in the SINEX standard format. Until a new ITRF realization is issued, it is desirable to perform special investigation to estimate reference temperature and atmospheric pressure for stations, and identify other geophysical models corresponding to the ITRF2000.

IERS Conventions
The astronomical and geophysical models used for data processing become more and more complicated with time as requirements to accuracy growth. Consequently, corresponding software becomes rather complicated. To simplify procedure of testing the software and eliminate number of errors in ACs' results it seems very desirable to provide test examples for all models and algorithms described in the IERS Conventions. Evidently, authors contributed to the IERS Conventions should provide such test data.

Acknowledgments
The author is very grateful to the organizers of the IERS Workshop for financial support of his trip to the meeting. This work is partially supported by the Russian Science Support Foundation.

208