-
-
Notifications
You must be signed in to change notification settings - Fork 208
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Computing DUT1 #176
Comments
I think they're rounding to the nearest tenth of a second. Remember, they say "until further notice", so a more precise value would go out of date faster. Try computing it 6 months from now or whatever, or figure out when it hits 0.15, and see if IERS releases a bulletin. |
I am definitely not an expert here, I was expecting to have values interpolated, but also to have the exact value at the release time. Anyway, I followed @barrycarter suggestion and made some plot. As you can see:
To better understand what happens in the future (none can predict the future, so I was expecting strange things) I did the same plot every months until mid 2019: So, after July discontinuity, slope changes in October (as expected) to a very low value (as to catchup with the previous line) and then goes more or less stable after January. In the end, I was expecting a more predictable behaviour and more agreement with bulletins dates and values, but probably there are a lot of other things to take into account here (such as e.g. propagation in the future with what I think could be a model). What I would like to know is if the method to calculate DUT1 is correct or if I am misinterpreting something. |
Just being obnoxious, but could you correct 30/11/2018 in your comment to 30/11/2017? |
That's a good question, @corrado9999. The value DUT1 doesn't wind up being terribly important in an application like Skyfield, because it's the difference between the very important value UT1 and the really-not-important-at-all (for astronomy calculations) UTC. While it's nice to have a way to translate to and from UTC to display clock time to the user, it's a very bad time scale for computation, because it has a 1-second discontinuity each time the standards bodies decide to sync it back up with the Earth's irregularly slowing rotation. Instead, Skyfield needs and uses the value ΔT ( The series of bulletins you're reading happen to not be the source of data Skyfield uses for ΔT, which is why you're not seeing any relationship between the dates on which they issue bulletins and the inflection points in Skyfield's ΔT estimates. Instead, Skyfield uses linear extrapolation between the points in the data files: http://maia.usno.navy.mil/ser7/deltat.data As you can see, these are much higher precision than the tenth-of-a-second estimates you're seeing from the DUT series of bulletins, so they're more appropriate for astronomical calculations. I'm not sure, though, why the discontinuities you're seeing have such a clear sawtooth pattern. The precision of the floating point dates in Skyfield should be around 20μs, much smaller than it looks like the sawtooth jumps are in your graph. If you'd like to share the Python program that generates the graph, I'll be happy to look into the computations to try to figure out where the sawtooth is coming from! |
Probably not very clearly, by I already linked the code just before the plot. Sorry, it's very ugly and uncommented, hope it will be still useful. Although not used anywhere, do you think you could expose such value? I am not very happy to use an internal function to do this, and to compare the results with other libraries it's useful to have access to it. |
Yes, I'd missed the link! I'll take a look, thanks. |
I've now tried out the script! Alas, it errors out:
And I don't see myself, even in the commented code, exactly where the |
Unbelievable, I missed the most important line of code! Sorry about that, I just updated the gist. |
I understand now that the jagged red sawtooth line belongs with the right axis, not the left axis, of the graph; the legend hadn't made it clear to me which lines corresponded to which axes. So I think all mysteries are now cleared up? To recap, repeating questions from the thread above:
As explained, DUT1 is low precision, rounds to a tenth of a second,
The jitter in the slope
They occur at the data points in the high precision files
The
Yes, you are predicting it correctly! If those are indeed most of the outstanding issues, |
After looking at the various options, I decided that your question was so important that https://en.wikipedia.org/wiki/DUT1 Here's an example notebook that does so: https://github.com/skyfielders/astronomy-notebooks/blob/master/Skyfield-Notes/DUT1.ipynb by plotting |
Great! Thank you for your support. |
According to IERS and Wikipedia, DUT1 is the difference between UT1 and UTC, and it is kept in the range (-1,1) seconds by using the leap seconds. I looked both in the documentation and in the code, but I could not find any reference to it. So I tried to calculate it by using a Time instance.
The only way I found was by using a "private" method called
_utc_float
, but I am not sure if this is correct,The problem is that the IERS bulletin states that, starting from that very same date, the DUT1 value to be disseminated should be 0.1.
The text was updated successfully, but these errors were encountered: