improve interpolation in IERS data

Currently, UT1-UTC is interpolated linearly in the IERS data, ignoring the effects of tides (which are not included in the tables)..While this is fine for almost all purposes, the recommended procedure is to use a Lagrangian interpolation scheme and include the tides [1]. This is a reminder to implement this in IERS, following the ideas in the fortran code mentioned in [1], after checking what should be done for jumps in UT1-UTC due to leap seconds.

[1] http://maia.usno.navy.mil/iers-gaz13

Mostly so there is a record: from an e-mail exchange with Daniel Gambis (IERS), the recommended procedure is:

Transform UT1-UTC into UT1-TAI by removing leap seconds. You get a continous time scale
Transform UT1-TAI into UT1R-TAI by correcting for the luni-solar zonal tides
Interpolate by applying for instance interp.f
Add back the zonal tides to get UT1-TAI
Transform back to UT1-UTC by adding back the leap second

The interpolation/tide routine to follow would be ftp://hpiers.obspm.fr/iers/models/interp.f

Cleared milestone as I won't be able to do this for 1.0. It should be done for ultimate precision and is not in itself difficult.

I find myself in a position of needing this rather badly. I've made some progress on getting interp.f ported, but have run in to troubles with the IERS_A code apparently always reporting the IERS_B columns of the finals2000A.all, and completely missing the bit about needing to back out the zonal tides before I put them back in.

#!/usr/bin/python3
from astropy.utils import iers
from astropy.time import Time
t = Time('2017-08-20',format='isot')
iers_a = iers.IERS_A.open()
dX,dY = iers_a.dcip_xy(t)
XP,YP = iers_a.pm_xy(t)
dUT1UTC = iers_a.ut1_utc(t)
# 17 820 57985.00 I  0.228614 0.000009  0.378523 0.000024  I 0.3403042 0.0000064  0.2552 0.0047  I     0.122\
    0.134     0.179    0.208  0.228598  0.378522  0.3402929     0.150     0.190
print(XP)
print(YP)
print(dX)
print(dY)
print(dUT1UTC)

@mcbeth

@mcbeth - yes, this has long been on my list! I'm a bit confused about what problem you have with the columns, though it is certainly the case that the various methods use IERS_B results in preference to those of IERS_A (since IERS_B results are presumably the "final" ones).

But perhaps more importantly, about the backing out of the zonal tides: I looked back at the e-mail exchange I had with Daniel Gambis of the Observatoire de Paris, and he wrote that the corrections that are in the table include the zonal tides already (unlike what the text accompanying interp.f suggests), and one would first take those out (presumably using the RAY routine), then interpolate, and finally add them back again.

I must say that I have partially held back from implementing all this because I wasn't sure how to test that whatever I did was in fact correct... Do you have any way to verify?

First, I was hoping to use:
http://maia.usno.navy.mil/t2c36e/t2c36e.html

It provides the EOM instead of the UT1-UTC, so it is a step away from an easy test.

I've also been looking at
https://github.com/USNavalResearchLaboratory/TrackerComponentLibrary/blob/master/Astronomical%20Code/getEOP.m

Which comes from the USNO (and would be authoritative?). I was hoping to use that as the official comparison, but I just turned in a bug report against the code and its interpretation of the dX/dY terms.

My assumption about IERS_A/B was coming from my reading of that USNO code, as he uses the IERS_A exclusively in his calculations.

So, I've been talking about Tech Note 36 (which I think may be about prediction), and the algorithm you describe is close to Gazette 13 (which I think is about adjusting measurements). I think it's clear that for any moment in the past Gazette 13 is the right thing (what you were guiding me toward).

I've wrapped the fortran code from Gazette 13 using pybind11, so I have evidence that my python versions of the lagrange interpolation and the ray model match to within compiler floating point variability. I'm going to try to incorporate that in to my EOM code and start comparing that against the website I posted from the USNO, see how it goes.

I probably need some of your contacts with IERS to see if I'm crazy, if you don't mind sharing

Don't mind sharing though probably best off-line. You can contact me at <same_username>@astro.utoronto.ca; but the person I contacted was Daniel Gambis (see http://hpiers.obspm.fr/eop-pc/index.php; e-mails in the link under the "director" item of "contact" in the bottom of the page).

@helgee

p.s. Looking at links to this issue, I see @helgee raised a similar issue about interpolation in the IERS tables for JuliaAstro - @helgee: did you find some official numbers to compare against?

Hi, this issue is dead. Wondering if you'd like a hand still?

@Juan-789

@Juan-789 - yes, it would be great if someone could implement this!

Hello, I would like to contribute to this issue. Would it be possible to assign it to me?

Is this still relevant? Any active pull requests?

Navigation Menu

Repository navigation

improve interpolation in IERS data #1803

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

improve interpolation in IERS data #1803

Description

Activity

mhvk commented on Dec 10, 2013

mhvk commented on Jan 13, 2015

mcbeth commented on May 20, 2019

mhvk commented on May 20, 2019

mcbeth commented on May 20, 2019

mcbeth commented on May 23, 2019

mhvk commented on May 23, 2019

mhvk commented on May 23, 2019

Juan-789 commented on Mar 9, 2025

mhvk commented on Mar 9, 2025

LoveChauhan-18 commented on Feb 13, 2026

simolanayak commented on Apr 27, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions