# Presentation: 268028

## Future IGS & inter-technique SINEX combinations: Issues and challenges

- D. Lavallée (aka Peter Clarke), R. Ferland, D. Thaller, T. Herring, R. Biancale.
- 1 Delft University of Technology, Newcastle University
- 2 Natural Resources, Canada
- 3 Astronomical Institute University of Berne
- 4 Massachusetts Institute of Technology
- 5 Centre National d’Etudes Spatiale

## Intro

- Discuss SINEX Products at:
**Internal interface** between internal (AC) products
- Affects IGS weekly and cumulative combination
**External interface** with external products
- Affects other technique services and ultimately IERS
- How should the IGS guide the products at these interfaces?

## Intro

**Internal interface** between internal (AC) products
- IGS guidelines
- Constraint and de-constraint
- SINEX format
- Discontinuities
**External interface** with external products
- IERS Unification Workshop
- Potential new IERS products
- Daily versus weekly
- New products, troposphere and local ties
- Preliminary Recommendations

## The Internal Interface: Constraint & De-constraint

- Numerical Issues
- Singular Matrices
- Near Singular Matrices (unpredictable effects)
- Unremovable/Unavailable Constraints
- Normal equations versus solutions
- Automation = Unattended
- Needs also automated Quality Control
- Software/procedure Changes:
- Ideally, provide parallel solutions
- Minimally, provide Warning

## SINEX 1.0, 2.0, 2.01, 2.02 (Proposal 2.10) -> SINEX 2.x

- Extensive format – Blessing and curse
- Evolving requirements
- Multi service
- Always growing-No going back!
- Backward Compatibility
- SINEX in Use
- Someone gives a subset (AC)
- Someone takes a subset (Combination Center/User)
- Format compliance of a file is never fully checked or required, and historically is never perfect.
- SINEX file + format description is not enough!
- Requires Agreement on subset of format used
- The unwritten rules
- The informally accepted bits
- IGS guidelines would help here
- Multi-technique SINEX software?

## SINEX 2.x

- Historical/Typical format development cycle

**Someone Needs **
**New parameters**

**They think of a**
**way to do it**

**Proposal**
**made and **
**tested**

**Implementation**
**And use**

**Official Format **
**Description**
**(Full **
**documentation)**

**Implementation**
**and use**
**(informal or **
**no documentation)**

- Common or extensive usage by some/all

- e.g. discontinuities format (IERS, IGS in use)
- , current proposals (GGOS-D in use)

## SINEX:Issues and Challenges

- Unwritten rules, missing documentation, informally accepted bits, fully in use but not “official” parameters
- Can sometimes make life difficult (particularly combination centers and other users)
- Interrupts automation
- Discourages product use by new groups
- Allows misinterpretation of SINEX products.
- Corrupts historical archive
- Will we ever move to a format first, implementation second approach?
- Would need multi-service working group or panel
- Would need regular deadlines for proposal consideration, proposal acceptance and proposal documentation
- Could consider data center side checking of sinex files

## Discontinuities: Error in Rate Due to Known Offsets

## Discontinuities

- Lots of people have this problem
- Possibilities for common effort
- Offset database
- Logical extension of site logs database
- IGS Discontinuities SINEX
- Submission (SINEX+Wiki)
- Agreement/locking of records
- Offset prediction (e.g. earthquakes)

## IERS Unification Workshop Action items 1/2

**This is a IGS specific summary! Full details: IERS website -> Organisation -> Workshops**
- SINEX Extension of Parameterization / Naming
- Generation of daily (24-hour) SINEX files (rapid solutions).  Coordinates, velocities, EOP’s, troposphere, ionosphere.
- Start the reporting of the troposphere parameters in the daily SINEX files
- A priori representation of the ERPs: ACs should converge to a unique representation (interpolation) of the a priori ERP values as a linear function (linear interpolation) between the vertices.
- Modeling standards for next ITRF :
- Technique-specific forms (a template) are provided by IVS, IGS, ILRS, IDS. Generation of a unified form, forms filled and returned by all ACs
- Atmospheric loading should be reconsidered after tests by van Dam et al.
- Recommend 3 receivers at fundamental sites, at least 2, One master station (of the three) should be analyzed by the IGS. The 2 (or 3) antennas may never be changed at the same time. It is not yet clear who will process the local “network”

**Notes:**
From Peter’s talk, 6 AC’s us GMF/GPT, zero using Vienna.

## IERS Unification Workshop Action items 2/2

- Optimum solution sinex versus sinex for combination
**Investigations**
- Investigate the reason for cut-off angle dependent effects and elevation-dependent weighting. ACs should freeze their selection of processing options and models between two reprocessing activities
- Further studies are required to understand the bias between SLR and microwave GPS orbits
- IDS and IGS to investigate improved radiation pressure models and parameterizations to reduce impact on the geocenter estimates, especially the new satellite box- and wing-models from UCL
- Study the influence of the arc length and orbit constraints on geocenter estimates
- IGS should consider applying the ionospheric corrections of higher order to be more consistent with the other Services’ products

## Daily vs weekly products

- General issues of consistency
- Some applications call for daily coordinates.
- Advantages to linking certain parameters across a number of day boundaries, or entire week.
- E.g. Solar radiation parameters and Center of mass estimate.

## The External Interface: Troposphere Combination for GPS and VLBI

- Correlation with station coordinates
- Stabilization (especially if local tie is missing)
- Improvement in height repeatability (negative values) for most sites if Trop Zenith delays are combined.
- Improvement is independent of agreement/disagreement with theory

**Notes:**
Figure-1: 
The time seires of GPS and VLBI are independently estimated, and the mean difference is compared to a theoretical value for this difference. This difference can be modelled differently; we tested three methods:
 Rule of thumb: 10m height difference = 3mm difference in troposphere zenith delay
 Standard atmosphere: Saastamoinen model using theoretical values for pressure/temperature according to the Berg model
 Meteorology: Saastamoinen model using true meteorological values

Figure 2:
Instead of adding the local tie, the troposphere zenith delay was combined (each co-location was tested individually); the figure shows the change in height repeatability for the solution with combined ZTD vs. not-combined ZTD; negative values indicate an improvement for the repeatability.
Instead of sorting according to the station names, it is sorted according the discrepancy of the zenith delay differences compared to theory (Figure 1), showing that the improvement of height repeatability is not correlated with the discrepancy shown in Figure-1.

## The External Interface: Local tie (LT) validation

- Including troposphere parameters into the combination provides an independent evaluation of LT

**Notes:**
Figure-3:
Mis-matching local tie for Fairbanks causes a bias in the north gradients if it is introduced (solution named „G+V: 8 LT“); 
If the Fairbanks local tie is not introduced (solution named „G+V: 7 LT“), the gradients are similar to the single-technique solutions, and the GPS and VLBI estimates agree very well.

## The External Interface: Local tie (LT) validation

- Using UT for GPS-VLBI local ties

**Notes:**
The bias for a VLBI-only solution vs. IERS-C04 is at 0.0025ms (black star).
Introducing all local ties causes a shift in UT with a bias of ~0.014ms (red triangle).
Then, each local tie was tested individually (i.e., computing a solution by ignoring only one local tie at time => altogether 8 solutions, marked with stars): two solutions are striking: those with ignoring the Fairbanks and the Westford local tie.
These two local ties were ignored (solution marked with blue diamond) yielding only a bias of ~0.0045ms.
No other local tie can further reduce this bias without degrading the solution in terms of coordiante repeatability (solutions marked with circles)

## Recommendations: Internal products

**COMBI-1: Define and maintain IGS conventions/procedure/guidelines document**
**COMBI-2: Use agreed set of models (currently IERS 2003)**
- Essential  for both internal (GNSS) and external (other services, IERS) product interface. Recommend that SINEX files detail applied models and procedure. A SINEX block could be defined specifically to include this information.
**COMBI-3: Report all apriori constraints, ensure** **they are removable**.
- Unconstrained solutions are preferred. Loose (2-3 order of magnitude than the estimates uncertainty) may be used. Inner (origin, orientation, scale) constraints acceptable.
**COMBI-4: Minimize equipment changes due to GNSS modernisation**
- The modernization should be coordinated to minimize equipment changes. Multiple receivers and antennas should be used in parallel at core sites, there should be a clear procedure for handling the processing in these cases.
**COMBI-5: Mechanism to contribute and share station discontinuity information**
- All users of station coordinates time series can potentially contribute to and benefit from this.

## Recommendations: External products

- COMBI-6: AC’s and hence IGS combination includes as many of the co-location sites as possible.
- COMBI-7: Include troposphere parameters in the SINEX files.
- Natural extension to the existing coordinates parameters, to which they are correlated. They can be combined with estimated troposphere from other techniques such as VLBI and DORIS to good effect. This should be done in conjunction with an upgrade to SINEX Version 2.x
- COMBI-8: Provide rapid combined IGS SINEX Product.
- Include a selected set of stations (important: Wettzell, Kokee Park, Tsukuba) and pole positions to help to improve VLBI UT rapid solution.
- COMBI-10: That the mechanism to extend the SINEX format ensures backward compatibility, full documentation and encourages use of the official format
- COMBI-9: Provide mechanism to stream extended products for inter-technique combinations via IGS
- Where IGS AC’s can provide extended products (e.g. daily sinex, or normal equations of extended parameterisations)  for inter-technique combinations, AND these products are directly related to the IGS products, that these products are streamed via IGS.