Repository navigation
current sidereal_time is broken #3274
Description
Python 2.7.5 (default, Nov 3 2014, 14:33:39)
[GCC 4.8.3 20140911 (Red Hat 4.8.3-7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from astropy.time import Time
>>> nowt = Time.now()
>>> print nowt
2015-01-06 11:16:27.877111
>>> nowt.sidereal_time('mean','greenwich')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib64/python2.7/site-packages/astropy-0.4.2-py2.7-linux-x86_64.egg/astropy/time/core.py", line 564, in sidereal_time
gst = self._erfa_sidereal_time(available_models[model.upper()])
File "/usr/lib64/python2.7/site-packages/astropy-0.4.2-py2.7-linux-x86_64.egg/astropy/time/core.py", line 578, in _erfa_sidereal_time
for jd_part in ('jd1', 'jd2')]
File "/usr/lib64/python2.7/site-packages/astropy-0.4.2-py2.7-linux-x86_64.egg/astropy/time/core.py", line 734, in __getattr__
tm._set_scale(attr)
File "/usr/lib64/python2.7/site-packages/astropy-0.4.2-py2.7-linux-x86_64.egg/astropy/time/core.py", line 404, in _set_scale
args.append(get_dt(jd1, jd2))
File "/usr/lib64/python2.7/site-packages/astropy-0.4.2-py2.7-linux-x86_64.egg/astropy/time/core.py", line 869, in _get_delta_ut1_utc
delta = iers_table.ut1_utc(jd1, jd2)
File "/usr/lib64/python2.7/site-packages/astropy-0.4.2-py2.7-linux-x86_64.egg/astropy/utils/iers/iers.py", line 229, in ut1_utc
raise IndexError('(some) times are outside of range covered '
IndexError: (some) times are outside of range covered by IERS table.
Activity
mhvk commentedon Jan 6, 2015
@ThemosTsikas - the problem is that to calculate the sidereal time, one needs
UT1, which cannot be calculated precisely without having up-to-date earth rotation information: see http://docs.astropy.org/en/latest/time/index.html#transformation-offsetsSo, the code is not really broken. That said, the error message and documentation for sidereal time could be clearer.... Would you have a suggestion for how we should change it so you would more easily have found what to do?
astrofrog commentedon Jan 6, 2015
@mhvk - the thing is, doing:
seems simple enough that it should work. Astropy should probably auto-download the IERS tables if needed, and if not available, it could assume that there are no leap seconds since the release and emit a warning, right? I think this is the same issue as for the observation planning with
astropy.coordinates(cc @eteq)mhvk commentedon Jan 6, 2015
@astrofrog - yes, we need to address this somehow, as clearly right now the behaviour is confusing (see also #3105). That said, you really don't want to point your telescope 15" off just because you missed a warning -- I do think an exception remains appropriate, especially since we do have a mechanism already to override it.
Most important would seem to allow auto-downloading of the IERS table; see new issue #3275 and #1697 for an old one to update IERS B automatically for every astropy release.
astrofrog commentedon Jan 6, 2015
As a side note, I'm curious about how other tools deal with this - I don't remember this ever being an issue with other tools, so do they ignore the leap seconds? Anyone know what e.g. AST and kapteyn do?
ThemosTsikas commentedon Jan 6, 2015
I would be happy with an extra argument to sidereal_time to indicate that a low precision result is acceptable. The user could try a protected high precision call first and call the low precision version if there's an exception.
taldcroft commentedon Jan 6, 2015
@mhvk - Did you just pick 15" out as a big number or does that mean something? I just looked and IERS claims the accuracy of the IERS-A table out to 90 days is 0.0125 seconds. So that should be just fine in any realistic telescope pointing situation, no?
http://hpiers.obspm.fr/iers/bul/bulb/explanatory.html
taldcroft commentedon Jan 6, 2015
So basically I would say to automatically have things work if the IERS-A table covers it. Issue a warning but not exception.
mhvk commentedon Jan 6, 2015
Yes, I'm happy with doing IERS A (even without a warning). I'm much more hesitant with automatically defaulting to UT1-UTC=0 for times further into the future, or if the table is not available/cannot be downloaded. (15" is 1s in time, i.e., without any information and including a possible leap second).
astrofrog commentedon Jan 6, 2015
Thinking about this a bit, no-one points a telescope using alt/az these days, mainly ra/dec, right? So that means that computing alt/az is mainly used to determine e.g. visibility, air mass, etc. for which a 15" offset is not likely important?
taldcroft commentedon Jan 6, 2015
@astrofrog - I was thinking along the same lines as well. Maybe outside the IERS-A time range then issue a warning saying there may be significant uncertainties or possible leap seconds.
mhvk commentedon Jan 6, 2015
@astrofrog - It depends on whether you think anybody would use astropy within the telescope control system! But this would be OK if we go with the automatic IERS A option (and automatic IERS A updating).
I'm not convinced that a warning is the way to go: I don't know how your scripts work, but mine usually have tons of warnings about malformed fits headers and irrelevant crap like that, which has left me fully trained to ignore any warning. I prefer that without IERS A, the user has to explicitly tell that they are OK with uncertain results.
Anyway, maybe best to first get to the important one: implement IERS A downloading/updating. This is something well beyond my skill set, but @eteq had mentioned he had ideas about how to do it.
taldcroft commentedon Jan 6, 2015
Let's just say you have an RA and Dec and want to calculate an Alt/Az for some location and time two years in the future. Sub-arcsecond accuracy is not a requirement. What would be the path for a user to do this in a natural way (i.e. same as for a time in the past or present) without getting an exception? Somehow the "I'm OK with low-precision" argument needs to get encapsulated in the coordinate, maybe in the
obstime? That would be arcane to me.We often get in this discussion, but I think that astropy has the responsibility to clearly document the limitations and accuracy of underlying algorithms, but we do not have to protect them (with the hammer of raising an exception) from regimes where the accuracy is lower.
mhvk commentedon Jan 6, 2015
@taldcroft - hmm, it seems our roles have reversed ! See #1145 (comment), where you state
It is this that convinced me at the time (#1145 (comment)), and indeed led me to write nearly the same 1.5 years later...
But perhaps it is just that you feel this does not hold for
sidereal_time(which, of course, requires UT1)? Though I think the coordinate framework does use UT1 directly (and @eteq has, I think, added a try/except to capture and ignore the exception, or used the possibility to get flags from iers).taldcroft commentedon Jan 6, 2015
😄 - at least that was 1.5 years ago and not last month... However in context perhaps it isn't a complete 180 degree switch, since in my mind the issue there was more if IERS data exist for the requested time, but are just not on the user's computer. (Caveat, I did not re-read the thread carefully). In that case the reasonable astronomer (knowing that astropy is aware of IERS) could easily assume that astropy is doing the right thing under the hood when it was not.
In other words, if astropy is able to provide a state-of-the-art answer using the best available data from IERS, then great, always do that. If the user is asking for UT1 for more than a year in the future where accurate predictions are simply not available, then just document that and perhaps issue a warning (which we all agree is weak).
astrofrog commentedon Jan 6, 2015
@mhvk - regarding operating a telescope - if you were to do that, then you would be computing times in the present and could then use the downloaded table. I don't see a use case where one needs 15" accuracy in the several month-future badly enough that an exception is necessary (and therefore I think a warning would be fine).
mhvk commentedon Jan 6, 2015
I think I'd be happy with a state where there would be an exception if IERS data should be available (but happens not to be on someone's computer), and no exception when the time is further ahead of the present than the IERS A tables cover. It would seem the path forward then is to make issue #3275 into a PR...
ThemosTsikas commentedon Jan 7, 2015
Apologies if I'm stating the obvious but this is reminiscent of the way that the IEEE floating point standard handles exceptions. It's a two-pronged approach: you can choose (at any point in your code) to have exceptions raised (from that point on until you explicitly say otherwise). Whether you do or don't, a "sticky" flag is also maintained. If you choose to run without exceptions raised, you can always clear the flag before some code and then inspect it after any piece of code to see if an inexact, say, condition arose at any intervening time.
Would it help your way of working if you had access to such a sticky flag saying effectively that at some point we performed a calculation at reduced precision?
Also, is there any way of getting an approximate current sidereal_time as things stand now? Thanks
mhvk commentedon Jan 7, 2015
@ThemosTsikas - this is not a bad suggestion and we have been thinking of context managers to do something alike (at least in other situations, e.g., in allowing implicit conversion from radians to dimensionless).
As for the practical question, yes, right now it is possible to get
sidereal_timeto reduced precision, by explicitly setting the offset of UT1 from UTC:(Of course, for the current time you can also get it much more precisely following the instructions in http://docs.astropy.org/en/latest/time/index.html#transformation-offsets)
embray commentedon Jan 12, 2015
Back to the issue of actually updating the IERS A table, which I think should happen automatically when needed, I don't think it's necessary to redownload the whole table (forgive me if we already have code that does this, but I don't think we do...)
So the
Last-Modifiedheader immediately tells us whether or not an update is needed. Better still, theETagcan be used for the same purpose. More usefully, theAccept-Ranges: bytesmeans we can just download updates to the file without redownloading the entire file. That of course assumes that new predictions are only appended to the end of the file and they don't go back and update old predictions? Is that something we can guarantee? Then it's only necessary to seek to the last bulletin we have and download any updates starting from there, rather than re-download the entire table.mhvk commentedon Jan 13, 2015
@embray - I agree we would only need to download the parts that have changed. I think it is pretty much guaranteed by IERS that the format does not change (but ideally one would have some checksum or other...).
embray commentedon Jan 13, 2015
The
ETagheader may be interpreted as a checksum. The problem is there's no one standard for how it should be generated. We'd have to find out how the maia.usno.navy.mil server is calculating it. If it is usable as a checksum, and we know how to compute it, then we can download only updates, merge, and then check that the resulting file matches theETag(which if we merge correctly it should). Otherwise the whole file will then need to be downloaded, but that would happen rarely, if ever.embray commentedon Jan 13, 2015
^ Alas no, it seems like the Apache settings they're using to generate the ETag header do not use the file contents at all. Oh well, that's okay.
taldcroft commentedon Nov 2, 2015
Essentially a duplicate of #3275.