Closed bennahugo closed 4 years ago
@ianheywood this replicates the problem you noted for your installations please ensure to use https://pip.pypa.io/en/stable/reference/pip_install/#cmdoption-no-binary as workaround
Another workaround / solution is to edit ~/.casarc to point to the right location for the measures data.
My 2 💰...
I would say use the following data directories for the various wheels:
/usr/share/casacore/data
/usr/local/share/casacore/data
That's going to satisfy most of our users.
The only 100% clean solution would be a python-casacore Debian package / Homebrew formula that is guaranteed to work with the other parts of casacore in those distributions.
@tammojan, interesting! Could you point me to more info on the .casarc
file?
@tammojan, interesting! Could you point me to more info on the
.casarc
file?
Sure. I'm afraid the documentation is both too concise and way too verbose, but have a look at the docs. The key for setting a custom data directory is measures.directory: ~/opt/casacore/data/
(for example, where this directory should contain a subdirectory geodetic
).
ping on this issue. This also affects 3.2 wheels on a fresh installation. I've also seen binding issues against non-existing boost libraries.
File "/home/hugo/ddf3debug/DDFacet/DDFacet/Data/ClassJones.py", line 876, in GiveBeam
beam_times = self.BeamMachine.getBeamSampleTimes(times, quiet=quiet)
File "/home/hugo/ddf3debug/DDFacet/DDFacet/Data/ClassFITSBeam.py", line 195, in getBeamSampleTimes
dm.posangle(self.field_centre,self.zenith).get_value("deg") for t0 in beam_times ]
File "/home/hugo/ddf3debug/DDFacet/DDFacet/Data/ClassFITSBeam.py", line 195, in <listcomp>
dm.posangle(self.field_centre,self.zenith).get_value("deg") for t0 in beam_times ]
File "/home/hugo/ddf3debug/venv/lib/python3.5/site-packages/casacore/measures/__init__.py", line 945, in posangle
return _measures.posangle(self, m0, m1)
RuntimeError: 2020-01-14 06:59:07 SEVERE MeasTable::dUTC(Double) (file /build/casacore-3.2.0/measures/Measures/MeasTable.cc, line 4281) Cannot read leap second table TAI_UTC
Perhaps the solution is to rsync the NRAO data directly upon installation and do periodic rsyncs when the installation is out of date?
AstroPy syncs its measure data to ~/.astropy/cache
IIRC. That's another option.
The following will fix your installation, which is not broken, just not configured to find data:
echo 'measures.directory: /usr/share/casacore/data' > ~/.casarc
It may be good to compile casacore in KERN the binary wheel build to specify this data directory, i.e. build casacore with -D DATA_DIR=/usr/share/casacore/data
.
Hi.
Sorry for the delay. Here are the minimum steps to reproduce this on an ubuntu 18.04 system:
yields
I can confirm that forcing wheel-rebuilding fixes the problem (e.g when installing into /usr/local on the container). It may be better not to try bundle binary that depends on system libraries for wheels since there are 0 guarantees that the wheels are going to be installed on a ubuntu derivative.