dataesr/scientific-paragraphs-categorization huggingface dataset:
We chose, therefore, to write the main computational parts of the new software set in C++. We wanted to avoid the hodgepodge of scripting languages used in GIPSY and chose Python3, which has a large user base and community support in the sciences and engineering, as the sole scripting language. For small problems and identical use cases (for instance precise point positioning with GPS or low Earth orbit determination with GPS) which are implemented in GIPSY and GipsyX/RTG, run times are nearly identical. Larger problems, that can be handled by GIPSY and GipsyX/RTGx can be faster with the new software, due to optimization and use of parallel computation. Table  1 , shows almost a factor of three increase in performance for a moderate size problem, the problem is too small for realizing large increases in speed with multiple cores/CPUs.
CPU Time(minutes) GIPSY 45 GipsyX/RTGx 1-core 16 GipsyX/RTGx 2-core 11 Among the key new capabilities of GipsyX/RTGx are: • Table  2  shows the size of the entire GipsyX/RTGx distribution in terms of the number of lines of code. Raw lines are just the total number of lines in all the source files. Physical lines are lines that are not comments or blank. The majority of the C++ code occurs in the single executable module, "rtgx", which models the GNSS data and other tracking data types, and estimates parameters such as station and satellite position. We describe the structure of "rtgx" below. There are approximately 140 individual executable programs in GipsyX/RTGx. Included are many small utilities, such as time format manipulation, time series and data manipulation, trend analysis, data archive access and plotting utilities.
Most users will only use a small set of these. In addition to the tracking data analysis tools, there is a set of Python3 executables dedicated to time series analysis of positions on the Earth and reference frame determination as well as many other small utility tools (for example, to convert between file formats or timing formats). We have attempted to apply in this development the many lessons learned from the previous iterations of GIPSY and RTG. GIPSY was written by many people under a fairly loose set of coding rules. The main computational pieces of GIPSY were divided into several independent FORTRAN modules (orbit integration, signal/Earth model, filter, smoother. ). There was considerable inconsistency in the input to these pieces, which were mostly FORTRAN namelists. Common information across these FORTRAN executables was not consistently named or configured.
To mitigate the complex configuration of the various GIPSY modules, we wrote a Perl script (gd2p. pl) to hide the complexity and act as the interface for most of our external users who were doing precise point positioning (PPP) or precise orbit determination (POD) of low Earth Orbiters using GPS  [Bertiger et al. , 2010c]. GipsyX/RTGx improves upon GIPSY in two ways here. One, there is a uniform input format, referred to as a 'tree' input defined in detail below, which has a general structure similar to YAML. We did not use YAML because, at the time of our development, it did not have some object-oriented inheritance properties or arbitrary script execution that would allow human readable, compact input for GNSS constellations where many of the satellites have identical properties. Second, instead of writing many individual executable modules as in GIPSY, the object-oriented C++ allowed us to write a single main executable, rtgx.
gde Data Editor GNSS data must be edited for phase breaks and gross outliers before it is processed to fit model parameters. The GNSS Data Editor (gde), is a C++ code that implements two distinct algorithms: turbo-edit  [Blewitt, 1990] , and simple continuity checks of linear combinations of phase data based on lowdegree polynominal fits. Turbo-edit looks at averages of pseudorange -phase measurements to detect jumps in the phase measurements. It is well suited to low rate data, such as the large number of RINEX files typically recorded at a 30-sec rate. When data rates are high, for example sampled every second as often seen in real-time applications, it is possible to detect phase breaks simply by monitoring the change in time of differences in phase observations on two frequencies. Such a difference cancels out receiver and transmitter clock jumps.
Every set of products contain files with consistent orbital state estimates, transmitter clock estimates, spacecraft attitude information, Earth rotation parameter (ERP) estimates, and widelane phase biases information. In addition, the no-net-rotation and fiducial-free solutions are associated with coordinate transformation files referred to as x-files. These x-files contain the set of 7 Helmert parameters (3 small rotations, 3 translations, and 1 scale parameter) needed to transform from the frame of the day to the ITRF. The format of these different products is detailed in the GipsyX software documentation. Following extensive testing and validation, the JPL GNSS analysis center transitioned seamlessly from products generated using the GIPSY software package to products created using GipsyX on January 29, 2017.
Our four-constellation products contain an average of 102 satellites per day, approximately comprised of 31 GPS, 28 Beidou, 22 Galileo and 21 GLONASS. While this dataset is limited, it gives a preliminary indication of the sort of performance that might be expected from multi-GNSS products processed with GipsyX/RTGx, which should also improve with time as models and procedures are further enhanced. GLONASS). GPS (JPL Rapid), provided for comparison, is computed using JPL's standard GPS-only Rapid products described in section 6. 1. 1. Units for all precision metrics are centimeters. All statistics were computed from Aug. 1 to Aug. 31, 2019. Each clock metric is the median value of the daily root-mean-square values of the overlaps/differences across the GNSS satellites after removing a linear trend from the entire GPS constellation to account for reference clock differences, a subsequent linear trend from each of Galileo and BeiDou to account for constellation bias reference differences, and a linear trend from each GLONASS satellite due to the presence of range biases - * likely making the GLONASS clock overlaps spuriously small.
6. 0 mm). We attribute the difference in vertical to station selection differences (i. e. 59 IGS14 stations vs. 106 IGS08), as vertical repeatability is highly site-dependent. While using IONEX files does not improve repeatability in this analysis, we still recommend its use to be consistent with the models used in the Final POD process, and because other analyses show that omitting it can introduce an offset in the z-component  [Ries et al. , 2018]. In this test, the offset is an average of 0. 4 mm. The ENV frame repeatability of about 2, 2, and 6 mm in Table  5  is significantly better than the 24-hr RMS repeatability of 3, 6, and 9 mm shown in  [Soycan, 2011]  using Bernese 5. 0 software. We note that significant improvements are seen in the east component with bias fixing  [Bertiger et al.
Instead of adjusting the zenith delay and tropospheric gradient parameters, only a more constrained zenith delay is adjusted to help break the correlation with the random walk vertical position. Some kinematic applications may have better information about the tropospheric delay. For instance, high flying aircraft typically have a small wet delay and the dry zenith delay may be computed using a pressure sensor. To demonstrate the expected performance of kinematic positioning with better known troposphere, we repeated the experiment from Table  6 , but fixed the zenith delay and the gradient parameters to the values from static 24-hour position solutions. Comparing Table  6  with Table  7 , one can see a significant and larger improvement in the vertical. [Bertiger et al. , 1994]. As a superset of these two software, GipsyX/RTGx supports precise postprocessing, reduced-dynamic orbit determination, as well as embedded real-time POD.
For post-processed LEO POD using GPS data, the GipsyX/RTGx provides identical capability to GIPSY, but with a simpler user interface along with additional capability for the newer GNSS constellations, DORIS, and SLR. Tests were performed with GRACE  [Tapley et al. , 2004a] , the followon GRACE mission (GRACE-FO), and Jason-2  [Lambin et al. , 2010; Bertiger et al. , 2010b; Cerri et al. , 2010]. Since the GPS determined orbits for Jason-2 are sub-centimeter accurate  [Bertiger et al. , 2010b] , we can use those orbits to measure our accuracy for Jason-2 orbits determined with other data types. Mixing GNSS, SLR, and DORIS data is also possible in GipsyX/RTGx, but has not had extensive testing yet. In the subsections below, we detail the expected accuracy and software capabilities for LEO POD using GPS, SLR, and DORIS data.
GPS -GRACE, GRACE-FO POD and time synchronization GipsyX/RTGx is the operational software used for GRACE-FO to determine the orbit and clock of the GRACE-FO spacecraft. GRACE and GRACE-FO are among the best low Earth orbiting satellites to test POD with GPS since they have a measurement of the inter-satellite range (up to a bias) that is good to the micron-level. This is the dual-one way range measurement made at K and Ka band, K-Band Range (KBR)  [Dunn et al. , 2003; Thomas, 1999]. It is the KBR's precision along with an accelerometer measuring the non-gravitational forces that allows the precise recovery of the Earth's time varying gravity field. Although GipsyX/RTGx, can process KBR range data and use accelerometer data, neither is used in the operational POD for GRACE or GRACE-FO discussed here.
This study demonstrates the long-term stability of salinity measurements from Argo floats equipped with inductive conductivity cells, which have extended float lifetimes as compared to electrode-type cells. New Argo float sensor payloads must meet the demands of the Argo governance committees before they are implemented globally. Currently, the use of CTDs with inductive cells designed and manufactured by RBR, Ltd. , has been approved as a Global Argo Pilot. One requirement for new sensors is to demonstrate stable measurements over the lifetime of a float. To demonstrate this, data from four Argo floats in the western Pacific Ocean equipped with the RBRargo CTD sensor package are analyzed using the same Owens-Wong-Cabanes (OWC) method and reference datasets as the Argo delayed-mode quality control (DMQC) operators.
When run with default settings against the standard DMQC Argo and CTD databases, the OWC analysis reveals no drift in any of the four RBRargo datasets and, in one case, an offset exceeding the Argo target salinity limits. Being a statistical tool, the OWC method cannot strictly determine whether deviations in salinity measurements with respect to a reference hydrographic product (e. g. , climatologies) are caused by oceanographic variability or sensor problems. So, this study furthermore investigates anomalous salinity measurements observed when compared with a reference product and demonstrates that anomalous values tend to occur in regions with a high degree of variability and can be better explained by imperfect reference data rather than sensor drift. This study concludes that the RBR inductive cell is a viable option for salinity measurements as part of the Argo program.
For Argo data, quality control includes two steps: First, real-time quality control (RTQC) procedures are applied to the data collected by the floats, focusing on the detection and elimination of outliers  (Schmid et al. 2007; Udaya Bhaskar et al. 2013; Wedd et al. 2015; Wong et al. 2020). These data are generally made freely available in near-real time (NRT), that is, within 24 h. Second, a delayed-mode quality controlled (DMQC) analysis is conducted to produce high quality datasets suitable for oceanographic research. Delayed-mode (DM) analysis relies on Argo data experts to examine the data and apply corrections when necessary. DM products are available to users 6-12 months after collection. Temperature and pressure are generally measured within the required accuracies throughout the life of a float  (Abraham et al.
For example, a firmware fault in the data bin averaging algorithm resulted in a pressure bias that could not be corrected in postprocessing  (Barker et al. 2011). As a result of the problems plaguing the FSI CTD, and perhaps a lack of interest from competing manufacturers, an overwhelming majority of CTD instruments installed on Argo profilers use Sea-Bird's electrode-based CTDs. A series of recent setbacks and technological improvements have motivated the development of a new sensor package for Core Argo floats. The switch to Iridium telemetry, as previously mentioned, has significantly reduced the time a float spends at the surface, thus decreasing the need for biofouling mitigation. Additionally, pumpfree CTDs consume much less power, which directly translates into longer float lifetime.
Also, there has been a call to diversify the sensor packages on Argo floats so that the program is not susceptible to ''single points of failure''  (Roemmich et al. 2019). The goal of this study is to assess the long-term accuracy and stability of salinity measurements collected by four Argo floats equipped with the RBRargo inductive CTD manufactured by RBR, Ltd. (https://rbr-global. com/). All four floats were deployed in the western Pacific Ocean as either experimental or pilot-project Argo floats (Fig. 1 ). For this analysis, we rely on the standard Argo community OWC MATLAB toolbox (https://github. com/ArgoDMQC/matlab_owc) that is used among DMQC operators to determine salinity offset and drift. The OWC method, as well as most statistical methods, is not free from ambiguity and subjectivity.
In an attempt to minimize subjectivity, we combine the OWC method with a custom-made MATLAB visualization toolbox designed to help Argo users to select appropriate settings for OWC processing and make defensible conclusions about accuracy and stability of conductivity sensors. The paper is organized as follows: The dataset and methods for data analysis are described in section 2. Section 3 presents the results of the analysis by first looking at the stability characteristics (i. e. , offset and drift) calculated by the OWC method and comparing it to the initial accuracy assessments. These statistics are then compared to salinity drift and offset estimated during DMQC and applied to other floats operating in the same regions. Some methods are suggested to avoid misinterpreting the results of the OWC analysis.
b. Salinity offset and drift detection The OWC analysis is a statistical method developed to detect salinity drift correction and described in  Owens and Wong (2009)  and  Cabanes et al. (2016). In this method, the salinity profiles observed by an Argo float are compared to reference data in the same region by using objective mapping (OM;  Bretherton et al. 1976). In this study, we used separately two reference datasets approved and used by the Argo community and prepared by the Argo Data Management Team (ADMT) at the Coriolis Data Center: 1) shipboard CTD casts (ADMT-CTD) and 2) DMQC-corrected Argo profiles collected during preceding years (ADMT-Argo). Both datasets are available for the members of the Argo program upon request to the Institut Français de Recherche pour l'Exploitation de la Mer (IFREMER).
c. Distinguishing between instrumental errors and oceanographic variability The results of the OWC output strongly depend on the quality of reference data. Anomalies in salinity measured by the float's CTD relative to water mass with different temperature-salinity characteristics can be easily misinterpreted as sensor drift, especially when reference data are sparse or inaccurate. The approach taken in this study relies on visualization tools designed to assist users to determine whether anomalies in measured salinity are caused by instrumental errors or oceanographic variability and, as such, avoid ambiguity in salinity drift detection. These visualizing tools include the following: 1) Plots showing (i) a time series of the ''profile fit coefficients'' (i. e. , the disagreement between the salinity measured by Argo float and reference data calculated by the OWC method averaged over the 10 selected reference potential temperature levels) and (ii) a map showing the magnitude of the fit coefficients along the float trajectory.
Such plots help to identify spatial coherency in discrepancies between the analyzed Argo measurements and the reference dataset, providing information on whether discrepancies should be attributed to errors in the reference data, or to sensor drift. 2) Diagrams comparing the objectively mapped reference salinity field calculated by the OWC method to a different reference data source. For this purpose, the nearest grid points of the Roemmich-Gilson (RG)  (Roemmich and Gilson 2009)  climatology and/or other monthly gridded datasets were used. Discrepancies between different reference sources support the hypothesis that large salinity anomalies might be due to erroneous reference data, rather than to sensor drift. RG climatology was selected because it is also based on the ADMT-Argo reference dataset but uses a different method for data interpolation.
a. Salinity offsets and their dependence on reference data and time separation factors The OWC analysis, when run with the settings specified in the appendix against the two ADMT-CTD and ADMT-Argo reference databases, revealed no statistical trends in any of the four RBRargo float salinities. There were small differences between the salinities measured by the RBRargo and the reference data. When compared with the ADMT-CTD reference database, the salinity offsets were different from the offsets based on the ADMT-Argo reference database (Table  2 ). These differences result from different time periods when the reference data were collected (Fig. 3 ). Most CTD casts were collected during the long (. 30 yr) period starting in the 1980s  (Figs. 3a3, 3b3, 3c3) , while most Argo profiles were collected after 2005 (Figs.
3a4, 3b4, 3c4 ) and cover a comparatively short time period. The resulting disagreement could be associated with temporal salinity variations in the Pacific Ocean documented in previous studies (e. g. ,  Boyer et al. 2005; Durack and Wijffels 2010; Helm et al. 2010). The salinity offset for Argo Australia float 5904925 in the Coral Sea demonstrated significant salinity bias: from 20. 0139 to 20. 0167 when compared with ADMT-CTD and ADMT-Argo reference data (Table  2 ). This offset exceeds the Argo accuracy limits (0. 01) and may result from the fact that this float was equipped with the older RBRargo design (see section 2a and Fig. 2 ). For the other three RBRargo floats equipped with the newer design (two Japan Argo floats in the northwest Pacific and one China Argo float in the Philippine Sea; see Table  1 ), OWC salinity offsets below the Argo accuracy limits were found when compared to the ADMT-CTD dataset with long (10-30 years) time separation factor (Table  2 ).
The dependence of the OWC results on other settings (see the appendix) was small. For all four floats, minimum offsets were found at the spatial separation factors (small/large) of 28/48 of latitude and longitude (Table  3 ). From these results, we chose the ADMT-CTD 2019v01 database as a source of reference data and the time separation factors (small/large) of 10/30 years for all four floats (Table  2 ). The resulting OWC output showed no significant statistical trends for all four floats,  which we interpret to mean that salinity, as measured by the RBRargo CTD, does not drift. We concluded that only salinity measured by one float (Argo Australia 5904925) required a correction in the form of a constant offset of 20. 015; the other three floats did not need a salinity correction. Direct comparison between the salinity profiles collected by the four RBRargo floats and the closest salinity profiles from the ADMT-Argo and ADMT-CTD datasets (online supplemental section 2) demonstrated that the differences in salinity in the beginning and the end of the RBRargo operation periods were within the limits of 0.
c. In situ drift and offset corrections for RBRargo compared to electrode-based CTDs To put the RBRargo salinity drift analysis in context, we assessed the long-term stability of other Argo floats equipped with electrode-based SBE41/41CP. To compare the CTDs directly, Argo datafiles were downloaded from a GDAC for all floats that 1) operated starting 2011 in the same areas (the 208 3 208 rectangles around the float trajectories in Fig. 1a ) and 2) contained a sufficient number of DM data (at least 25 profiles). A total of 360 floats met these criteria; the median time of operation was about 4 years, and the median number of DM profiles was 175 (minimum of 27 profiles; maximum of 438 profiles). For each float, the salinity offsets used for DM correction were computed from the mean difference between the raw salinity (PSAL) and the adjusted salinity (PSAL_ADJUSTED) in all DM profiles.
In about 16% of the Argo floats with electrode conductivity sensors (57/360), TABLE  3. Salinity offsets calculated by the OWC method using the ADMT-CTD 2019v1 reference dataset at different spatial separation factors. Optimal time separation factors 10/30 years for all four floats were selected on the basis of Table  2   the applied salinity offsets exceeded 0. 01. For 31% of floats (111/360), the salinity drift exceeded 0. 0025 yr 21. One float with an RBRargo CTD (Argo Australia float 5904925) demonstrated a significant offset (20. 015) relative to ADMT-Argo reference salinity (Fig. 5a ), which is also the first float with RBR-equipped conductivity cell deployed in 2015. Since then, the design of the RBR conductivity cell was improved, with the thermistor located next to the conductivity cell (see Fig.
d. Detecting problematic reference data in salinity drift assessment The OWC calibration method, when applied to data from four RBRargo, indicated that the CTDs are very stable over two or more years. However, there remain anomalies in the calibration salinity that warrant further investigation because, as a statistical method, OWC cannot determine whether variations in the calibration salinity are related to sensor problems or oceanographic variability. In this section, we describe in detail the results from the OWC output of four RBRargo floats and demonstrate the methods helping us to avoid this kind of ambiguity. The approach we use includes 1) identifying spatial coherency in discrepancies between the analyzed Argo measurements and the reference dataset, 2) comparing the reference salinity fields calculated by the OWC to a different reference data source, and 3) applying the OWC analysis to other nearby contemporary Argo floats.
1) ARGO AUSTRALIA FLOAT 5904925 IN THE CORAL SEA For the Argo Australia float 5904925 deployed in the Coral Sea, the computed fit coefficients were stable during the entire 4-yr period of the float operation, demonstrating a high level of the sensor stability (Fig. 6a ). A more detailed analysis demonstrated that the deviations from the average offset were spatially coherent, suggesting that the discrepancy might be due a specific oceanographic feature that was measured by the float, but not captured by the reference dataset. In fact, for Argo Australia float 5904925, the geographical location of these deviations demonstrates that all profiles with salinity offsets larger than 20. 015 were concentrated in the area to the northeast from the Solomon Islands, between 98 and 128S and between 1618 and 1658E (Fig.