Repository navigation
1.2RC1 - test failure in astropy/time/formats.py #5098
Description
___________________________________________ test_scale_conversion ____________________________________________
def test_scale_conversion():
if INTERNET_OFF:
# With internet off (which is the default for testing) then this will
# fall back to the bundled IERS-B table and raise an exception. But when
# testing with --remote-data the IERS_Auto class will get the latest IERS-A
# and this works.
with pytest.raises(ScaleValueError):
Time(Time.now().cxcsec, format='cxcsec', scale='ut1')
else:
> Time(Time.now().cxcsec, format='cxcsec', scale='ut1')
astropy/time/tests/test_basic.py:907:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
astropy/time/core.py:213: in __init__
precision, in_subfmt, out_subfmt)
astropy/time/core.py:263: in _init_from_vals
precision, in_subfmt, out_subfmt)
astropy/time/core.py:301: in _get_time_fmt
return FormatClass(val, val2, scale, precision, in_subfmt, out_subfmt)
astropy/time/formats.py:337: in __init__
in_subfmt, out_subfmt, from_jd)
astropy/time/formats.py:131: in __init__
self.set_jds(val1, val2)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = <astropy.time.formats.TimeCxcSec object at 0x7ff27a39f150>, val1 = array(582365171.0633501)
val2 = array(0.0)
def set_jds(self, val1, val2):
"""
Initialize the internal jd1 and jd2 attributes given val1 and val2.
For an TimeFromEpoch subclass like TimeUnix these will be floats giving
the effective seconds since an epoch time (e.g. 1970-01-01 00:00:00).
"""
# Form new JDs based on epoch time + time from epoch (converted to JD).
# One subtlety that might not be obvious is that 1.000 Julian days in
# UTC can be 86400 or 86401 seconds. For the TimeUnix format the
# assumption is that every day is exactly 86400 seconds, so this is, in
# principle, doing the math incorrectly, *except* that it matches the
# definition of Unix time which does not include leap seconds.
# note: use divisor=1./self.unit, since this is either 1 or 1/86400,
# and 1/86400 is not exactly representable as a float64, so multiplying
# by that will cause rounding errors. (But inverting it as a float64
# recovers the exact number)
day, frac = day_frac(val1, val2, divisor=1. / self.unit)
jd1 = self.epoch.jd1 + day
jd2 = self.epoch.jd2 + frac
# Create a temporary Time object corresponding to the new (jd1, jd2) in
# the epoch scale (e.g. UTC for TimeUnix) then convert that to the
# desired time scale for this object.
#
# A known limitation is that the transform from self.epoch_scale to
# self.scale cannot involve any metadata like lat or lon.
try:
tm = getattr(Time(jd1, jd2, scale=self.epoch_scale,
format='jd'), self.scale)
except Exception as err:
raise ScaleValueError("Cannot convert from '{0}' epoch scale '{1}'"
"to specified scale '{2}', got error:\n{3}"
.format(self.name, self.epoch_scale,
> self.scale, err))
E ScaleValueError: Cannot convert from 'cxcsec' epoch scale 'tt'to specified scale 'ut1', got error:
E (some) times are outside of range covered by IERS table.
astropy/time/formats.py:374: ScaleValueError
___________________________________________ test_scale_conversion ____________________________________________
def test_scale_conversion():
if INTERNET_OFF:
# With internet off (which is the default for testing) then this will
# fall back to the bundled IERS-B table and raise an exception. But when
# testing with --remote-data the IERS_Auto class will get the latest IERS-A
# and this works.
with pytest.raises(ScaleValueError):
Time(Time.now().cxcsec, format='cxcsec', scale='ut1')
else:
> Time(Time.now().cxcsec, format='cxcsec', scale='ut1')
astropy/time/tests/test_basic.py:907:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
astropy/time/core.py:213: in __init__
precision, in_subfmt, out_subfmt)
astropy/time/core.py:263: in _init_from_vals
precision, in_subfmt, out_subfmt)
astropy/time/core.py:301: in _get_time_fmt
return FormatClass(val, val2, scale, precision, in_subfmt, out_subfmt)
astropy/time/formats.py:337: in __init__
in_subfmt, out_subfmt, from_jd)
astropy/time/formats.py:131: in __init__
self.set_jds(val1, val2)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = <astropy.time.formats.TimeCxcSec object at 0x7ff2793c0510>, val1 = array(582365211.867949)
val2 = array(0.0)
def set_jds(self, val1, val2):
"""
Initialize the internal jd1 and jd2 attributes given val1 and val2.
For an TimeFromEpoch subclass like TimeUnix these will be floats giving
the effective seconds since an epoch time (e.g. 1970-01-01 00:00:00).
"""
# Form new JDs based on epoch time + time from epoch (converted to JD).
# One subtlety that might not be obvious is that 1.000 Julian days in
# UTC can be 86400 or 86401 seconds. For the TimeUnix format the
# assumption is that every day is exactly 86400 seconds, so this is, in
# principle, doing the math incorrectly, *except* that it matches the
# definition of Unix time which does not include leap seconds.
# note: use divisor=1./self.unit, since this is either 1 or 1/86400,
# and 1/86400 is not exactly representable as a float64, so multiplying
# by that will cause rounding errors. (But inverting it as a float64
# recovers the exact number)
day, frac = day_frac(val1, val2, divisor=1. / self.unit)
jd1 = self.epoch.jd1 + day
jd2 = self.epoch.jd2 + frac
# Create a temporary Time object corresponding to the new (jd1, jd2) in
# the epoch scale (e.g. UTC for TimeUnix) then convert that to the
# desired time scale for this object.
#
# A known limitation is that the transform from self.epoch_scale to
# self.scale cannot involve any metadata like lat or lon.
try:
tm = getattr(Time(jd1, jd2, scale=self.epoch_scale,
format='jd'), self.scale)
except Exception as err:
raise ScaleValueError("Cannot convert from '{0}' epoch scale '{1}'"
"to specified scale '{2}', got error:\n{3}"
.format(self.name, self.epoch_scale,
> self.scale, err))
E ScaleValueError: Cannot convert from 'cxcsec' epoch scale 'tt'to specified scale 'ut1', got error:
E (some) times are outside of range covered by IERS table.
astropy/time/formats.py:374: ScaleValueError
Activity
astrofrog commentedon Jun 15, 2016
@taldcroft - could you take a look at this and let us know if this is release-critical?
taldcroft commentedon Jun 15, 2016
@saimn - are you running tests with
--remote-data? What platform and package configuration?saimn commentedon Jun 15, 2016
@taldcroft - Same as #5099 (sorry again!)
https://gist.github.com/saimn/98e8ca025b9ac8d09a22e3ff71688598
taldcroft commentedon Jun 15, 2016
Somewhat grasping at straws... I will try running on CentOS-6 later today (but have to run right now). I think that in testing you should have a clean local cache, but just the same you did you entirely wipe your cache in
.astropy? I assume tests pass without remote data?saimn commentedon Jun 15, 2016
Yes, tests pass without remote data. And same failures after cleaning the cache.
taldcroft commentedon Jun 15, 2016
Hmm... tests pass on my CentOS-6 platform for Py2.7 and Py3.5.1, for remote and not remote data.
taldcroft commentedon Jun 15, 2016
Can you run
Time(Time.now().cxcsec, format='cxcsec', scale='ut1')from an IPython session with your 1.2rc1 installation?Another piece of diagnostic info is to run the failing test with
--pdband then:astrofrog commentedon Jun 15, 2016
Tried reproducing this, but I don't see this failure on CentOS 7
1 remaining item
saimn commentedon Jun 16, 2016
So first issue is that I get a timeout from http://maia.usno.navy.mil/ser7/finals2000A.all (I can download it but it takes longer than the 3 sec timout). And second issue is that
ie.iers_tableis None.saimn commentedon Jun 16, 2016
After looking a bit more in detail, all I can say is that I'm confused by the mix between inheritance (IERS_Auto/IERS_B/IERS), class methods and the iers_table class attribute ...
astrofrog commentedon Jun 16, 2016
Should we increase the timeout? 3 seconds seems pretty small
eteq commentedon Jun 16, 2016
@saimn - have you tried boosting the timeout? You can do this by doing something like
The perhaps non-obvious item here is that the timeout is 3 seconds to open the connection, not the amount of time to complete the download. So we don't want to make people wait too long because then their code will hang for a long time if they have the internet off or whatever (depending on their network setup...)
eteq commentedon Jun 16, 2016
That is, if setting that configuration item resolves @saimn's error, it might mean that we should just add a note to do that instead of hard-coding a special timeout just for IERS.
saimn commentedon Jun 17, 2016
@eteq - Increasing the timeout indeed does the job:
But there is still the issue of why the fallback is not working:
IERS_B_FILE(data/eopc04_IAU2000.62-now) is correctly read, but thenie.iers_tableis None (which is the root of the other failures, from @taldcroft 's comment ?).taldcroft commentedon Jun 17, 2016
This is all quite confusing indeed even to me.... I realize that you should not be looking at the
ie.iers_tableattribute at all, but instead justie. The former is just the cached version and is allowed to beNone, and probably should have been a private attribute all along. Sorry for the misdirection.The problem with
iers_tablebeing None is a latent issue in the original code:In your case this could be fixed by having the Auto class fall through to loading via the
IERS_Bclass directly instead ofIERS. I think this is a corner case that can wait.I would say that the suggested documentation update would be the right thing right now. I probably won't have time to do this today because of other commitments.
In order to make the changes for auto-downloading be back-compatible, it is layered on top of the existing IERS / IERS_A / IERS_B infrastructure. As mentioned this module is pretty confusing. Hopefully most users and devs just won't have to deal with it going forward, or else we need to consider a bigger re-write in the future.
taldcroft commentedon Jun 17, 2016
The experience of @saimn does make me wonder if it would be worth increasing the timeout for IERS download to maybe 5 or 10 seconds so we have fewer of these issues pop up in the wild.
astrofrog commentedon Jun 17, 2016
👍 - 3 seconds is low
taldcroft commentedon Jun 17, 2016
See #5111.
saimn commentedon Jun 17, 2016
Increasing the timeout for this file seems a good solution. 👍
saimn commentedon Jun 17, 2016
Also, I will not be able to test this before Monday, here at home I don't have the timeout issue ...
eteq commentedon Jun 18, 2016
@saimn - no worries - whenever you get a chance please give it a shot, and if it's now working post-#5111, go ahead and close this.
saimn commentedon Jun 20, 2016
Fixed with #5111 !