# 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 check_ephemeris.py 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 check_ephemeris.py 1990/01/01
$python check_ephemeris.py 2015/01/01 WARN MeasTable::Planetary(MeasTable::Types, Double) (file /build/buildd/casacore-1.7.0/measures/Measures/MeasTable.cc, 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 check_ephemeris.py 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/MeasTable.cc, line 6307    Leap second table TAI_UTC seems out-of-date.
SEVERE  gaincal::MeasTable::dUTC(Double) (file measures/Measures/MeasTable.cc, line 6307)+  Until table is updated (see aips++ manager) times and coordinates
SEVERE  gaincal::MeasTable::dUTC(Double) (file measures/Measures/MeasTable.cc, 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