Repository navigation
Problem with IERS Bulletin table #356
Description
When doing the usual update with download_IERS_A it now throws a load of errors every time we import astroplan. Presumably something's wrong with the table it downloaded.
This is a real problem, given it breaks every script that imports astroplan (and by extension our whole TCS).
>>> import astroplan
Traceback (most recent call last):
File "/home/martin/.local/lib/python3.5/site-packages/astropy/io/ascii/core.py", line 957, in _convert_vals
converter_func, converter_type = col.converters[0]
IndexError: list index out of range
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/martin/.local/lib/python3.5/site-packages/astroplan/__init__.py", line 31, in <module>
get_IERS_A_or_workaround()
File "/home/martin/.local/lib/python3.5/site-packages/astroplan/utils.py", line 58, in get_IERS_A_or_workaround
iers.IERS.iers_table = _get_IERS_A_table()
File "/home/martin/.local/lib/python3.5/site-packages/astroplan/utils.py", line 92, in _get_IERS_A_table
table = iers.IERS_Auto.open()
File "/home/martin/.local/lib/python3.5/site-packages/astropy/utils/iers/iers.py", line 583, in open
cls.iers_table = cls.read(file=filename)
File "/home/martin/.local/lib/python3.5/site-packages/astropy/utils/iers/iers.py", line 452, in read
iers_a = Table.read(file, format='cds', readme=readme)
File "/home/martin/.local/lib/python3.5/site-packages/astropy/table/table.py", line 2519, in read
out = io_registry.read(cls, *args, **kwargs)
File "/home/martin/.local/lib/python3.5/site-packages/astropy/io/registry.py", line 531, in read
data = reader(*args, **kwargs)
File "/home/martin/.local/lib/python3.5/site-packages/astropy/io/ascii/connect.py", line 39, in io_read
return read(filename, format=format, **kwargs)
File "/home/martin/.local/lib/python3.5/site-packages/astropy/io/ascii/ui.py", line 353, in read
dat = reader.read(table)
File "/home/martin/.local/lib/python3.5/site-packages/astropy/io/ascii/cds.py", line 322, in read
return super(Cds, self).read(table)
File "/home/martin/.local/lib/python3.5/site-packages/astropy/io/ascii/core.py", line 1202, in read
table = self.outputter(cols, self.meta)
File "/home/martin/.local/lib/python3.5/site-packages/astropy/io/ascii/core.py", line 988, in __call__
self._convert_vals(cols)
File "/home/martin/.local/lib/python3.5/site-packages/astropy/io/ascii/core.py", line 973, in _convert_vals
raise ValueError('Column {} failed to convert: {}'.format(col.name, last_err))
ValueError: Column dX_2000A_A failed to convert: could not convert string to float: '9 521 586'
Activity
bmorris3 commentedon Apr 5, 2018
Perhaps some insight can be gained from astropy/astropy#5059. What happens if you download the table from a different mirror?
martinjohndyer commentedon Apr 5, 2018
Didn't work I'm afraid.
It looks like it might be a problem at the USNO end, see the bottom of http://maia.usno.navy.mil/ser7/finals2000A.all with missing data?
martinjohndyer commentedon Apr 5, 2018
Does the function keep backups of the old tables? If there's a problem it would be useful to be able to revert and just deal with the loss of accuracy.
martinjohndyer commentedon Apr 5, 2018
Looks like it might be something wrong with the table format, the number it reports an error on is the first not on a new line. Presumably because it's expecting the 'P' string.
martinjohndyer commentedon Apr 5, 2018
I can conform editing the file in the cache to add newlines fixed the problem. I know it's not expected to be an issue, but maybe a validity check on the table would be a good idea before just breaking everything.
bmorris3 commentedon Apr 7, 2018
@martinjohndyer – any chance this has resolved with newer table updates?
martinjohndyer commentedon Apr 9, 2018
@bmorris3 Yes it seems to be. Obviously just a problem with the table at the other end, though maybe astropy/astroplan should have some validation function to make the errors a little more obvious what's wrong.
bmorris3 commentedon Apr 9, 2018
@eteq / @bsipocz – is there any precedent for doing this elsewhere in astropy?
elendil-software commentedon Apr 26, 2018
Hi
I have the same problem. But I don't understand what to do to solve it.
Regards
lpsinger commentedon Jul 11, 2019
Why does astroplan keep a copy of the IERS data that is separate from the one managed by
astropy.utils.iers?wtgee commentedon Aug 18, 2019
@bmorris3 we're still struggling with this IERS table so I want to dedicate some time to trying to fix it. Following up on @lpsinger's comment, if we use an alternate url for download it still doesn't seem to place it in the cache properly. That is, I can do
and it will work fine, but if I then import any other module that uses astroplan I will still get a warning about it being out of date. I've looked at the source a little bit but there is some trickery going on with it trying to override things and I haven't had the time to fully dig through it. Any thoughts would be appreciated!
bmorris3 commentedon Aug 20, 2019
@wtgee I'm currently at the Extreme Solar Systems conference and will be able respond in detail to your question next week. Sorry for my delay 😄