Configuring the casacore ephemeris

Note that as part of the installation you (or your system administrator) will have installed the casacore “measures data”. This includes information essential to carrying out astronomical calculations, such as a list of leap seconds and a set of solar system ephemerides (which specify the positions of the planets at any given time). Data for the ephemerides are ultimately supplied by NASA JPL; they have been converted into a format that casacore can use. Any given ephemeris is only valid for a limited time (usually on the order of centuries), determined by the accuracy with which it was calculated.

By default, casacore will use the DE 200 ephemeris. Although the version of DE 200 supplied by JPL is valid until 2169, some versions converted for use with casacore are not, and may not provide coverage of the dates of your observation. A simple Python script can be used to check:

$ cat
import sys
from casacore.measures import measures
dm = measures()
dm.do_frame(dm.epoch('UTC', sys.argv[1]))
dm.separation(dm.direction('SUN'), dm.direction('SUN'))
$ python 1990/01/01
$ python 2015/01/01
WARN    MeasTable::Planetary(MeasTable::Types, Double)
  (file /build/buildd/casacore-1.7.0/measures/Measures/, line 4056)
  Cannot find the planetary data for MeasJPL object number 3 at UT day 57023 in
  table DE200

If no warning is printed, there is no problem; otherwise, you should use a different ephemeris. For example, the DE 405 ephemeris should be valid until at least early 2015:

$ cat > ~/.casarc
measures.jpl.ephemeris: DE405
$ python 2015/01/01
# No warnings

An alternative issue sometimes encountered is that of measures data which is simply outdated. Should you see an error along the lines of

SEVERE  gaincal::MeasTable::dUTC(Double) (file measures/Measures/, line 6307    Leap second table TAI_UTC seems out-of-date.
SEVERE  gaincal::MeasTable::dUTC(Double) (file measures/Measures/, line 6307)+  Until table is updated (see aips++ manager) times and coordinates
SEVERE  gaincal::MeasTable::dUTC(Double) (file measures/Measures/, line 6307)+  derived from UTC could be wrong by 1s or more

Then you might try to update your measures data via Rsync, as described in this NRAO helpdesk article