OPUS and Earth Tides

Let me give this a shot.

Earth tides affect the geoid relative to the earth's center. The geoid is established as a mean of the geoid surface, therefore the surface would go up and down as the earth rotates. The coordinates of each spot on the earth are a meaned observation, and help as fixed for each day. The GNSS satellite orbits are also affected by earth tidal forces and are relative to the surface of the earth. As a CORS goes up and down, so do the satellites. It is my understanding that it is all accounted for in those very complicated orbit equations for each satellite.

Earth tides were well thought out years ago. It cannot all be perfectly predicted which is why, every day the prior day's orbits are recalculated from a gazillion observations.

Paul in PA

Correct me if I'm wrong, but earth tides and ocean loading only significantly affect PPP type position solution calculations?

https://igscb.jpl.nasa.gov/igscb/center/analysis/noaa.acn

The above document details the analysis strategy of the US NGS with respect to their contribution to the IGS. Note references to earth tide modeling in accordance with IERS conventions. BTW, lots of good details in the conventions available at the https://www.iers.org/IERS/EN/Publications/TechnicalNotes/tn32.html

Also see: https://www.iers.org/IERS/EN/Publications/TechnicalNotes/TechnicalNotes.html

HTH,

DMM

Also, from the (Windoze version) PAGES program output we see what modeling is performed and the date it was added/modified/corrected in the program.

*********************************************
* *
* pages(1607.11) *
* NOAA GPS Orbit Solution *
* 16/12/25 23:40 *
* *
*********************************************
* 9505.26: improved solid Earth tide model *
* 9505.26: NMF tropo mapping fct *
* 9507.21: 2 or 3 rad pr parameters *
* 9507.21: phase rotation correction *
* 9507.21: satellite elevation correction *
* 9507.31: ephemeris adjusted for EOP rates *
* 9508.04: model sub-daily EOP variations *
* 9508.09: correct ephemeris rotation & LOD *
* 9509.27: new apriori file & SINEX output *
* 9510.24: coordinates at data midpoint *
* 9511.06: mathematical correlation of DDs *
* 9601.31: correction of L1-L2 offset *
* 9605.08: read in fixed L1 & L2 integers *
* 9607.12: PWL EOP; EOP and Tropo global *
* 9609.03: correct nmf for high lat sites *
* 9609.03: split sv pos and vel controls *
* 9807.09: complete and consistent B1950 *
* 9809.18: multiple frequency estimation *
* 9901.01: satellite params can be global *
* 9908.11: install IERS subdaily EOP model *
* 9909.13: install option to estimate OLT *
* 0109.21: IGS std subdaily EOP corrections *
* 0203.19: modify use of std subdaily EOP *
* 0204.17: observation elevation weighting *
* 0209.17: IERS std Earth tide model option *
* 0209.24: individual satellite weighting *
* 0402.26: correct init of IERS Earth tide *
* 0407.13: enable ANTEX APCs *
* 0410.07: estimate SV offsets and APCs *
* 0502.25: estimate position at monument *
* 0507.29: fix poltid.f: north_corr*-1.0 *
* 0508.10: add ortho_eop for subdaily EOP *
* 0509.29: add BLOCK IIR-A, IIR-B, IIR-M *
* 0601.10: XYZs in *hd.dat now fmtd 3f14.4 *
* 0604.26: use 3D ocean-loading model *
* 0606.13: add north, east tropo gradients *
* 0606.27: replace Herring with Boehm meteo *
* 0606.27: replace CfA with GMF map funct *
* 0607.31: add subdaily nutation in PM *
* 0608.28: fixed relativity Shapiro delay *
* 0806.19: fixed SV offsets read from ANTEX *
* 0903.17: adjust and constrain NEU option *
* 0903.24: update hardisp + dehanttideinel *
* 0908.12: option to use OTL and CMC models *
* 0909.09: apply CMC as required by eph *

Paul in PA, post: 407858, member: 236 wrote: It is my understanding that it is all accounted for in those very complicated orbit equations for each satellite.

I'm sure there is a lot of computation to apply the tidal effects to orbits. But I don't think the orbits can account for what goes on when you are comparing your data to the CORS. A change in orbit doesn't have the same effect at every ground station.

GeeOddMike, post: 407863, member: 677 wrote: The above document ... lots of good details in the conventions available at

I'm afraid I can't see the forest for the trees. I see PhD level formulas there but am not sure whether those are only used to figure out where the fixed stations are, or whether something similar also is done when your session is processed by OPUS.

GeeOddMike, post: 407866, member: 677 wrote: improved solid Earth tide model

GeeOddMike, post: 407866, member: 677 wrote: 0209.17: IERS std Earth tide model option

Entries like that seem to say OPUS does the calculations for each submission. I don't see anything in the extended report that reflects that. I'd have expected to see that along with the velocity and phase-center-to-arp adjustments.

Bill93, post: 407871, member: 87 wrote: I'm sure there is a lot of computation to apply the tidal effects to orbits. But I don't think the orbits can account for what goes on when you are comparing your data to the CORS. A change in orbit doesn't have the same effect at every ground station.

I'm afraid I can't see the forest for the trees. I see PhD level formulas there but am not sure whether those are only used to figure out where the fixed stations are, or whether something similar also is done when your session is processed by OPUS.

Entries like that seem to say OPUS does the calculations for each submission. I don't see anything in the extended report that reflects that. I'd have expected to see that along with the velocity and phase-center-to-arp adjustments.

Bill,

"THE GUY" to answer most of your questions would be Dr. Mark Schenewerk. I'm sure that there are others who have a good-excellent handle on exactly what goes on behind the PAGES curtain, but I think Mark is still "The Guy."

Now there are (I believe) some differences between PAGES and PAGES_Lt (used by OPUIS_S), but I couldn't begin to even guess just what they might be. Obviously PAGES is a session processor, whereas PAGE_Lt is a (single) Baseline Processor, but the difference might not end there.

Loyal

This presentation "Using and Understanding OPUS" says:
"OPUS‰ÛS modeling highlights: International Earth Rotation Service (IERS) 2003 solid Earth tide model."
http://c.ymcdn.com/sites/www.nysapls.org/resource/resmgr/imported/012314-13-Handout_OPUS_2013_grayscale.pdf

The reason why it's not listed along with the velocity and APC-ARP corrections is that earth tides are corrected at the observation level, not at the coordinate level, as it may vary a lot within a long session.

-FGN.

Thanks. That makes a lot of sense.

And on a side note, thanks for your work on Wikipedia also. I just noticed that we both were commenting on Theodolite.

Bill,

Earth tides are effected by the sun and twice as strong by the moon and are generally less than ocean tides.

Given that the orbits account for the satellite locations, earth tides influence horizontal location at a level that you cannot measure. We are then left with vertical locations. Vertical OPUS positions are based on differencing from where the CORS are to where your receiver is, the satellites being known. If the CORS are high so are you. NGS will note that your elevation is much less accurate than your position, for which there are several reasons. Horizontally your position is determined from Satellites to the N, S, E & W which tends to balance out the observations. Elevations can only be determined from Up. If we had the ability to receive GPS signals from down also that would improve the geometry of elevation calculations. That is probably more important than the minor difference in elevation due to earth tides from CORS that might all be several hundred miles away, all in the same direction. The solution for that is OPUS-RS which surrounds your site with CORS at much closer ranges.

With that in mind I almost always use OPUS-RS when my major goal is elevations. I just did a site where my OPUS solution came back from 3 CORS surrounding my project and about equal distance away.

LAT: 40 52 48.71962 0.011(m)
E LON: 285 5 10.53364 0.011(m)
W LON: 74 54 49.46636 0.011(m)
EL HGT: 123.946(m) 0.007(m)
ORTHO HGT: 157.171(m) 0.017(m) [NAVD88 (Computed using GEOID12B)]

BASE STATIONS USED
PID DESIGNATION LATITUDE LONGITUDE DISTANCE(m)
DK7751 NJWC WARREN COUNTY CORS ARP N404803.072 W0750452.530 16651.0
DJ8947 PAMS STROUDSBURG CORS ARP N405944.024 W0751503.835 31163.5
DK4432 NJSC SUSSEX COUNTY CORS ARP N410331.676 W0744509.429 24028.1

I held those OPUS values and merely used OPUS-RS subfiles a few days later as a check.

As to earth tides, the only real difference is if you had to use CORS several thousands of miles away. But, a bigger problem when using CORS so distant is commonality of satellites in view. Differencing can only be done from common satellites.

Paul in PA

Paul in PA, post: 407918, member: 236 wrote: the sun and twice as strong by the moon

That's what I got from the WIkipedia article.

Paul in PA, post: 407918, member: 236 wrote: Vertical OPUS positions are based on differencing from where the CORS are to where your receiver ... If the CORS are high so are you.

Except that Dr. Nievinski has told us that the earth tides are dealt with before the differencing, so they do not assume you go up and down the same amount as the CORS.

Paul in PA, post: 407918, member: 236 wrote: ORTHO HGT: 157.171(m) 0.017(m)

A recent thread demonstrated that the pk-pk computation for ortho height is incorrect and hence meaningless. It is too sensitive to ellip height pk-pk and too optimistic in geoid uncertainty.

"Except that Dr. Nievinski has told us that the earth tides are dealt with before the differencing, so they do not assume you go up and down the same amount as the CORS."

No disagreement. If the CORS are adjusted for earth tides before the differencing, then that adjustment follows through to your OPUS site. It may not be perfectly correct but the variance of height difference is within my error budget. Assume 240 mi to CORS and 24,000 miles of earth circumference, then the error might be on the order of 0.01, I can live with that. If the CORS are not going up and down, what then are they dealing with?

When using OPUS-RS and you are within the polygon of CORS, you are most definitely going up and down with the surrounding CORS.

"EL HGT: 123.946(m) 0.007(m)"

Differencing is based on the fixed system, XYZ/LatLonEllip. I accept the mathematics, the ortho correction is what it is and I can do nothing about it.

Paul in PA

FWIW,

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4004007/
this is article "Estimates of Minor Ocean Tide Loading Displacement and Its Impact on Continuous GPS Coordinate Time Series"

Also, from the README_PNT6M file for NGS vector reduction program PAGE-NT (PC version available for download from their ftp site) we have
the following entries related to OLT. The "skeleton file" provides parameters for the program. Note the reference to "adjust at mon" and to
"use phase pattern Horiz".

In practice, the 3-D site displacement due to OTL is calculated by:

ëÓc=‰öÔjAcjcos(ìàj(t)‰öÕì¥cj) (1)

where ëÓc denotes a displacement component (radial, west and south) at a particular site
at time t, j denotes the tidal component set, amplitudes Acj and phases ì¥cj describe the loading response for the chosen site.

1a) The default.txt file has a C::EO section that
should be set up as follows to use the MIT ocean-loading grid:

C::EO ========= EXTRA OPTIONS for Pages.skl ===================================
21
EPOCH FOR OUTPUT
1997 1 1 0 0 0.0
observation standard error
0.050e+00 0.020e+00
USE FRAME ITRF00
adjust at mon
use phase pattern horiz
ocean-loading grid file
c:e1pnt6Motl_FES2004.grid
ocean-loading center-of-mass corrections
M2 NCDF_FES2004 -1.2661E-03 -1.4298E-03 -1.3724E-03 8.2077E-04 1.1479E-03 2.3005E-04
S2 NCDF_FES2004 -1.7763E-04 -5.7273E-04 -5.3350E-04 -3.1591E-04 -5.1370E-05 2.8184E-04
N2 NCDF_FES2004 -3.2372E-04 -2.8986E-04 -2.7121E-04 1.9849E-04 2.6018E-04 -1.4302E-04
K2 NCDF_FES2004 -1.1814E-04 -1.5250E-04 -1.1223E-04 -1.0889E-05 -1.5751E-05 1.2367E-04
K1 NCDF_FES2004 -1.1370E-03 4.4839E-03 -1.8539E-03 -8.6426E-04 -9.1022E-04 -1.7823E-03
O1 NCDF_FES2004 -1.6802E-04 2.9702E-03 -1.3985E-03 -2.2975E-04 -8.8858E-04 -6.4989E-04
P1 NCDF_FES2004 -3.6495E-04 1.4941E-03 -6.1436E-04 -2.9129E-04 -2.9261E-04 -5.7461E-04
Q1 NCDF_FES2004 3.0709E-05 4.5472E-04 -2.7831E-04 -2.9313E-05 -2.1734E-04 -4.1637E-05
Mf NCDF_FES2004 -5.0643E-04 -7.3040E-05 -2.2065E-04 4.1472E-04 -1.0212E-04 8.2276E-05
Mm NCDF_FES2004 -2.7885E-04 2.0596E-05 4.6882E-05 1.8399E-04 -7.4897E-06 1.3209E-05
Ssa NCDF_FES2004 -1.4899E-04 2.6146E-06 1.3687E-04 3.5475E-05 -2.4093E-05 3.1666E-07
C::SI ========= SINEX Information =============================================

The "use phase pattern horiz" line tells PAGES to use the North and East
offsets for each ground antenna, from the ANTEX file or from the

differencing is important but double differencing is really important, anyway that's what Dr. Schenewerk spent time explaining.

He also kept insisting that if you believe the numbers from GPS you are..........well not rational..........believe nothing, trust nothing.

MightyMoe, post: 408209, member: 700 wrote: He also kept insisting that if you believe the numbers from GPS you are..........well not rational...

I'd like to see that explained in more detail. Just how bad is it?

MightyMoe, post: 408209, member: 700 wrote: He also kept insisting that if you believe the numbers from GPS you are..........well not rational...

I'd like to see that explained in considerably more detail.

astrodanco, post: 408211, member: 7558 wrote: I'd like to see that explained in more detail. Just how bad is it?

His point was that you need redundancy,,,,,,,,,,the more the better.

The old saying of "trust but verify" should be "don't trust and verify" respecting GPS, my words I'm not quoting or paraphrasing him,,,,,;)

The pk-pk numbers in OPUS-S are based on a sample of only 3, so can vary considerably. The Schwarz paper gives the std deviation of the range as 0.8884 times the sigma of the normal population the samples are drawn from. By comparison the std deviation of the mean of three samples would be smaller at 0.577 sigma.

I suspect the tails of the distribution of the range variable are long. As an exercise, maybe I'll try to figure out 95% confidence limits on the range of 3 samples with known sigma. I expect it will be wider than the +/-1.96 sigma that applies to a single gaussian normal variable.

The "Horizontal Accuracy" and "Vertical Accuracy" numbers in the OPUS extended report are probably based on the variations seen on each vector over time and then the variances of the vectors combined without regard to how much those vectors disagree with each other. Variations in the propagation may be correlated between CORS, and between CORS vs. your location, and the common components not detected in the analysis.

A better estimate of the accuracy of your result would somehow involve both the pk-pk range and the extended report accuracy values, but I'm not sure how to best combine them.

Since pk-pk range is a positive number, of course the confidence limits will be radically different from a gaussian normal. Duh.

A Matlab simulation finds the 95% limits (2.5% to 97.5%) to be at
0.303 to 3.682 times population sigma in Range, or
0.180 to 2.176 times MeanRange

Bill93, post: 408224, member: 87 wrote: Since pk-pk range is a positive number, of course the confidence limits will be radically different from a gaussian normal. Duh.

A Matlab simulation finds the 95% limits (2.5% to 97.5%) to be at
0.303 to 3.682 times population sigma in Range, or
0.180 to 2.176 times MeanRange

I dunno Bill.

While I always ‰ÛÏlook‰Û at the peak-peak variance on my OPUS_S solutions, I don't really put much weight on them. It's been my experience (out here), that the p-p variance says more about the 3 CORS used, than it does about the ‰ÛÏremote Point.‰Û

Although I always ‰ÛÏcherry pick‰Û the CORS used by OPUS, and pay a lot of attention to each CORS behavior (both short term and long term), even the most stable and well behaved CORS isn't perfect. My modus operandi has always been to export the dx, dy, dz, vector data, along with the rms and correlation data out of the G-Files, and run things through COLUMBUS to get a better feel for the coordinate estimate at the Remote Station.

Loyal