GSTAR: an innovative software platform for processing space geodetic data at the observation level

Abstract

To meet the demands for the data combination with multiple space geodetic techniques at the observation level, we developed a new software platform with high extensibility and computation efficiency, named space Geodetic SpatioTemporal data Analysis and Research software (GSTAR). Most of the modules in the GSTAR are coded in C++ with object-oriented programming. The layered modular theory is adopted for the design of the software, and the antenna-based data architecture is proposed for users to construct personalized geodetic application scenarios easily. The initial performance of the GSTAR software is evaluated by processing the Global Navigation Satellite System (GNSS) data collected from 315 globally distributed stations over two and a half years. The accuracy of GNSS-based geodetic products is evaluated by comparing them with those released by International GNSS Service (IGS) Analysis Centers (AC). Taking the products released by European Space Agency (ESA) as reference, the Three-Dimension (3D) Root-Mean-Squares (RMS) of the orbit differences are 2.7/6.7/3.3/7.7/21.0 cm and the STandard Deviations (STD) of the clock differences are 19/48/16/32/25 ps for Global Positioning System (GPS), GLObal NAvigation Satellite System (GLONASS), Galileo navigation satellite system (Galileo), BeiDou Navigation Satellite System (BDS), Medium Earth Orbit (MEO), and BDS Inclined Geo-Synchronous Orbit (IGSO) satellites, respectively. The mean values of the $X$ and $Y$ components of the polar coordinate and the Length of Day (LOD) with respect to the International Earth Rotation and Reference Systems Service (IERS) 14 C04 products are -17.6 microarc-second (µas), 9.2 µas, and 14.0 µs/d. Compared to the IGS daily solution, the RMSs of the site position differences in the north/east/up direction are 1.6/1.5/3.9, 3.8/2.4/7.6, 2.5/2.4/7.9 and 2.7/2.3/7.4 mm for GPS-only, GLONASS-only, Galileo-only, and BDS-only solution, respectively. The RMSs of the differences of the tropospheric Zenith Path Delay (ZPD), the north gradients, and the east gradients are 5.8, 0.9, and 0.9 mm with respect to the IGS products. The $X$ and $Y$ components of the geocenter motion estimated from GPS-only, Galileo-only, and BDS-only observations well agree with IGS products, while the $Z$ component values are much nosier where anomalous harmonics in GNSS draconitic year can be found. The accuracies of the above products calculated by the GSTAR are comparable with those from different IGS ACs. Compared to the precise scientific orbit products, the 3D RMS of the orbit differences for the two Gravity Recovery and Climate Experiment Follow-on (GRACE-FO) satellites is below 1.5 cm by conducting Precise Point Positioning with Ambiguity Resolution (PPP-AR). In addition, a series of rapid data processing algorithms are developed, and the operation speed of the GSTAR software is 5.6 times faster than that of the Positioning and Navigation Data Analyst (PANDA) software for the quad-system precise orbit determination procedure.

Introduction

With the rapid development of space technology in recent years, an integration of multiple space geodetic techniques, such as Global Navigation Satellite System (GNSS), Satellite Laser Ranging (SLR) or Lunar Laser Ranging (LLR), Very Long Baseline Interferometry (VLBI), and Doppler Orbitography and Radiopositioning Integrated by Satellite (DORIS) can provide the observation data with high accuracy, high temporal resolution, and high spatial resolution. They are widely applied in various scientific research fields including meteorology, geophysics, seismology, disaster warning, etc. (National Academies of Sciences, Engineering, & Medicine, 2020).

Each of the above techniques has its unique advantage. For example, the SLR is sensitive to the variations of the center of mass of the Earth (geocenter motion) and scale, while the VLBI is the only space geodetic technique to obtain the nutation offset and the difference of universal time as realized by Earth rotation and the atomic time, namely Universal Time (UT1) and Coordinated Universal Time (UTC), (Nothnagel et al., 2017; Pearlman et al., 2019). The DORIS is often used to compute precise orbits of Low Earth Orbit (LEO) altimeter satellites which are designed to study the global sea-level change (Willis et al., 2010). Due to a considerable increase in the ground stations over the past ten years, the GNSS is of great interest to scientists for providing the overwhelming majority of high-precision observations compared to other three geodetic techniques. Using Global Positioning System (GPS), GLObal NAvigation Satellite System (GLONASS), BeiDou Navigation Satellite System (BDS), and Galileo navigation satellite system (Galileo) data collected from hundreds of global stations, the International GNSS Service (IGS) provides several high-precision geodetic products, e.g., tropospheric Zenith Path Delay (ZPD), Global Ionosphere Map (GIM), geocenter motion and Earth Rotation Parameter (ERP) (Johnston et al., 2017). Besides, the distances between two BDS satellites can be measured by Inter-Satellite Links (ISL) using Ka-band signals (Yang et al., 2020). The use of the ISL measurements can improve the accuracy of satellite orbits and the determined ERP and the geocenter motion (Glaser et al., 2020; Michalak et al., 2021; Xie et al., 2019; Zhao et al., 2022). Hence, the ISL is expected to be a new space geodetic technique which has a great potential in scientific applications. Only is the combination of the above techniques possible to complete a complex geodetic task, e.g., the determination of the International Terrestrial Reference Frame (ITRF) and Earth Orientation Parameter (EOP) (Altamimi et al., 2016). The combination of multiple techniques at the observation level is an important issue and becomes a hot topic in geodesy (Coulot et al., 2007). It requires not only the theoretical methodology, but also a powerful software with flexible architectures to estimate massive number of parameters simultaneously.

A number of software packages were developed over the past decades. With the funding from the National Natural Science Foundational of China, the Positioning and Navigation Data Analyst (PANDA) software was developed at Wuhan University and has become the GNSS data processing software of an IGS Analysis Center (AC) (Guo et al., 2015a; Liu & Ge, 2003; Shi et al., 2008). Over the past two decades, we gained lots of experiences in high precision data processing in the development of the PANDA. With the continuous efforts of many people, the PANDA software now supports SLR, DORIS, ISL, and VLBI data at the observation level (Guo et al., 2015b; Wang et al., 2022; Xie et al., 2020). Other typical software packages which have contributed to the IGS or the realization of the ITRF and EOP products of the International Earth Rotation and Reference Systems Service (IERS) include Bernese (Dach et al., 2015), NAPEOS (Springer et al., 2011), EPOS (Glaser et al., 2017; Uhlemann et al., 2015), GINS (Marty et al., 2011), GAMIT/GLOBK (Herring et al., 2018), GipsyX (Bertiger et al., 2020), C5++ (Hobiger & Otsubo, 2014), etc. The FORTRAN language is widely adopted to develop these software packages at the early age. Although FORTRAN has been modernized in the development of these software packages, it is still difficult for the development and maintenance of a software because users should spend a lot of time to learn the details of each function or algorithm. Besides, the fact that fewer people are familiar with FORTRAN in the future will be detrimental to the advancement of the software. Since the C++ language is widely used and supports object-oriented programming, it is more suitable than FORTRAN for a large geodetic software with complex functions. Therefore, a state-of-the-art processing software which is coded in C++ has been a trend when multiple geodetic techniques are integrated at the observation level. Within the software, the high-performance computing is also needed for obtaining the results with a high temporal and spatial resolution (Barbu et al., 2018). However, a few geodetic software packages (i.e., GipsyX and C5 ++) have been redesigned and coded in C++ , and showed an improvement in both design and computational efficiency (Bertiger et al., 2020; Hobiger et al., 2014). Thus, it is urgent for China to develop homemade geodetic software with object-oriented design and modularized architecture coded in a C++ language.

With the experiences in the algorithm development of the PANDA software over the past two decades, we designed and implemented a new software framework for space Geodetic SpatioTemporal data Analysis and Research (GSTAR). The GSTAR software is coded in C++ with object-oriented programming. In order to improve the maintainability and extensibility, the layered modular theory is adopted to develop the GSTAR software. The data architecture of the software is designed to simulate the real-world scenario of geodetic applications where all models and algorithms are implemented by different modules. High performance computing methods are also used in the GSTAR software to improve computation efficiency. This paper first presents the details of design and implementation of the GSTAR software. Then, the performance of the GSTAR software in GNSS and LEO data processing is presented by comparing with the IGS products released by different ACs and LEO scientific products, respectively. Meanwhile, the improvement of the data processing efficiency with GSTAR with respect to the PANDA software is also analyzed. Finally, major conclusions and plans of the software development are drawn.

Design and implementation of the GSTAR software

Overview

The GSTAR software is developed for processing the observations with multiple space geodetic techniques with high temporal and spatial resolution. Most modules of the software are written in C++ (version 11) while a small portion is written in ANSI C language. At present, there are more than 100,000 lines of C/C++ code. All modules are developed under the same coding rules to minimize code redundancy. The GSTAR software can be run on both Windows and Linux operating systems, which is applicable for various types of users.

For improving expandability and making the software easy for secondary development, all modules are elaborately designed and implemented using the object-oriented method which obeys the rule of high cohesion and low coupling. It allows users to develop their own application programs without knowing mathematical details. This is very important for a large scientific software package because it is impractical for users to have a good knowledge of the entire software. Therefore, it is not only convenient for expert users to develop their own modules to expand the capacity of the software, but also friendly for beginners to learn data processing skills quickly and easily.

The key features of the GSTAR software include the following:

• Satellite precise orbit and clock determination, which includes quad-system GNSS satellites (GPS, GLONASS, Galileo, BDS) and numerous LEO satellites.

• Precise positioning for both network and Precise Point Positioning (PPP) solutions in either static or kinematic mode.

• Precise estimation of geodetic parameters, which includes ERP, geocenter motion, troposphere delay, and ionosphere delay.

• Supporting both ionosphere-free combination and uncombined approach in the multi-frequency context using all available GNSS observation types.

• Supporting a combination of GNSS, ISL, and SLR techniques at the observation level, while DORIS and VLBI techniques are under development.

• Supporting ambiguity resolution using either double-difference or PPP with Ambiguity Resolution (PPP-AR) approach.

• Supporting parallel computing to improve data processing efficiency.

Software framework

The layered modular theory is adopted to develop the GSTAR software. The software is divided into 16 main modules which are distributed in five layers. The overall structure framework of the software is shown in Fig. 1. In the figure, modules in one layer are dependent on those in lower layers. The advantage of this structure framework is to realize the software in a modular form. Developers will find it convenient to realize their personalized applications quickly by using a few interfaces without studying the details of numerous functions and algorithms which are encapsulated in different modules. Each module is compiled individually and forms an independent library, while there is only one applicable program named gstar for Linux or gstar.exe for Windows. Therefore, it is convenient for users to start the processing procedure by typing only one command “./gstar./gstar_filelist” in which gstar_filelist is a formatted text file recording paths of all configuration files and information files.

Fig. 1

The structure framework of the GSTAR software

Base layer

The base layer includes four modules, i.e., configure library (Config), basic function library (Utility), basic mathematics library (BaseFunc), and spatiotemporal datum library (Datum). The “Config” library reads user’s commands from formatted configuration files. The “Utility” library defines some basic operations such as string manipulation and data type conversion. The “BaseFunc” library includes common numerical calculations, e.g., vector operation, matrix manipulation, interpolation, fitting, statistical analysis, etc. The “Datum” library allows the transformation between different coordinate systems and between different time systems, where the Standards of Fundamental Astronomy (SOFA) library released by the International Astronomical Union (IAU) is used for the transformation between the international terrestrial reference system and geocentric celestial reference system (Petit & Luzum, 2010).

Data layer

The data layer accomplishes the definition of observations, products or information as well as corresponding operations such as reading or writing data. The data layer includes two modules, i.e., observation and product data operation library (IO) and information file operation library (Table). The “IO” library supports all available observation and product file formats (Dach et al., 2015). The “Table” library is used to obtain extra information such as satellite metadata, planet ephemeris, earth gravitational field data, earth rotation data, antenna data, tide data, etc. The parallel processing techniques are adopted in this layer. It will significantly improve file operation efficiency if many stations are processed.

Model layer

The frequently-used data processing models are implemented in the model layer. This layer consists of seven modules, i.e., satellite orbit model library (Orbit), clock model library (Clock), observations error model library (ErrorCorr), data quality control library (QC), troposphere model library (Trop), ionosphere model library (Iono), and ambiguity resolution library (AmbFix). In each module, the state-of-the-art models and algorithms are implemented consistent with the IERS conventions 2010 (Petit & Luzum, 2010) (see Table 1). Besides, the combination usage of turbo-edit method, robust estimation method, and epoch-differenced single-frequency cycle slip detection method will clean the raw observations before parameter estimation as much as possible.

Table 1 Summary of the data processing models and strategies

Estimator layer

The estimator layer realizes parameter estimation with high efficiency. At present, the estimator layer implements two estimation methods, i.e., the Square Root Information Filtering method (SRIF) for real-time application and the Least SQuare method (LSQ) for post-processing application. The estimator layer has only one library named Engine, where the two estimation methods are included. Since the parameter estimation is generally the most time-consuming, the high-performance matrix operations and intelligent parameter organization algorithms are developed to improve data processing efficiency, which is the key to realize high temporal and spatial resolution for both real-time and post-processing applications.

Scenario layer

The scenario layer provides a flexible framework for users to develop a personalized application program, such as orbit determination, positioning, time transfer, atmosphere monitoring, etc. The GSTAR software has accomplished a full-featured application program by organizing all available models and functions, as described in “Overview” section. The scenario layer consists of two modules, i.e., main function library (Main) and core function library (Core). The “Main” library acts as the bootstrap entry to start processing with the software, while all application functions are implemented in the “Core” library. The processing framework realized in the “Core” library is summarized in Fig. 2 where major procedures and corresponding support libraries are included. The “Core” library also establishes data architecture and defines processing flow of the software, which will be described in the following sections.

Fig. 2

The processing framework of the GSTAR software implemented in the “Core” library

Data architecture

Future satellite is assumed to have a number of sensors of GNSS, SLR, DORIS, ISL, VLBI, etc. (Delva et al., 2023). In this way, a satellite no longer has a single function, but is like an observation platform. To accommodate this trend, an antenna rather than a satellite or a ground station is taken as a core unit in the software. Different with the physical antenna that is only used to send or receive signals, the antenna defined in the GSTAR acts as an independent processing unit which obtains and preprocesses observations before the normal equation is formed. The antenna is designed as a base class with four major interfaces, as shown in Fig. 3. The first interface is used to read observations from files or streaming through the “IO” library. Then, the second interface is designed to preprocess data based on the “QC” library. For example, the detection of cycle slips and outliers is conducted using this interface. Afterwards, the Observation minus Calculation (O-C) measurements are calculated through the third interface using the “ErrorCorr” library, while the fourth interface calculates the partials of parameters. The O-C measurements includes both real and virtual observations. This design has two advantages. One is the easiness for adding new techniques to extend software capability. Developers can subclass the base class to implement above interfaces in terms of different geodetic techniques and focus on the development of the derived antenna object. The other is the convenience for parallel programming. This is because the antennas are fully independent of each other, and all instantiated antennas can operate in parallel to improve the processing efficiency. Therefore, the advantage of high efficiency of the GSTAR is expected to be more obvious in a multi-core supercomputer.

Fig. 3

Definition of major interfaces for an antenna unit

Based on the antenna unit, the logical data models of the software are designed and described in Fig. 4. In the figure, n refers to the number of antennas, p represents number of parameters, and q is the number of O-C measurements. Each antenna supports the operations from only one geodetic technique. Through data processing as shown in Fig. 3, each antenna calculates partials of the parameters to be estimated and corresponding O-C measurements synchronously in parallel. These values are organized in two groups and will be automatically pushed to the “Engine” library to form normal equations. The parameters and O-C measurements are managed intelligently so that users can concentrate on the development of their own algorithms without considering the way to match the SRIF or the LSQ estimator.

Fig. 4

Overview of logical data models based on the antenna unit

To make logical data models like the true world, three kinds of objects are specified: device, data, and event. The device describes the equipment composition of the observation platform where the antenna unit is the major component. It includes ground stations, satellites, mobile phones, aircrafts, etc. The data is generated by the antenna unit and describes the attributes of parameters and O-C measurements. The event depends on the data and is used to promote the process flow procedure (see details in “Process flow” section). For better management of these objects, three corresponding repositories are established, namely device repository, data repository and event repository. In this way, all data collected with multiple geodetic techniques are efficiently organized to obtain a combination solution at the observation level.

Process flow

The “Core” library in the scenario layer implements the data processing flow, as shown in Fig. 5. The event-driven mechanism is applied to realize data processing epoch by epoch. Two types of events are defined in the GSTAR, namely time event and measurement event. The time event is used to map the parameters of the past epoch to those of the current epoch. It includes the description of parameter stochastic model, e.g., random walk model and white noise model. The measurement event is used to map the parameters to the observations at the current epoch. It records the partials of parameters and corresponding O-C measurements derived from the antenna processing unit. All events are instantiated and managed by the event repository.

Fig. 5

Process flow diagram of the Core library

Before starting these events, some information should be initialized and prepared, e.g., satellite attribution information, satellite initial orbit, float or fixed ambiguity arc, etc. In the initialization step, the parameters generated by the antenna unit are also prepared together with their a-priori information. For each epoch, all time events are first instantiated and added to the main process. Afterwards, they are run by the estimator so that the parameters of the past epoch are converted to the current epoch, which is called time update procedure. The pre-elimination of invalid parameters (e.g., ambiguities for those satellites which are no longer tracked) is also implemented in this procedure. Then, all measurement events are instantiated and added to the main process after the calculation of partials and corresponding O-C measurements. The measurement events are finally run by the estimator if the parameters need to be estimated at the current epoch, which is called measurement update procedure.

It is noted that an additional back-substitution procedure is needed for a post-processing application at the end of the program. It is used to recover pre-eliminated parameters and calculate post-fit residuals of observations. In addition, it is necessary to improve the precision and reliability of geodetic products by screening of post-fit residuals. This method is widely adopted by most well-known software such as GAMIT, Bernese, PANDA, etc. Taking GNSS data processing as example, the main program gstar generally needs to be run three times. The first time is for screening of raw observations. Due to a combination usage of multiple preprocess algorithms, the majority of cycle slips and outliers are detected in this procedure. The second time is for screening of post-fit residuals. Typically, it will have a good performance because a few remaining small cycle slips and outliers are eliminated. The third time is to obtain an ambiguity-fixed solution to further improve the precision of geodetic products.

Data and processing strategies

To evaluate the performance of the GSTAR software, two and a half years of GNSS data (including GPS, GLONASS, Galileo and BDS) collected from January 1^st of 2020 to June 30^th of 2022 is used to calculate geodetic products, i.e., satellite orbit, ERP, satellite clock, site position, geocenter motion, and ZPD with gradients. 315 IGS global stations are selected for data processing. The distribution of these stations is shown in Fig. 6.

Fig. 6

Global distribution of IGS stations for GNSS data processing. Stations used in different procedure are marked by different symbols and colors

Four steps are proposed to generate the products. The first step is the precise Orbit Determination Procedure (POD), where quad-system satellite precise orbits are calculated together with the ERP daily using the data from 165 globally distributed stations. In this procedure, the data are processed at the sampling interval of 300 s and site positions are tightly constrained to the IGS weekly solutions consistent with the IGb14 frame (Rebischung & Schmid, 2016). The ionosphere-free combination of dual-frequency code and phase measurements are used for parameter estimation while the double-differenced ambiguity resolutions for GPS, Galileo, and BDS are conducted (Ge et al., 2006). The second step is the Precise Clock Estimation (PCE) procedure, where quad-system satellite clocks are calculated at the sampling interval of 30 s using the data from 99 uniformly distributed stations. The calculated satellite orbits and ERP products from the first step are input into this procedure. The third step is the positioning procedure (POS), where the satellite orbits, clocks, and ERP products are introduced to calculate site positions at the sampling interval of 300 s. The 120 stations with quad-system data which are not used in the POD and PCE procedure are selected for site position estimation in static mode. Meanwhile, the ZPDs with horizontal gradients are estimated in another procedure, where about 190 stations in IGS ZPD products are selected for evaluation. The final step is the Geocenter Determination Procedure (GCC), where the geocenter motion is calculated together with satellite orbits and clocks using the data from the same stations in the PCE procedure at the sampling interval of 300 s. In this procedure, the ERPs are fixed to the IERS C04 series (Bizouard et al., 2018), and the No-Net-Translation (NNT) and No-Net-Rotation (NNR) conditions are applied (Zajdel et al., 2019). The different usage of stations in each step are labeled with different shapes and colors in Fig. 6. The details of the models and strategies used for each step are listed in Table 1.

The precision of the products generated by the GSTAR software is compared with those from nine IGS ACs or institutions. Identifications (ID) of these ACs or institutions are denoted as COD, ESA, GFZ, GRG, IAC, JAX, JPL, SHA and WHU, respectively. The full name of these institutions and the corresponding software used are listed in Table 2. For brevity, the products calculated by the GSTAR software are marked as BHU in this paper, which refers to Beihang University.

Table 2 The institution ID, full name, and software used of nine IGS ACs and Beihang University

Performance analysis and result validation

GNSS satellite orbit

The performance of quad-system satellite orbit products from BHU is compared with those from seven IGS Multi-GNSS Experiment (MGEX) ACs, i.e., COD, GFZ, GRG, IAC, JAX, SHA and WHU. The orbit products from ESA are taken as reference for the evaluation of these products due to its best static PPP accuracy among IGS MGEX ACs (Li et al., 2020). The time series of Three-Dimension (3D) Root-Mean-Squares (RMS) of the orbit difference from each institution with respect to ESA’s orbit product are shown in Fig. 7. The corresponding average values of 3D RMS are listed in Table 3. For GPS, GLONASS, and Galileo, the One-Dimension (1D) RMSs whose value exceed 20 cm were treated as outliers and were removed from the statistics. For BDS MEO and IGSO, the 1D outlier thresholds were set as 30 cm and 50 cm, respectively. Note that the symbol ‘-’ in the table illustrates that the satellites of corresponding orbit type are not involved in the products of the corresponding institution.

Fig. 7

Time series of 3D RMS of the orbit differences from different institutions with respect to the orbit products from the ESA

Table 3 Average values of 3D RMS of the orbit differences from different institutions with respect to the ESA’s orbit product (unit: cm)

Figure 7 shows that the accuracy of GNSS orbit from BHU is comparable to that of other institutions overall. Compared with the GLONASS and BDS, the GPS and Galileo results from BHU are more consistent with those from ESA. We can see that the RMSs for GPS, GLONASS and Galileo satellites are stable over time, while the RMS for BDS MEO satellites is gradually decreasing for most ACs. This is due to the increasing number of IGS global stations that support all working BDS-3 satellites over the past three years. Table 3 shows that 3D RMSs from BHU are 2.7, 6.7, 3.3, 7.7, 21.0 cm for GPS, GLONASS, Galileo, BDS MEO and BDS IGSO, respectively. The accuracy of GPS, Galileo and BDS MEO from BHU is close to that from COD, GFZ and WHU, which is better than that from GRG, IAC and SHA. The accuracy of GLONASS from all institutions is comparable.

ERP

Accuracy of the EPR products from BHU and seven IGS MGEX ACs are evaluated by comparing them with the IERS 14 C04 products. For a better comparison, some information of ERP products from these institutions is summarized in Table 4. In the table, the number of stations and satellites is the average value obtained from the ERP product files (IGS ERP format) released by each AC, where ‘-’ denotes that no values are available in the corresponding products. The time series of the differences between ERP products of different institutions and the IERS 14 C04 products are plotted in Fig. 8. The corresponding average values and the STandard Deviations (STD) of the ERP differences are listed in Table 5.

Table 4 Information of ERP products from different institutions. The time range is from Day Of Year (DOY) 001 in 2020 to DOY 182 in 2022

Fig. 8

Time series of ERP differences from different institutions with respect to the IERS 14 C04 products

Table 5 Average values and STDs of ERP differences from different institutions with respect to the IERS 14 C04 products

Figure 8 shows that the time series of the polar motion differences from all ERP products with respect to the IERS 14 C04 product are generally within 150 μas and most LOD differences are better than 100 µs/d. The ERP product of BHU is well consistent with the results of other institutions, and the time series shows good stability. Since the absolute values of the LOD differences from SHA are generally larger than 100 μs/d, they are not shown in Fig. 8 and Table 5. To be specific, the STDs of $X$ and $Y$ components of polar motion ($X_{P}$ and $Y_{P}$) and the LOD from BHU are 57.2 μas, 48.2 μas, and 20.8 µs/d, respectively, which are comparable to those from other institutions. The average values of $X$ and $Y$ components of polar motion and the LOD from BHU are -17.6 µas, 9.2 µas, and 14.0 µs/d. Nevertheless, the average values of the ERP from each institution vary significantly. This could be attributed to the different ground station network distribution and different number of satellites used (Zajdel et al., 2020). Another important factor is that different prior constraint conditions are introduced in the processing procedure from each institution. This factor might affect the average value of the ERP estimates. Note that there exists an obvious bias in the LOD results of each institution. The existing literature suggests that this phenomenon might be related to the mismodeled SRP perturbation and the resonance between the periods of earth rotation and orbital motion (Meindl, 2011; Zajdel et al., 2020).

GNSS satellite clock

Consistent with the satellite orbits, the ESA clock products are used as the reference values for the evaluation of the quad-system satellite clock products from BHU and seven IGS MGEX ACs. The STD time series of the clock differences averaged over all satellites of each constellation are shown in Fig. 9. The datum offset and orbit differences are subtracted from the clock differences. The outliers in each daily difference series are detected and deleted for each satellite, which are defined as three times larger than the RMS. The corresponding mean values of the STD time series for each constellation from different institutions are shown in Table 6.

Fig. 9

Time series of STDs of clock differences with respect to the ESA products for different institutions

Table 6 Mean values of STDs of satellite clock differences with respect to the ESA products for different institutions (unit: ps)

For BDS MEO satellites, the STD of clock differences are 32 ps for BHU, which is slightly larger than the smallest STD of 28 ps for COD. The clock estimates from most of the involved institutions are generally at the comparable level with the average STD ranging from 28 to 53 ps. As to BDS IGSO satellites, the STD of clock differences stay at the level of 25–39 ps, which is slightly better than the results of BDS MEO satellites for all institutions. The reason for the better accuracy of IGSO satellites might be more stations simultaneously tracking IGSO satellites in a region. Concerning other GNSS satellites, the STDs of the clock differences between BHU and ESA is 19 ps, 16 ps, and 48 ps for GPS, Galileo, and GLONASS, respectively. The statistical results show that the satellite clock corrections of GPS and Galileo have superior quality among the four constellations, whose STDs roughly stay at the level of 10 ~ 30 ps. The COD archives the best performance for both GPS and Galileo. It is observed that the GLONASS clocks are of the worst quality with the STD of 48 ~ 87 ps. Compared with other ACs, STDs of BHU have a better consistency with those of ESA for GLONASS satellites, which may result from more stringent data quality control.

Site position

120 stations which are not used for the POD and PCE procedure are selected to estimate the daily site positions (see the right panel of Fig. 6). For comparison purpose, the daily solutions of GPS-only, GLONASS-only, Galileo-only, and BDS-only are obtained using one month data in June 2022. The accuracy of the site positions is evaluated by comparing them with the IGS daily solution. The RMSs of the position differences between the estimated and IGS solutions in north, east and up directions for each station are shown in Fig. 10, and the average values of RMSs for all stations are listed in Table 7. The outliers in each daily coordinates are detected and deleted which are defined as three times larger than the RMS.

Fig. 10

RMSs of the position differences for each station with respect to the IGS daily solution over a month

Table 7 Average values of RMSs of position differences for all stations with respect to the IGS daily solution over a month (unit: mm)

Figure 10 shows that the RMSs of the GPS-only results are very stable for different stations. The RMSs in the north and east directions of most stations are below 3 mm, while in the up direction generally less than 6 mm. For Galileo and BDS, the RMSs in the north and east directions are generally below 5 mm, which are much more stable than that of the up direction. Since the ambiguity is not fixed for GLONASS, its solution is less accurate than the other three systems in the horizontal direction. Table 7 shows that the RMSs in the north/east/up directions for all stations are 1.6/1.5/3.9, 3.8/2.4/7.6, 2.5/2.4/7.9 and 2.7/2.3/7.4 mm for GPS-only, GLONASS-only, Galileo-only, and BDS-only, respectively. Apart from the precision differences of satellite orbits and clocks, the scale offset caused by the inconsistency of satellite PCOs between different systems in igs14_2194.atx is an important factor that affects the up component of the site position. In addition, the deviation of coordinates between different systems could be another factor, and is expected to be caused by the station-specific intersystem bias (Dach et al., 2021).

ZPD and horizontal gradients

The accuracy of ZPD products derived from BHU, COD, and JPL is evaluated by taking the IGS products as the reference (Byun & Bar-Sever, 2009). Only GPS data is processed for the estimation of the ZPDs and the horizontal gradients because it is the only system that is used in the COD and JPL products. The data at 190 common stations used in the COD, JPL, and IGS products are used for this evaluation. The RMSs of the differences in ZPDs as well as the east and north components of gradients with respect to the IGS products for each station are shown in Fig. 11, and the corresponding mean values of the RMSs are listed in Table 8.

Fig. 11

The RMS of the differences of the ZPDs, the north gradients, and the east gradients with respect to IGS products for each station

Table 8 Average values of the RMSs of the ZPDs, the north gradients, and the east gradients with respect to IGS products for all stations (unit: mm)

Figure 11 shows that the RMSs of the ZPDs for most stations are lower than 6 mm. This accuracy is consistent with that from previous studies (Byun & Bar-Sever, 2009). It can be observed that the ZPDs and the horizontal gradients generally exhibit a consistent accuracy among different products for most stations. An in-depth analysis shows that ZPD products from BHU have a comparable accuracy with JPL ZPDs and have slightly better accuracy than the ZPDs from COD. While for the horizontal gradients, the accuracy of our products is similar to those from COD but slightly worse than those from JPL. To be specific, the mean values of the RMS of the ZPDs, the north gradients, and the east gradients are 5.8/0.9/0.9 mm, while those for COD and JPL are 6.2/0.9/0.9 mm and 5.6/0.8/0.7 mm, respectively. In general, our ZPD products have similarly accuracy as the products from COD and JPL.

Geocenter motion

The geocenter motion is conventionally defined as the movement of the Center of Mass (CM) of the total Earth system (including the solid Earth and its fluid envelope) with respect to the Center of Figure (CF) of the solid Earth surface (Altamimi et al., 2016). The daily time series of geocenter motion derived from GPS-only, Galileo-only, and BDS-only using the GSTAR software are shown in Fig. 12. For BDS-only solution, only BDS-3 MEO satellites are used. The mean values and STDs of the time series of the geocenter motion for each system are listed in Table 9. For comparison purpose, the results from IGS combined products (Rebischung et al., 2016) are also presented in the figure and table.

Fig. 12

Time series of the geocenter motion derived from GPS-only, Galileo-only, BDS-only, and IGS products, respectively

Table 9 Average values and STDs of geocenter motion time series derived from GPS-only, Galileo-only, BDS-only and IGS products (unit: mm)

Figure 12 shows that the X and Y components of the geocenter motion estimated from different satellite systems well agree with IGS products. However, the $Z$ component of GNSS-derived geocenter motion is much nosier and shows significant sub-seasonal periodical patterns, which mainly result from the GNSS orbit related modeling errors (Meindl et al., 2013). To be specific, the STDs of the $Z$ component time series are 6.6, 11.4, 13.2, and 23.2 mm for IGS, GPS-only, Galileo-only, and BDS-only, respectively. Such a variability of geocenter motion time series stays at a comparable level with respect to the results from Zajdel et al. (2021). In general, the GPS-derived geocenter motion shows a better agreement with respect to the IGS products, while those from BDS have the largest variation.

Figure 13 presents the amplitude spectra of geocenter motion time series derived from IGS, GPS-only, Galileo-only, and BDS-only, respectively. The anomalous harmonics in GNSS draconitic year (Ray et al., 2008) are clearly visible in the $Z$ component, especially for the geocenter motion time series derived from BDS. This might be caused by the systematic errors of GNSS orbit related models. Apart from the GNSS draconitic harmonics, a striking 7 d signal with the amplitude of 2–3 mm is observed in the BDS-derived time series for the X and Y components, while the 9.9 d signal with the amplitude of 1.5 mm can be found in the Galileo-derived time series. The 9.9 d signal in Galileo-derived geocenter motion was also reported by Zajdel et al. (2019). Apparently, these two signals are related to the orbit repetition period, which is 13 revolutions in 7 days for BDS MEO satellites and is 17 revolutions in 10 days for Galileo.

Fig. 13

Amplitude spectra of geocenter motion time series derived from GPS-only, Galileo-only, BDS-only, and IGS products, respectively

LEO satellite orbit

In addition to the geodetic products released by the IGS, the performance of GSTAR in processing LEO satellite data is also evaluated in this paper. Two LEO satellites from the Gravity Recovery and Climate Experiment Follow-on (GRACE-FO) mission, namely GRACE-C and GRACE-D, are selected to validate the software performance for LEO satellite POD and the capability of multi-technique combination with the observations from both GPS and SLR techniques. The a priori precision of 5 mm is used for SLR observations while that of 0.3 m and 2 mm are used for GPS code and phase observations, respectively. Thus, the weighting ratio of SLR observations and ionosphere-free combination of GPS phase observations is $\frac{1}{{\left( {0.005} \right)^{2} }}:\frac{1}{{\left( {0.002 \times 3} \right)^{2} }} = 1.4$. An average number of 7 SLR stations is used in this procedure. SLR station coordinates are fixed to ILRSB weekly solutions (https://ilrs.gsfc.nasa.gov/data_and_products/products/index.html#s5). The daily precise orbits of GRACE-C and GRACE-D were estimated from July 1st to September 30th in 2020 using the reduced-dynamic orbit determination method (Švehla & Rothacher, 2003). As supplement to Table 1, the significant differences in the strategies and dynamic models used in LEO POD procedure are list in the Table 10.

Table 10 Strategies and models adopted in the GRACE-FO satellite POD procedure

Four schemes were designed to make a full comparison: (1) float solutions with the phase ambiguities not resolved to integer values; (2) double-difference AR solution (DD-AR) with the space-space baselines between two GRACE-FO satellites; (3) PPP-AR solution for each GRACE-FO satellite where the corresponding phase observation-specific signal bias products released by WHU were employed; (4) GPS + SLR combined solution which is based on the PPP-AR solution but using the additional SLR observations. The daily RMS of orbit differences over the along-track, cross-track, and radial directions with respect to Level-1B precise scientific orbits (Case et al., 2010) for the four schemes is shown in Fig. 14, and the average RMS for all days is listed in Table 11.

Fig. 14

Daily RMS of orbit differences with respect to Level-1B precise scientific orbits

Table 11 Average RMS of orbit differences with respect to Level-1B precise scientific orbits (unit: mm)

Figure 14 shows that the orbit accuracy of the GRACE-C is comparable with that of the GRACE-D. As expected, the DD-AR and PPP-AR solutions for the two satellites obtain a higher orbit accuracy when compared to the float solution. The PPP-AR solution achieves better performance than the DD-AR solution, especially for the along-track direction. As listed in Table 11, the average 3D RMS is less than 1.5 cm for the two satellites when the PPP-AR is conducted. Compared to the GPS observations, the orbit accuracy from the combined GPS + SLR observations are not further improved. One reason is that the number of SLR observations is much smaller than that of GPS observations, which leads to the fact that the GPS observations dominate the solution. Besides, the outlier detection and weighting strategy of SLR observations also affect the combined GPS + SLR results. In practice, the SLR observations are often used to validate GNSS-derived LEO orbits. Nevertheless, it has been reported that the addition of SLR observations is beneficial to the determination of global geodetic parameters (Strugarek et al., 2019).

Computation efficiency

A series of rapid data processing algorithms are designed and implemented for both serial and parallel computing in the GSTAR software. The satellite orbit numerical integration procedure and the parameter estimation procedure are the two most time-consuming parts when the data from a large number of satellites and stations is processed. To solve the above problems, a rapid orbit integration algorithm is developed to improve the efficiency of orbit integration for a large-scale constellation without relying on parallel computing. In this algorithm, an adaptive step-changed Admas integration method and a synchronous integration algorithm are proposed, which improves the computation efficiency by 14 times when compared with the traditional method if quad-system navigation satellites are used (Fan et al., 2017). For the parameter estimation algorithm, the high-performance linear algebra libraries are introduced, e.g., BLAS and LAPACK (Quintana-Ortí et al., 1998), and the LSQ and SRIF algorithms are redesigned to accommodate these algebra libraries. The modified LSQ and SRIF realized synchronous elimination of parameters in a parallel program which can exploit all the CPU power of a multi-core system (Gong et al., 2018). Besides, it is important to reduce replication and read/write operations between the memory and the hard disk because it is very time consuming to ceaselessly move tens of millions of floats simultaneously. Therefore, an intelligent parameter organization algorithm is proposed according to parameter’s life cycle, which reduce the number of memory and disk operations significantly. In addition, a parallel algorithm is developed for reading observation files, which can further improve the operation speed of the software when the data from hundreds of stations are processed simultaneously.

To evaluate the comprehensive performance of the above algorithms, the elapsed time of the entire POD procedure (same as depicted in “Data and processing strategies” section) in one day is counted, as illustrated in Fig. 15. Through various combination of different constellations, six cases are designed to study the effect of data increase on the computation efficiency, namely GPS only (G), combined GPS/BDS-2 (GC2), combined GPS/BDS-3 (GC3), combined GPS/BDS-2/BDS-3 (GC23), combined GPS/BDS-2/BDS-3/Galileo (GC23E) and combined GPS/BDS-2/BDS-3/Galileo/GLONASS (GC23ER). For comparison, the elapsed time of the traditional algorithms adopted by the PANDA software, i.e., step-fixed orbit integration method applied for each satellite separately and elimination of parameters in a serial program with frequently memory and disk operations, is also counted and shown in Fig. 15. All programs run on a computer equipped with a 4 GHz processor and solid-state disk, where our rapid data processing algorithms were tested with eight threads. For a fair comparison, the main programs of both the PANDA and the GSTAR software were run three times to generate the orbit products.

Fig. 15

The elapsed time of daily POD procedure using the GSTAR and the PANDA in different constellation solutions

Figure 15 shows that the elapsed time of the rapid algorithms developed in the GSTAR is about three times shorter than that of the traditional algorithms in the PANDA when only GPS data is processed. Apparently, the elapsed time difference between the rapid and traditional algorithms is significantly increased when all satellites’ data from four constellations is processed simultaneously. To be specific, the quad-system POD procedure takes only 40 min for the rapid algorithms, while the overall elapsed time of traditional algorithms is close to four hours. The elapsed time ratio of the rapid algorithms to the traditional algorithms is 3.1, 3.1, 4.0, 4.5, 5.2 and 5.6 for each case, respectively. This indicates that greater improvement of the computation efficiency can be achieved when the number of satellites is increased. It is noted that 165 stations are used in this test. We found that GSTAR can complete the quad-system POD procedure within half an hour when only 100 stations are used, which greatly shortens the update interval of the current ultra-rapid orbit products.

Conclusion and future work

Data combination of multiple space geodetic techniques at the observation level is an important issue and becomes a hot topic in geodesy. It needs a state-of-the-art geodetic data processing software with flexible architecture and high computation efficiency. However, most of well-known geodetic software packages are still coded in FORTRAN language, which are hard to maintain and inadequate to process huge amount of data at the observation level. Aiming at providing a flexible software framework with high extensibility and computation efficiency, we developed the GSTAR software in C++ with the object-oriented programming, where the layered modular theory is adopted, and the antenna-based data architecture is proposed to construct any geodetic application scenario in the computer.

Using the quad-system GNSS data collected from 315 globally distributed stations, the initial performance of the GSTAR software is evaluated by comparing with the products released by the IGS ACs. The quad-system precise orbit and clock products as well as ERPs are first calculated. The results show that the 3D RMSs of orbit differences are 2.7/6.7/3.3/7.7/21.0 cm and the STDs of clock differences are 19/48/16/32/25 ps for GPS, GLONASS, Galileo, BDS MEO, and BDS IGSO satellites when the ESA products are taken as reference, respectively. The average values of the $X$ and $Y$ components of polar coordinates and the LOD with respect to the IERS C04 products are − 17.6 µas, 9.2 µas, and 14.0 µs/d. By fixing the orbits, clocks, and ERPs to our products, the static coordinates of stations and the ZPDs with horizontal gradients are then estimated. The results showed that the RMSs of the differences in the north/east/up direction compared to the IGS daily solution are 1.6/1.5/3.9, 3.8/2.4/7.6, 2.5/2.4/7.9 and 2.7/2.3/7.4 mm for GPS-only, GLONASS-only, Galileo-only, and BDS-only, respectively. The RMSs of the differences of the ZPDs and the horizontal gradients are 5.8, 0.9, and 0.9 mm compared with the IGS products. Meanwhile, the geocenter motion is calculated in an individual procedure by applying the NNT and NNR conditions. The results show that the $X$ and $Y$ components of the geocenter motion estimated from GPS, Galileo, and BDS well agree with IGS products, while the $Z$ component values are much nosier. Anomalous harmonics in GNSS draconitic year can be found in the $Z$ component, indicating that GNSS orbit related modeling errors are the major factor that affects the $Z$ component of the geocenter motion. Besides, most of the above products are compared with those from different IGS ACs. The results indicate that the products calculated by the GSTAR are comparable with those from the IGS ACs. The performance in LEO satellite orbits is also evaluated. The results show that the 3D accuracy of less than 1.5 cm for two GRACE-FO satellites can be obtained compared to the Level-1B precise scientific orbit products. However, the combination of GPS and SLR observations achieves no further improvement. Finally, the computation efficiency of the GSTAR is evaluated. Under conditions of 165 stations, the elapsed time of the quad-system POD procedure is about 40 min using the rapid data processing algorithms in the GSTAR, whereas the elapsed time of the traditional algorithms adopted by the PANDA software is 5.6 times longer than the GSTAR.

To sum up, the GSTAR software has accomplished the major architecture development at the current stage. Most of the functionality of multi-system and multi-frequency GNSS applications are realized. In addition, the software now supports the combination of GNSS, SLR, and ISL at the observation level, while VLBI and DORIS are still under development. Due to space limited, only performance of GNSS products and LEO satellite orbits is analyzed in this paper, where the accuracy of all GNSS products as suggested by the IGS is detailed except for the ionosphere. In fact, using the initial version of the software, the performance of the ionosphere derived from the uncombined model had been evaluated by a comparison with different IGS global ionospheric map (GIM) products in our previous work (Wang et al., 2019). Besides, for the validation of the uncombined model for GNSS multi-frequency data processing by the GSTAR, we can refer to Fan et al. (2021). As for multi-technique combination in the software, we evaluated the performance of ERP estimates in our previous work using simulated ISL Ka-band observations and BDS L-band observations from ground stations and LEO satellites, and for details refer to Fang et al. (2022).

Since the goal of the GSTAR is to realize a deep integration of GNSS, SLR, ISL, VLBI and DORIS techniques at the observation level with high computation efficiency, the performance of the combination of all geodetic techniques will be the focus in our future work. We will continue the research on the higher computation efficiency by exploring more comprehensive parallel programming algorithms on CPU, or taking full advantages of parallel capability of GPU. To further improve processing efficiency, new algorithms by reducing computation complexity of the data processing need to be developed according to characteristic of each geodetic technique. We also plan to build a website to provide open service for geodesy communities and the user manual of the GSTAR is expected to be finished soon.