This document describes the proprietary
programmer's interface to the Swiss Ephemeris DLL.

Swiss Ephemeris is made available by its
authors under a dual licensing system.
The software developer, who uses any part of Swiss Ephemeris in his or her software, must choose between
one of the two license models, which
are

a)
GNU public license version 2 or later

b)
Swiss Ephemeris Professional License

The choice must be made before the software
developer distributes software
containing parts of Swiss Ephemeris to others, and before any public
service using the developed software is activated.

If the developer chooses the GNU GPL
software license, he or she must fulfill the conditions of that license, which
includes the obligation to place his or her whole software project under the
GNU GPL or a compatible license. See
http://www.gnu.org/licenses/old-licenses/gpl-2.0.html

If the developer chooses the Swiss
Ephemeris Professional license, he must follow the instructions as found in
http://www.astro.com/swisseph/ and purchase the Swiss Ephemeris Professional
Edition from Astrodienst and sign the corresponding license contract.

swe_calc_ut()
and swe_calc() work exactly
the same way except that swe_calc() requires Ephemeris
Time( more
accurate: Dynamical Time ) as a parameter whereas swe_calc_ut() expects Universal Time. For common astrological calculations, you will only need swe_calc_ut() and will not have to think
anymore about the conversion between Universal Time and Ephemeris Time.

swe_calc_ut()
and swe_calc() compute
positions of planets, asteroids, lunar nodes and apogees. They are defined as
follows:

On success, swe_calc ( or swe_calc_ut)returns a 32-bit integer containing flag bits that indicate
what kind of computation has been done. This value may or may not be equal toiflag. If an option specified byiflag cannot be fulfilled or makes no sense, swe_calc just does what can be done. E.g., if you specify that you want JPL
ephemeris, butswe_calccannot find the ephemeris file, it
tries to do the computation with any available ephemeris. This will be
indicated in the return value of swe_calc. So, to make sure that swe_calc () did exactly what you had wanted, you may want to check whether or
not the return code == iflag.

However, swe_calc() might return an fatal error code (< 0) and an error string in one of
the following cases:

The larger file is about 10 times the
size of the short ephemeris. If the user does not want an ephemeris for the
time before 1500 he might prefer to work with the short files. If so, just copy
the files ending with ”s.se1” to your hard
disk. Swe_calc()tries the long one and on failure
automatically takes the short one.

Asteroid ephemerides are looked for in the
subdirectories ast0, ast1, ast2 .. ast9 etc of the
ephemeris directory and, if not found there, in the ephemeris directory itself.
Asteroids with numbers 0 – 999 are expected in directory ast0, those with numbers 1000 – 1999 in directory ast1 etc.

Note that not all asteroids can be computed for the whole period of Swiss Ephemeris. The
orbits of some of them are extremely sensitive to
perturbations by major planets. E.g. CHIRON,
cannot be computed for the time before 650 AD and after 4650 AD
because of close encounters with Saturn. Outside this time range, Swiss
Ephemeris returns the error code, an error message, and a position value 0. Be
aware, that the user will have to handlethis case in his
program. Computing Chiron transits for Jesus or Alexander the Great will not work.

The same is
true for Pholus before 3850 BC, and for many other asteroids, as e.g.
1862 Apollo. He becomes chaotic before the year 1870 AD, when he
approaches Venus very closely. Swiss Ephemeris does not provide positions of
Apollo for earlier centuries !

Note on asteroid names

Asteroid names are listed in the
file seasnam.txt. This file is in the ephemeris directory.

Fictitious planets have numbers greater
than or equal to 40. The user can define his or her own fictitious planets. The
orbital elements of these planets must be written into the file seorbel.txt. The function swe_calc()looks for the file seorbel.txt in the
ephemeris path set by swe_set_ephe_path().
If no orbital elements file is found, swe_calc()uses the built-in orbital elements of the above mentioned Uranian planets and
some other bodies. The planet number of a fictitious planet is defined as

(See, e.g.,
Vulcan, the second last elements set (not the ”Uranian” Vulcanus but the
intramercurian hypothetical planet Vulcan).) ”T * T”, ”T2”, ”T3” are also
allowed.

The equinox can
either be entered as a Julian day or as ”J1900” or ”B1950” or ”J2000” or, if
the equinox of date is required, as ”JDATE”. If you use T terms, note that
precession has to be taken into account with JDATE, whereas it has to be
neglected with fixed equinoxes.

No T term is
required with the mean anomaly, i.e. for the speed of the body, because our
software can compute it from semi-axis and gravity. However, a mean anomaly T
term had to be added with Vulcan because its speed is not in agreement with the
laws of physics. In such cases, the software takes the speed given in the
elements and does not compute it internally.

From Version 1.62
on, the software also accepts orbital elements for fictitious bodies that move
about the earth. As an example, study the last elements set in the excerpt of
seorbel.txt above. After the name of the body, ”, geo” has to be added.

A special body
number SE_ECL_NUT is provided to compute the obliquity of the ecliptic and
the nutation. Of course nutation is already added internally to the planetary
coordinates by swe_calc() but sometimes it will be
needed as a separate value.

If no bits are set, i.e. if iflag == 0, swe_calc() computes what common astrological ephemerides (as available in book
shops) supply, i.e. an apparent body position in geocentric ecliptic
polar coordinates ( longitude, latitude, and distance) relative to the trueequinox of the date.

If the speed of the body is
required, set iflag = SEFLG_SPEED

For mathematical points as the mean
lunar node and the mean apogee, there is no apparent position. Swe_calc()returns true positions for these points.

If you need another kind of
computation, use the flags explained in the following paragraphs (c.f. swephexp.h). Their names begin with ‚SEFLG_‘. To
combine them, you have to concatenate them (inclusive-or) as in the following
example:

If none of this flags is specified, swe_calc() tries to compute the default ephemeris. The default ephemeris is
defined in
swephexp.h:

#define
SEFLG_DEFAULTEPH SEFLG_SWIEPH

In this case the default ephemeris
is Swiss Ephemeris. If you have not specified an
ephemeris iniflag, swe_calc() tries to compute a Swiss Ephemeris position. If it does not find
the required Swiss Ephemeris file either, it computes a Moshier position.

Common ephemerides supply apparent geocentric positions. Since the journey of
the light from a planet to the earth takes some time, the planets are never
seen where they actually are, but where they were a few minutes or hours
before. Astrology uses to work with the positions we see. ( More
precisely: with the positions we would see, if we stood at the center of the
earth and could see the sky. Actually, the geographical position of the
observer could be of importance as well and topocentric positionscould be
computed, but this is usually not taken into account in astrology.). The
geocentric position for the earth (SE_EARTH) is returned as zero.

SEFLG_BARYCTR yields coordinates as
referred to the solar system barycenter. However, this option is not completely
implemented. It was used for program
tests during development. It works only
with the JPL and the Swiss Ephemeris, not with the Moshier ephemeris;
and only with physical bodies, but not with the nodes and the apogees.

Moreover, the barycentric Sun of
Swiss Ephemeris has ”only” a precision of 0.1”. Higher accuracy would have
taken a lot of storage, on the other hand it is not needed for precise
geocentric and heliocentric positions. For more precise barycentric positions
the JPL ephemeris file should be used.

A barycentric position can be
computed for
all planets including the sun and moon. For the
lunar nodes and lunar apogees the coordinates are returned as zero; no error
message appears.

For astrometric positions, which are
sometimes given in the Astronomical Almanac, the light-time correction is
computed, but annual aberration and the light-deflection by the sun neglected.
This can be done with SEFLG_NOABERR and SEFLG_NOGDEFL. For positions related to
the mean equinox of 2000, you must set SEFLG_J2000 and SEFLG_NONUT, as well.

Swe_calc() usually computes the
positions as referred to the equinox of date. SEFLG_J2000 yields data referred
to the equinox J2000. For positions referred to other equinoxes, SEFLG_SIDEREAL
has to be set and the equinox specified by swe_set_sid_mode(). For more information, read the description of this function.

For
apparent positions of the planets, JPL Horizons follows a different approach
from Astronomical Almanac and from the IERS Conventions 2003 and 2010. It uses the old precession models IAU 1976 (Lieske) and nutation IAU
1980 (Wahr) and corrects the resulting positions by adding daily-measured
celestial pole offsets (delta_psi and delta_epsilon) to nutation. (IERS
Conventions 1996, p. 22) While this approach is more accurate in some respect,
it is not referred to the same reference frame. For more details see the
general documentation of the Swiss Ephemeris in swisseph.doc or http://www.astro.com/swisseph/swisseph.htm
, ch. 2.1.2.2.

Apparent positions of JPL Horizons
can be reproduced with about 0.001 arcsec precision using the flag
SEFLG_JPLHOR. For best accuracy, the daily earth orientation parameters (EOP)
delta_psi and delta_eps relative to the IAU 1980 precession/nutation model must
be downloaded and saved in the ephemeris path defined by swe_set_ephe_path().
The EOP files are found on the IERS website:

Once you have computed a planet,
e.g., in ecliptic coordinates, its equatorial position or its rectangular
coordinates are available, too. You can
get them very cheaply ( little CPU time used ), calling again swe_calc()with the same parameters, but adding
SEFLG_EQUATORIAL or SEFLG_XYZ to iflag.
swe_calc() will not compute the body again, just
return the data specified from internal storage.

·Because many asteroids, especially the
ones with high catalogue numbers, have no names yet (or have only a preliminary
designation like 1968 HB), and because the Minor Planet Center of the IAU add
new names quite often, it happens that there is no name in the asteroid file
although the asteroid has already been given a name. For this, we have the file
seasnam.txt, a file that contains a list of all named asteroid and is usually
more up to date. If swe_calc() finds a preliminary
designation, it looks for a name in this file.

The function swe_fixstar_ut() was introduced with Swisseph version 1.60. It does exactly
the same as swe_fixstar() except that it expects Universal Time rather than Ephemeris time as
an input value. (cf. swe_calc_ut() and swe_calc())

The functions swe_fixstar_ut() and swe_fixstar()computes fixed stars. They are defined as follows:

The
parameter star must provide for at least 41 characters for the returned star name.
If a star is found, its name is returned in this field in the following format:traditional_name,
nomenclature_namee.g. "Aldebaran,alTau".

·star
contains a positive number ( in ASCII string format, e.g. "234"): The 234-th non-comment line in the file
fixstars.cat is used. Comment lines begin with # and are ignored.

·starcontains a traditional name: the first star in the file fixstars.cat is used whose traditional name fits the given name. All names are
mapped to lower case before comparison. If star has n
characters, only the first n characters of the traditional name field are compared. If a comma
appears after a non-zero-length traditional name, the traditional name is cut
off at the comma before the search. This allows the reuse of the returned star
name from a previous call in the next call.

·starbegins with a comma, followed by a nomenclature name, e.g. ",alTau": the star with this name in the
nomenclature field ( the second field ) is returned. Letter case is observed in
the comparison for nomenclature names.

For correct spelling of nomenclature
names, see file fixstars.cat. Nomenclature names are
usually composed of a Greek letter and the name of a star constellation. The
Greek letters were originally used to write numbers, therefore to number the
stars of the constellation. The abbreviated nomenclature names we use in fixstars.cat are constructed from two lowercase letters for the Greek letter
(e.g. ”al” for ”alpha”) and three letters for the
constellation (e.g. ”Tau” for ”Tauri”).

The function and the DLL should survive
damaged fixstars.cat files which contain illegal data and star names exceeding the
accepted length. Such fields are cut to acceptable length.

There are two special entries in the file
fixstars.cat:

·an entry for the Galactic Center,
named "Gal.
Center" with one blank.

·a star named "AA_page_B40" which is the star calculation sample of Astronomical Almanac (our bible of the last two years), page B40.

You may edit the star catalogue and
move the stars you prefer to the top of the file. This will increase the speed
of your computations. The search mode is linear through the whole star file for
each call of swe_fixstar().

As for the explanation of the other
parameters, see swe_calc().

Barycentric positions are not
implemented. The difference between geocentric and heliocentric fix star
position is noticeable and arises from parallax and gravitational deflection.

Attention:swe_fixstar()does
not compute speedsof the fixed stars. If you need them,
you have to compute them on your own, calling swe_fixstar()for a second ( and third ) time.

The functions swe_nod_aps_ut() and swe_nod_aps() compute planetary nodes and apsides ( perihelia, aphelia, second focal
points of the orbital ellipses ). Both functions do exactly the same except
that they expect a different time parameter (cf. swe_calc_ut() and swe_calc() ).

The parameter iflag allows the same specifications as with the function swe_calc_ut(). I.e., it contains the Ephemeris flag, the heliocentric,
topocentric, speed, nutation flags etc. etc.

The parameter method
tells the function what kind of nodes or apsides are required:

#define SE_NODBIT_MEAN 1

This is also the default. Mean nodes
and apsides are calculated for the bodies that have them, i.e. for the Moon and
the planets Mercury through Neptune, osculating ones for Pluto and the
asteroids.

#define
SE_NODBIT_OSCU 2

Osculating nodes and apsides are
calculated for all bodies.

#define
SE_NODBIT_OSCU_BAR 4

Osculating nodes and apsides are
calculated for all bodies. With planets beyond Jupiter, they are computed from
a barycentric ellipse. Cf. the explanations in swisseph.doc.

If this bit is combined with
SE_NODBIT_MEAN, mean values are given for the planets Mercury - Neptun.

#define
SE_NODBIT_FOPOINT 256

The second focal point of the
orbital ellipse is computed and returned in the array of the aphelion. This bit
can be combined with any other bit.

It is not meaningful to compute mean
oribital elements topocentrically. The concept of mean elements precludes
consideration of any short term fluctuations in coordinates.6. Eclipse and
planetary phenomena functions

Find
the next total eclipse, calculate the geographical position where it is maximal
and the four contacts for that position (for a detailed explanation of all
eclipse functions see the next chapters):

This function requires the time
parameter tjd_start in Universal Time and also yields the
return values (tret[]) in UT. For conversions between ET and UT, use the
function swe_deltat().

Note: An implementation of this
function with parameters in Ephemeris Time would have been possible. The
question when the next solar eclipse will happen anywhere on earth is
independent of the rotational position of the earth and therefore independent
of Delta T. However, the function is often used in combination with other
eclipse functions (see example below), for which input and output in ET makes
no sense, because they concern local circumstances of an eclipse and therefore are dependent on the rotational position
of the earth. For this reason, UT has been chosen for the time parameters of
all eclipse functions.

ifltype specifies the eclipse type
wanted. It can be a combination of the following bits (see swephexp.h):

#define SE_ECL_CENTRAL 1

#define SE_ECL_NONCENTRAL 2

#define SE_ECL_TOTAL 4

#define SE_ECL_ANNULAR 8

#define SE_ECL_PARTIAL 16

#define SE_ECL_ANNULAR_TOTAL 32

Recommended
values for ifltype:

/* search for any eclipse, no matter which type */

ifltype =
0;

/* search
a total eclipse; note: non-central total eclipses are very rare */

ifltype =
SE_ECL_TOTAL ¦ SE_ECL_CENTRAL ¦ SE_ECL_NONCENTRAL;

/* search
an annular eclipse */

ifltype =
SE_ECL_ANNULAR ¦ SE_ECL_CENTRAL ¦ SE_ECL_NONCENTRAL;

/* search
an annular-total (hybrid) eclipse */

ifltype_ =
SE_ECL_ANNULAR_TOTAL ¦ SE_ECL_CENTRAL ¦ SE_ECL_NONCENTRAL;

/* search
a partial eclipse */

ifltype =
SE_ECL_PARTIAL;

If your code
does not work, please study the sample code in swetest.c.

If you want to draw the eclipse path of a total or annular eclipse on
a map, first compute the start and end time of the total or annular phase with swe_sol_eclipse_when_glob(), then call swe_sol_eclipse_how() for several
time intervals to get geographic positions on the central path. The northern
and southern limits of the umbra and penumbra are
not implemented yet.

Occultations of some stars may be very rare
or do not occur at all. Usually the function searches an event until it finds
one or reaches the end of the ephemeris. In order to avoid endless loops, the
function can be called using the flag ifl |= SE_ECL_ONE_TRY. If called with this flag, the function
searches the next date when the Moon is in conjunction with the object and
finds out whether it is an occultation. The function does not check any other
conjunctions in the future or past.

If the return value is > 0, there is an
occulation and tret and attr contain the information about it.

If the return value is = 0, there is no
occulation; tret[0] contains the date of closest conjunction.

If the return value is = -1, there is an
error.

In order to find events in a particular
time range (tjd_start < tjd < tjd_stop), one can write a loop and call
the function as often as date (tjd < tjd_stop). After each call, increase the tjd = tret[0] + 2.

If one has a set of stars or planets for
which one wants to find occultations for the same time range, one has to run
the same loop for each of these object. If the events have to be listed in
chronological order, one has to sort them before output.

The function returns:

/* retflag

-1 (ERR) on error (e.g. if swe_calc()
for sun or moon fails)

0
(if no occultation/no eclipse found)

SE_ECL_TOTAL or SE_ECL_ANNULAR or
SE_ECL_PARTIAL

SE_ECL_VISIBLE,

SE_ECL_MAX_VISIBLE,

SE_ECL_1ST_VISIBLE, SE_ECL_2ND_VISIBLE

SE_ECL_3ST_VISIBLE, SE_ECL_4ND_VISIBLE

These return values (except the
SE_ECL_ANNULAR) also appear with occultations.

tret[0] time
of maximum eclipse

tret[1] time
of first contact

tret[2] time
of second contact

tret[3] time
of third contact

tret[4] time
of forth contact

tret[5] time
of sunrise between first and forth contact (not implemented so far)

tret[6] time
of sunset beween first and forth contact
(not implemented so far)

Similar to swe_sol_eclipse_where(),
this function can be used to find out the geographic position, where, for a
given time, a central eclipse is central or where a non-central eclipse is
maximal. With occultations, it tells us, at which geographic location the
occulted body is in the middle of the lunar disc or closest to it. Because
occultations are always visible from a very large area, this is not very
interesting information. But it may

become more interesting as soon as
the limits of the umbra (and penumbra) will be implemented.

The function swe_rise_trans()
computes the times of rising, setting and meridian
transits for all planets, asteroids, the moon, and the fixed stars. The
function swe_rise_trans_true_hor() does the same for a local horizon that has
an altitude != 0.

The functions returns a rising of an
object,

- if at t0 the object is below the
horizon and a rising takes place before the next culmination of the object

- if at t0 the object is above the horizon
and a rising takes place between the next lower and upper culminations of the
object.

And it returns a setting of an
object,

- if at t0 the object is above the
horizon and a setting takes place before the next lower culmination of the
object

- if at t0 the object is below the
horizon and a setting takes place between the next upper and lower
culminations.

Note, “culmination” does not mean meridian
transit, especially not with the Sun, Moon, and planets. The culmination of a
moving body with changing declination does not take place exactly on the
meridian but shortly before or after the meridian transit. In polar regions, it
even happens that the moon "rises" shortly after the culmination, on
the west side of the meridian. I. e., the upper limb if its disk will become
visible for a short time. The function swe_rise_trans() should catch these
cases.

The function swe_azalt_rev()is not precisely the reverse of swe_azalt(). It computes either ecliptical or equatorial coordinates from
azimuth and true altitude. If only an apparent altitude is given, the true
altitude has to be computed first with the function swe_refrac() (see below).

The refraction depends on the
atmospheric pressure and temperature at the location of the observer.

If atpress is given the value 0, the function estimates the pressure from the
geographical altitude given in geopos[2] and attemp. If geopos[2] is 0, atpress will be estimated for sea level.

There is also a more sophisticated
function swe_refrac_extended(), It allows correct
calculation of refraction for altitudes above sea > 0, where the ideal
horizon and planets that are visible may have a negative height. (for
swe_refrac(), negative apparent heights do not exist!)

- With good visibility and good eye
sight (high Snellen ratio), the “evening first” of the Moon may actually begin
in the morning, because the Moon becomes visible before sunset. Note the LMT
and duration of visibility in the following example:

- Stars that are circumpolar, but
come close to the horizon, may have an evening last and a morning first, but
swe_heliacal_ut() will not find it. It only works if a star crosses the
horizon.

- In high geographic latitudes > 55
(?), unusual things may happen. E.g. Mars can have a morning last appearance.
In case the period of visibility lasts for less than 5 days, the function
swe_heliacal_ut() may miss the morning first.

- With high geographic latitudes
heliacal appearances of Mercury and Venus become rarer.

The user must be aware that strange
phenomena occur especially for high geographic latitudes and circumpolar
objects and that the function swe_heliacal_ut() may not always be able to
handle them correctly. Special cases can best be researched using the function
swe_vi_limit_mag().

The function swe_vis_lim_mag()determines the limiting visual magnitude
in dark skies. If the visual magnitude mag of an object is known for a given
date (e. g. from a call of function swe_pheno_ut(), and if mag is smaller than
the value returned by swe_vis_limt_mag(), then it is visible.

The Julian
day number has nothing to do with Julius Cesar, who introduced the Julian
calendar, but was invented by the monk Julianus. The Julian day number tells
for a given date the number of days that have passed since the creation of the
world which was then considered to have happened on 1 Jan –4712 at noon. E.g.
the 1.1.1900 corresponds to the Julian day number 2415020.5.

Midnight has always a JD with
fraction 0.5, because traditionally the
astronomical day started at noon. This was practical because then there was no
change of date during a night at the telescope. From this comes also the fact that noon ephemerides were printed
before midnight ephemerides were introduced early in the 20th century.

The following functions, which were
introduced with Swiss Ephemeris version 1.76, do a similar job as the functions
described under 7.1. The difference is that input and output times are
Coordinated Universal Time (UTC). For transformations between wall clock (or
arm wrist) time and Julian Day numbers, these functions are more correct. The
difference is below 1 second, though.

Use these functions to convert

-local time to UTC and UTC to local
time,

-UTC to a Julian day number, and

-a Julian day number to UTC.

Note, in case of leap seconds, the input
or output time may be 60.9999 seconds. Input or output forms have to allow for
this.

/* transform local time to UTC or UTC to
local time

*

*
input:

* iyear ... dsec date and time

* d_timezone timezone offset

*
output:

* iyear_out ... dsec_out

*

*
For time zones east of Greenwich, d_timezone is positive.

*
For time zones west of Greenwich, d_timezone is negative.

*

*
For conversion from local time to utc, use +d_timezone.

*
For conversion from utc to local time, use -d_timezone.

*/

void FAR PASCAL_CONV swe_ utc_time_zone(

int32 iyear, int32 imonth, int32 iday,

int32 ihour, int32
imin, double dsec,

double d_timezone,

int32
*iyear_out, int32 *imonth_out, int32 *iday_out,

int32 *ihour_out, int32 *imin_out, double *dsec_out

)

/* input: date and time (wall clock time),
calendar flag.

*
output: an array of doubles with Julian Day number in ET (TT) and UT (UT1)

And how do you get the date and wall
clock time from a Julian day number? Depending on whether you have tjd_et
(Julian day as ET (TT)) or tjd_ut (Julian day as UT (UT1)), use one of the two
functions swe_jdet_to_utc() or swe_jdut1_to_utc().

The insertion of leap seconds is not
known in advance. We will update the Swiss Ephemeris whenever the IERS
announces that a leap second will be inserted. However, if the user does not
want to wait for our update or does not want to download a new version of the
Swiss Ephemeris, he can create a file swe_leapsec.txt in the ephemeris
directory. Insert a line with the date on which a leap second has to be
inserted. The file looks as follows:

# This file contains the dates of leap
seconds to be taken into account

# by the Swiss Ephemeris.

# For each new leap second add the date of
its insertion in the format

Universal Time (UT or UTC) is based on Mean Solar Time, AKA
Local
Mean Time, which is a uniform measure of time. A
day has always the same length, independent of the time of the year.

In the centuries before mechanical
clocks where used, when the reckoning of time was mostly based on sun dials,
the True
Solar Time was used, also called Local Apparent Time.

The difference between Local Mean Time and Local Apparent Time is called the equation of time. This difference can become as
large as 20 minutes.

If a historical date was noted in Local Apparent Time, it must first be converted to Local Mean Time by applying the equation of time, before it can be used to compute
Universal Time (for the houses) and finally Ephemeris Time (for the planets).

This conversion can be done using
the function swe_lat_to_lmt(). The reverse function is swe_lmt_to_lat(). If
required, the equation of time itself, i. e. the value e = LAT – LMT, can be
calculated using the function swe_time_equ()

/* Equation of Time

*

*
The function returns the difference between local apparent and local mean time
in days.

The Julian day number, you compute
from a birth date, will be Universal Time (UT, former GMT) and can be used to
compute the star time and the houses. However, for the planets and the other
factors, you have to convert UT to Ephemeris time (ET):

For precision fanatics: The value of
delta t depends on the tidal acceleration in the motion of the moon. Its
default value corresponds to the state-of-the-art JPL ephemeris (e.g. DE406, s. swephexp.h). If you use another JPL ephemeris, e.g. DE200, you may wish the tidal constant of DE200. This makes a
difference of 0.5 time seconds in 1900 and 4 seconds in 1800 (= 0.2” in the
position of the sun). However, this effect is limited to the period 1620 -
~1997. To change the tidal acceleration, use the function

Delta T
values for future years can only be estimated. Strictly speaking, the Swiss
Ephemeris has to be updated every year after the new Delta T value for the past
year has been published by the IERS. We will do our best and hope to update the
Swiss Ephemeris every year. However, if the user does not want to wait for our
update or does not download a new version of the Swiss Ephemeris he can add new
Delta T values in the file swe_deltat.txt, which has to be located in the Swiss
Ephemeris ephemeris path.

# This file allows make new Delta T known
to the Swiss Ephemeris.

# Note, these values override the values
given in the internal Delta T

This function must be called before topocentric planet positions for a certain birth place
can be computed. It tells Swiss Ephemeris, what geographic position is to be
used. Geographic longitude geolon and latitude geolat must be in degrees, the altitude above sea must be in meters. Neglecting
the altitude can result in an error of about 2 arc seconds with the moon and at an altitude 3000 m. After calling swe_set_topo(), add SEFLG_TOPOCTR toiflag and call swe_calc() as with
an ordinary computation. E.g.:

The function swe_get_ayanamsa_ut() was introduced with Swisseph Version 1.60 and expects Universal
Time instead of Ephemeris Time. (cf. swe_calc_ut() and swe_calc())

The two functions compute the ayanamsha, i.e. the distance of the tropical vernal point from the sidereal
zero point of the zodiac. Theayanamsha is used to compute sidereal planetary positions from tropical ones:

pos_sid =
pos_trop – ayanamsha

Before calling swe_get_ayanamsha(), you have to set the sidereal mode with swe_set_sid_mode, unless you want the
default sidereal mode, which is the Fagan/Bradleyayanamsha.

If the environment variable
SE_EPHE_PATH exists in the environment
where Swiss Ephemeris is used, its content is used to find the ephemeris files. The variable can contain a directory
name, or a list of directory names separated by ; (semicolon) on Windows or : (colon) on Unix.

If the path is longer than 256 bytes, swe_set_ephe_path() sets the path \SWEPH\EPHE instead.

If no environment variable exists
and swe_set_ephe_path() is never called, the built-in ephemeris path is used. On Windows it
is ”\sweph\ephe” relative to the current working drive, on Unix it is "/users/ephe".

Asteroid ephemerides are looked for
in the subdirectories ast0, ast1, ast2 .. ast9 of the ephemeris directory and, if not found there, in the ephemeris
directory itself. Asteroids with numbers 0 – 999 are expected in directory ast0, those with numbers 1000 – 1999 in directory ast1 etc.

The environment variable SE_EPHE_PATH is most convenient when a user has several applications installed
which all use the Swiss Ephemeris but would normally expect the ephemeris files
in different application-specific directories. The use can override this by
setting the environment variable, which forces all the different applications
to use the same ephemeris directory. This allows him to use only one set of
installed ephemeris files for all different applications. A developer should
accept this override feature and allow the sophisticated users to exploit it.

If you work with the JPL ephemeris,
SwissEph uses the default file name which is defined in swephexp.h as SE_FNAME_DFT. Currently, it has the value ”de406.eph” or
”de431.eph”.

If a different JPL ephemeris file is
required, call the function swe_set_jpl_file()to make the file name known to the software, e.g.

swe_set_jpl_file(”de405.eph”);

This file must reside in the
ephemeris path you are using for all your ephemeris files.

If the file name is longer than 256 byte, swe_set_jpl_file() cuts the file name to a length of 256 bytes. The error will become
visible after the first call of swe_calc(), when it
will return zero positions and an error message.

int
hsys, /* house method, ascii code of one of the letters PKORCAEVXHTBG
*/

);

The function swe_houses() is most comfortable, if you need the houses for a given date and
geographic position. Sometimes, however, you will want to compute houses from
an ARMC, e.g. with the composite horoscope which has no date, only the
composite ARMC of two natal ARMCs. In such cases, you can use the function swe_houses_armc(). To compute the composite ecliptic
obliquityeps, you will have to call sweph_calc()with ipl = SE_ECL_NUT
for both birth dates and calculate the average of botheps.

Note thattjd_ut must be Universal Time, whereas planets are
computed from Ephemeris Time

tjd_et
= tjd_ut + delta_t(tjd_ut).

Also note that the array cusps
must provide space for 13 doubles (declare
as cusp[13]), otherwise you risk a
program crash. With house system ‘G’ (Gauquelin sector cusps), declare it as cusp[37].

Note: With house system ‘G’, the
cusp numbering is in clockwise direction.

The extended house function swe_houses_ex() does exactly the same calculations as swe_houses().
The difference is that swe_houses_ex() has
a parameter iflag, which can
be set to SEFLG_SIDEREAL, if siderealhouse
positions are wanted. Before calling swe_houses_ex() for
sidereal house positions, the sidereal mode can be set by calling the function swe_set_sid_mode(). If this is not done, the default sidereal mode, i.e. the
Fagan/Bradley ayanamsha, will be used.

There is a disagreement between American and European
programmers whether eastern or western geographical longitudes ought to be
considered positive. Americans prefer to have West longitudes positive,
Europeans prefer the older tradition that considers East longitudes as positive
and West longitudes as negative.

The Astronomical Almanac still follows the European pattern. It gives the geographical
coordinates of observatories in "East longitude".

The Swiss Ephemeris also follows the
European
style. All Swiss Ephemeris functions that use
geographical coordinates consider positive geographical longitudes as Eastand negative ones as West.

The variables armc,
geolat, eps, and xpin[0]and xpin[1](ecliptic longitude and latitude of the
planet) must be in degrees. serr must, as usually, point to a character array of 256 byte.

The function returns a value between
1.0 and 12.999999, indicating in which house a planet is and how far from its
cusp it is.

With house system ‘G’ (Gauquelin
sectors), a value between 1.0 and 36.9999999 is returned. Note that, while all
other house systems number house cusps in counterclockwise direction, Gauquelin
sectors are numbered in clockwise direction.

With Koch houses, the function sometimes returns 0, if the computation was not possible. This happens most often in polar regions, but it can happen at latitudes below
66°33’ as well, e.g. if a body has a high declination and falls
within the circumpolar sky. With circumpolar fixed stars (or asteroids) a Koch
house position may be impossible at any geographic location except on the
equator.

The user must decide how to deal
with this situation.

You can use the house positions
returned by this function for house horoscopes (or ”mundane” positions). For
this, you have to transform it into a value between 0 and 360 degrees. Subtract
1 from the house number and multiply it with 30, or mund_pos = (hpos – 1) *
30;

You will realize that house
positions computed like this, e.g. for the Koch houses, will not agree exactly
with the ones that you get applying the Huber ”hand calculation” method. If you
want a better agreement, set the ecliptic latitude xpin[1]= 0;. Remaining differences result from the
fact that Huber’s hand calculation is a simplification, whereas our computation
is geometrically accurate.

This function requires TROPICAL positions inxpin. SIDEREAL house positions are identical to tropical ones in the following
cases:

·If the traditional method is used to
compute sidereal planets (sid_pos = trop_pos – ayanamsha). Here the function swe_house_pos() works
for all house systems.

·If a non-traditional method
(projection to the ecliptic of t0 or to the solar system rotation plane) is
used and the definition of the house system does not depend on the ecliptic.
This is the case with Campanus, Regiomontanus, Placidus, Azimuth houses, axial rotation houses. This is NOT
the case with equal houses, Porphyry and Koch houses.
You have to compute equal and Porphyry house positions on your own. We recommend to avoid Koch
houses here. Sidereal Koch houses make no sense with these sidereal algorithms.

For general information on Gauquelin
sectors, read chapter 6.5 in documentation file swisseph.doc.

There are two functions that can be
used to calculate Gauquelin sectors:

·swe_house_pos. Full details about this
function are presented in the previous section. To calculate Gauquelin sectors
the parameter hsys must be set to 'G' (Gauquelin sectors). This function will
then return the sector position as a value between 1.0 and 36.9999999. Note
that Gauquelin sectors are numbered in clockwise direction, unlike all other
house systems.

This function returns OK or ERR
(-1). It returns an error in a number of cases, for example circumpolar bodies
with imeth=2. As with other SE functions, if there is an error, an error
message is written to serr. dgsect is used to obtain the Gauquelin sector
sector position as a value between 1.0 and 36.9999999. Gauquelin sectors are
numbered in clockwise direction.

There are six methods of computing
the Gauquelin sector position of a planet:

The sidereal time is computed inside the houses() function
and returned via the variable armc which measures sidereal time in degrees. To get sidereal time in
hours, divide armcby 15.

If the sidereal time is required
separately from house calculation, two functions are available. The second
version requires obliquity and nutation to be given in the function call, the
first function computes them internally. Both return sidereal time at the Greenwich Meridian, measured in hours.

PLACALC, the
predecessor of SWISSEPH, had included several functions
that we do not need for SWISSEPH anymore. Nevertheless we include them again in
our DLL, because some users of our software may have taken them over and use
them in their applications. However, we gave them new names that were more
consistent with SWISSEPH.

PLACALC used
angular measurements in centiseconds a lot;
a centisecond is 1/100 of an arc second. The C
type CSEC or centisec is a 32-bit integer. CSEC was used because calculation with integer variables was
considerably faster than floating point calculation on most CPUs in 1988, when
PLACALC was written.

In the Swiss Ephemeris we have
dropped the use of centiseconds and use double (64-bit floating point) for all
angular measurements.

If you work with GFA-Basic or some other brain damaged language, the problem will occur that
the DLL interface does not support 8-bit, 32-bit, double by value and VOID data
or function types. Therefore, we have written a set of modified functions that
use double pointers instead of doubles,
character pointersinstead
of characters, and integersinstead of void. The names of these modified functions
are the same as the names of their prototypes, except that they end with ”_d”, e.g. swe_calc_d() instead of swe_calc().The export definitions of these functions can be found in file swedll.h. We do not repeat them here to avoid confusion with the ordinary
functions described in the preceding chapters. The additional functions are
only wrapper functions, i.e. they call internally the real DLL functions and
return the same results.

Swiss Ephemeris release 1.61 is the last
release for which 16-bit compilers have been supported and for which a 16-bit
DLL has been created.

The 32-bit DLL contains the exported
function under 'decorated names'. Each function has an underscore before its
name, and a suffix of the form @xx where xx is the number of stack bytes used by the call.

The Visual Basic declarations for the DLL
functions and for some important flag parameters are in the file

\sweph\vb\swedecl.txt and can be
inserted directly into a VB program.

A sample VB program vbsweph is included on the distribution, in directory \sweph\vb. To run this sample, the DLL file swedll32.dll
must be copied into the vb directory or installed in the Windows system
directory.

DLL functions returning a string:

Some DLL functions return a string, e.g.

char* swe_get_planet_name(int ipl,
char *plname)

This function copies its result into the
string pointer plname; the calling program must provide
sufficient space so that the result string fits into it. As usual in C
programming, the function copies the return string into the provided area and
returns the pointer to this area as the function value. This allows to use this
function directly in a C print statement.

In VB there are three problems with this
type of function:

1. The string
parameter plname must be initialized to a string of
sufficient length before the call; the content does not matter because it is
overwritten by the called function. The parameter type must be ByVal plname as
String.

2. The
returned string is terminated by a NULL character. This must be searched in VB
and the VB string length must be set accordingly. Our sample program
demonstrates how this can be done:

3. The function
value itself is a pointer to character. This function value cannot be used in VB
because VB does not have a pointer data type. In VB, such a Function can be
either declared as type ”As long” and the
return value ignored, or it can be declared as a Sub. We have chosen to declare
all such functions as ‚Sub‘, which
automatically ignores the return value.Declare Sub swe_get_planet_name
(ByVal ipl as Long, ByVal plname as String)

Borland
C++ Builder (BCB) does not understand the
Microsoft format in the library file SWEDLL32.LIB; it
reports an OMF error when this file is used in a BCB project. The user must
create his/her own LIB file for BCB with the utility IMPLIB which is part of
BCB.

With the following command command you
create a special lib file in the current directory:

The Swiss Ephemeris can be run from Perl
using the Perl module SwissEph.pm. The module SwissEph.pm uses XSUB (“eXternal
SUBroutine”), which calls the Swiss Ephemeris functions either from a C library
or a DLL.

In order to run the Swiss Ephemeris from
Perl, you have to

Install the Swiss Ephemeris. Either you download the Swiss
Ephemeris DLL from http://www.astro.com/swisseph
or you download the Swiss Ephemeris C source code and compile a static or
dynamic shared library. We built the package on a Linux system and use a
shared library of the Swiss Ephemeris functions.

The distribution contains executables and C
source code of sample programs which demonstrate the use of the Swiss Ephemeris
DLL and its functions.

All samples programs are compiled with the
Microsoft Visual C++ 5.0 compiler (32-bit). Project and Workspace files for
these environments are included with the source files.

Directory structure:

Sweph\bin DLL, LIB
and EXE file

Sweph\src source
files, resource files

Sweph\src\swewin32 32-bit windows sample program

Sweph\src\swete32 32-bit character mode sample program

You can run
the samples in the following environments:

Swetest.exe in Windows command line

Swete32.exe in Windows command line

Swewin32.exe in Windows

Character mode executable that needs a
DLL

Swete32.exe

The project files are in \sweph\src\swete32

swetest.c

swedll32.lib

swephexp.h

swedll.h

sweodef.h

define
macros:USE_DLL DOS32 DOS_DEGREE

swewin32.exe

The project files are in \sweph\src\swewin32

swewin.c

swedll32.lib

swewin.rc

swewin.h

swephexp.h

swedll.h

sweodef.h

resource.h

define macro USE_DLL

How the sample programs search for the
ephemeris files:

1. check
environment variable SE_EPHE_PATH; if it exists it is
used, and if it has invalid content, the program fails.

2. Try to find
the ephemeris files in the current working directory

3. Try to find
the ephemeris files in the directory where the executable resides

4. Try to find
a directory named \SWEPH\EPHE in one of the following
three drives:

·where the executable resides

·current drive

·drive C:

As soon as it succeeds in finding the first
ephemeris file it looks for, it expects all required ephemeris files to reside
there. This is a feature of the sample programs only, as you can see in our C
code.

The DLL itself has a different and simpler
mechanism to search for ephemeris files, which is described with the function swe_set_ephe_path() above.

Starting with release 1.26, the full
source code for the Swiss Ephemeris DLL is made available. Users can choose to
link the Swiss Ephemeris code directly into their applications. The source code
is written in Ansi C and consists of these files:

Bytes

Date

File name

Comment

1639

Nov 28
17:09

Makefile

unix
makefile for library

API
interface files

15050

Nov 27
10:56

swephexp.h

SwissEph
API include file

14803

Nov 27
10:59

swepcalc.h

Placalc API
include file

Internal
files

8518

Nov 27
10:06

swedate.c

2673

Nov 27
10:03

swedate.h

8808

Nov 28
19:24

swedll.h

24634

Nov 27
10:07

swehouse.c

2659

Nov 27
10:05

swehouse.h

31279

Nov 27
10:07

swejpl.c

3444

Nov 27
10:05

swejpl.h

38238

Nov 27
10:07

swemmoon.c

2772

Nov 27
10:05

swemosh.h

18687

Nov 27
10:07

swemplan.c

311564

Nov 27
10:07

swemptab.c

7291

Nov 27
10:06

sweodef.h

28680

Nov 27
10:07

swepcalc.c

173758

Nov 27 10:07

sweph.c

12136

Nov 27
10:06

sweph.h

55063

Nov 27
10:07

swephlib.c

4886

Nov 27
10:06

swephlib.h

43421

Nov 28
19:33

swetest.c

In most cases the user will compile
a linkable or shared library from the source code, using his favorite C
compiler, and then link this library with his application.

If the user programs in C, he will
only need to include the header file swephexp.h with his application; this in
turn will include sweodef.h. All other source files can ignored from the
perspective of application development.

To simplify porting of older Placalc applications to the Swiss Ephemeris API,
we have created the Placalc compatibility API which
consists of the header file swepcalc.h. This
header file replaces the headers ourdef.h, placalc.h, housasp.h and astrolib.h in Placalc applications.You should be able to link your Placalc aplication now
with the Swiss Ephemeris library. The Placalc API
is not contained in the SwissEph DLL.

Depending on what hardware and compiler you
use, there will be slight differences in your planetary calculations. For
positions in longitude, they will be never larger than 0.0001" in
longitude. Speeds show no difference larger than 0.0002 arcsec/day.

The following factors show larger
differences between HPUX and Linux on a Pentium II processor:

The differences originate from the fact
that the floating point arithmetic in the Pentium is executed with 80 bit
precision, whereas stored program variables have only 64 bit precision. When
code is optimized, more intermediate results are kept inside the processor
registers, i.e. they are not shortened from 80bit to 64 bit. When these results
are used for the next calculation, the outcome is then slightly different.

In the computation of speed for the nodes
and apogee, differences between positions at close intervals are involved; the
subtraction of nearly equal values results shows differences in internal
precision more easily than

other types of calculations. As these
differences have no effect on any imaginable application software and are
mostly within the design limit of Swiss Ephemeris, they can be savely ignored.

The last bracket
of the function main() at the end of the file is
missing.

If you want to
compile the code, you have to add it manually. Note that these files may grow
very fast,

depending on
what you are doing in your application. The output is limited to 10000 function
calls per run.

Swetrm32.dll is for multitasking, i.e. if more than one application at a time
are calling Swisseph functions. If you used the single task DLL here, all
applications would try to write their trace output into the same file. Swetrm32.dll generates output file names that contain the process identification
number of the application by which the DLL is called, e.g. swetrace_192.c and swetrace_192.txt.

Keep in mind
that every process creates its own output files and with time might fill your
disk.

In order to use a trace DLL, you have to
replace your Swisseph DLL by it:

a) save your Swisseph DLL

b) rename the trace DLL as your Swisseph
DLL (e.g. as
swedll32.dll)

IMPORTANT: The Swisseph DLL will not work properly if you call it from more
than one thread.

Similar tracing is also possible if you
compile the Swisseph source code into your application. Use the preprocessor
definitions TRACE=1 for single task debugging, and
TRACE=2 for multitasking. In most compilers this flag can be set with –DTRACE=1 or /DTRACE=1.

This is a major release which makes the
Swiss Ephemeris fully compatible with JPL Ephemeris DE430/DE431.

A considerable number of functions were
updated. That should not be a problem for existing applications. However, the
following notes must be made:

1. New ephemeris files sepl*.se1 and
semo*.se1 were created from DE431, covering the time range from 11 Aug. -12999
jul. (= 4 May -12999 greg.) to 7 Jan.
16800. For consistent ephemerides, users are advised to use either old sepl*
and semo* files (based on DE406) or new files (based on DE431) but not mix old
and new ones together. The internal handling of old and new files is not
100% identical (because of 3. below).

2. Because the time range of DE431 is a
lot greater than that of DE406, better algorithms had to be implemented for
objects not contained in JPL ephemerides (mean lunar node and apogee). Also,
sidereal time and the equation of time had to be updated in order to give
sensible results for the whole time range. The results may slightly deviate
from former versions of the Swiss Ephemeris, even for epochs inside the time
range of the old ephemeris.

3. Until version 1.80, the Swiss
Ephemeris ignored the fact that the different JPL ephemerides have a different
inherent value of the tidal acceleration of the Moon. Calculations of Delta T
must be adjusted to this value in order to get best results for the remote past,
especially for ancient observations of the Moon and eclipses. Version 2.0 might
result in slightly different values for Deltat T when compared with older
versions of the Swiss Ephemeris. The correct tidal acceleration is
automatically set in the functions swe_set_ephe_path() and swe_set_jpl_file(),
depending on the available lunar ephemeris. It can also be set using the
function swe_set_tid_acc(). Users who work with different ephemerides at the
same time, must be aware of this issue. The default value is that of DE430.

New functionality and improvements:

- Former versions of the Swiss Ephemeris
were able to exactly reproduce ephemerides of the Astronomical Almanac. The new
version also supports apparent position as given by the JPL Horizons web
interface (http://ssd.jpl.nasa.gov/horizons.cgi).
Please read the chapter 2.4.5.i in this file above.

- swe_sidtime() was improved so that it
give sensible results for the whole time range of DE431.

- swe_time_equ() was improved so that it
give sensible results for the whole time range of DE431.

- New functions swe_lmt_to_lat() and
swe_lat_to_lmt() were added. They convert local mean time into local apparent
time and reverse.

- New function swe_lun_eclipse_when_loc()
provides lunar eclipses that are observable at a given geographic position.

- Bug fix in function
swe_sol_eclipse_when_loc().If the local maximum eclipse occurs at sunset or
sunrise, tret[0] now gives the moment when the lower limb of the Sun touches
the horizon. This was not correctly implemented in former versions

- Several changes to C code that had
caused compiler warnings (as proposed by Torsten Förtsch).

- Bug fix in Perl functions swe_house()
etc. These functions had crashed with a segmention violation if called with the
house parameter ‘G’.

- Bug fix in Perl function swe_utc_to_jd(), where gregflag had been
read from the 4th instead of the 6th parameter.

- Bug fix in Perl functions to do with date conversion. The default
mechanism for gregflag was buggy.

- For
Hindu astrologers, some more ayanamshas were added that are related to
Suryasiddhanta and Aryabhata and are of historical interest.

- Attention with swe_sol_eclipse_how(): return value
attr[4] is azimuth, now measured from south, in agreement with the function
swe_azalt() and swe_azalt_rev().

- minor bug fix in swe_rise_trans():
twilight calculation returned invalid times at high geographic latitudes.

- minor bug fix: when calling swe_calc()
1. with SEFLG_MOSEPH, 2. with SEFLG_SWIEPH, 3. again with SEFLG_MOSEPH, the
result of 1. and 3. were slightly different. Now they agree.

- minor bug fix in swe_houses(): With
house methods H (Horizon), X (Meridian), M (Morinus), and geographic latitudes
beyond the polar circle, the ascendant was wrong at times. The ascendant always
has to be on the eastern part of the horizon.

- For the period before 1633, the new formulae by Espenak and Meeus
(2006) are used. These formulae were
derived from Morrison & Stephenson (2004), as used by the Swiss Ephemeris
until version 1.76.02.

- The tidal acceleration of the moon contained in LE405/6 was corrected
according to Chapront/Chapront-Touzé/Francou A&A 387 (2002), p. 705.

- Fixed stars:

- There was an error in the handling of the proper motion in RA. The
values given in fixstars.cat, which are taken from the Simbad database
(Hipparcos), are referred to a great circle and include a factor of cos(d0).

- There is a new fixed stars file sefstars.txt. The parameters are now
identical to those in the Simbad database, which makes it much easier to add
new star data to the file. If the program function swe_fixstars() does not find
sefstars.txt, it will try the the old fixed stars file fixstars.cat and will
handle it correctly.

- Fixed stars data were updated, some errors corrected.

- Search string for a star ignores white spaces.

- Other changes:

- New function swe_utc_time_zone(), converts local time to UTC and UTC
to local time. Note, the function has no knowledge about time zones. The Swiss
Ephemeris still does not provide the time zone for a given place and time.

- swecl.c:swe_rise_trans() has two new minor features:
SE_BIT_FIXED_DISC_SIZE and SE_BIT_DISC_BOTTOM (thanks to Olivier Beltrami)

- The Swiss Ephemeris is now able to read
ephemeris files of JPL ephemerides DE200 - DE421. If JPL will not change the
file structure in future releases, the Swiss Ephemeris will be able to read
them, as well.

- Function swe_fixstar() (and
swe_fixstar_ut()) was made slightly more efficient.

In September 2006, Pluto was introduced
to the minor planet catalogue and given the catalogue number 134340.

The numerical integrator we use to
generate minor planet ephemerides would crash with 134340 Pluto, because Pluto
is one of those planets whose gravitational perturbations are used for the
numerical integration. Instead of fixing the numerical integrator for this
special case, we chang the Swiss Ephemeris functions in such a way that they
treat minor planet 134340 Pluto (ipl=SE_AST_OFFSET+134340) as our main body
Pluto (ipl=SE_PLUTO=9). This also results in a slightly better precision for
134340 Pluto.

Swiss Ephemeris versions prior to 1.71
are not able to do any calculations for minor planet number 134340.

Bug fixed (in swecl.c: swi_bias()): This
bug sometimes resulted in a crash, if the DLL was used and the SEFLG_SPEED was
not set. It seems that the error happened only with the DLL and did not appear,
when the Swiss Ephemeris C code was directly linked to the application.

·Topocentric lunar positions (not relevant for common astrology): the ellipsoid shape of the
earth was not correctly implemented. This resulted in an error of 2 - 3 arc
seconds. The new precision is 0.2 - 0.3 arc seconds, corresponding to about 500
m in geographic location. This is also the precision that Nasa's Horizon system
provides for the topocentric moon. The planets are much better, of course.

·Solar eclipse functions: The correction of the topocentric moon
and another small bug fix lead to slightly different results of the solar
eclipse functions. The improvement is within a few time seconds.

·J2000 coordinates for the lunar nodes
were redefined: In versions before 1.50, the J2000 lunar nodes were the
intersection points of the lunar orbit with the ecliptic of 2000. From 1.50 on,
they are defined as the intersection points with the ecliptic of date, referred
to the coordinate system of the ecliptic of J2000.

The time range of the Swiss Ephemeris has
been extended by numerical integration. The Swiss Ephemeris now covers the
period 2 Jan 5401 BC to 31 Dec 5399 AD. To use the extended time
range, the appropriate ephemeris files must be downloaded.

In the JPL mode and the Moshier mode the
time range remains unchanged at 3000 BC to 3000 AD.

IMPORTANT

Chiron’s ephemeris is now restricted to the
time range 650 AD – 4650 AD; for explanations, see swisseph.doc.

Outside this time range, Swiss Ephemeris
returns an error code and a position value 0. You must handle this situation in
your application. There is a similar restriction with Pholus (as with some
other asteroids).

The environment variable SE_EPHE_PATH is now always overriding the call to swe_set_ephe_path() if it is set and contains a value.

Both the environment variable and the
function argument can now contain a list of directory names where the ephemeris
files are looked for. Before this release, they could contain only a single
directory name.

·source code is included with the
distribution under the new licensing model

·the Placalc compatibility API (swepcalc.h) is now documented

·There is a new function to
compute the equation of time swe_time_equ().

·Improvements of ephemerides:

·ATTENTION: Ephemeris of 16 Psyche has been wrong so far ! By a
mysterious mistake it has been identical to 3 Juno.

·Ephemerides of Ceres, Pallas, Vesta,
Juno, Chiron and Pholus have been reintegrated, with more recent orbital
elements and parameters (e.g. asteroid masses) that are more appropriate to
Bowells database of minor planets elements. The differences are small, though.

·Minor bug fix in computation of
topocentric planet positions. Nutation has not been correcly considered in
observer’s position. This has lead to an error of 1 milliarcsec with the
planets and 0.1” with the moon.

·We have inactivated the coordinate
transformation from IERS to FK5, because there is still no
generally accepted algorithm. This results in a difference of a few milliarcsec
from former releases.

·swe_house_pos for computation of the
house position of a given planet. See description in SWISSEPH.DOC, Chapter 3.1 ”Geocentric and topocentric
positions”. A bug has been fixed that has sometimes turned up, when the
JPL ephemeris was closed. (An error in memory allocation and freeing.)

·A change of the ephemeris bits in
parameter iflag of function
swe_calc() usually forces an implicit swe_close()
operation. Inside a loop, e.g. for drawing a graphical epehemeris, this can
slow down a program. Before this release, two calls with iflag = 0 and iflag = SEFLG_SWIEPH where
considered different, though in fact the same ephemeris is used. Now these two
calls are considered identical, and swe_close() is not
performed implicitly.
For calls with the pseudo-planet-number ipl = SE_ECL_NUT, whose result does not depend on the chosen ephemeris, the
ephemeris bits are ignored completely and swe_close()
is never performed implicitly.

·In former versions, calls of the
Moshier ephemeris with speed and without speed flag have returned a very small
difference in position (0.01 arc second). The reason was that, for precise
speed, swe_calc() had to do an additional iteration in the light-time calculation.
The two calls now return identical position data.

·A bug has been fixed that sometimes
occurred in swe_calc() when the user changed iflag between calls, e.g. the speed flag. The first call for a planet which had been
previously computed for the same time, but a different iflag, could return
incorrect results, if Sun, Moon or Earth had been computed for a different time
in between these two calls.

·A bug has been fixed that has
sometimes lead to a floating point exception when the speed flag was not
specified and an unusual sequence of planets was called.

·Additional asteroid files have been
included.

Attention: Use these files only with
the new DLL. Previous versions cannot deal with more than one additional
asteroid besides the main asteroids. This error did not appear so far, because
only 433 Eros was on our CD-ROM.

·swe_fixstar() has a better
implementation for the search of a specific star. If a number is given, the
non-comment lines in the file fixstars.cat are now
counted from 1; they where counted from zero in earlier releases.

·swe_fixstar() now also computes
heliocentric and barycentric fixed stars positions. Former versions Swiss
Ephemeris always returned geocentric positions, even if the heliocentric or the
barycentric flag bit was set.

·The Galactic Center has been included in fixstars.cat.

·Two small bugs were fixed in the
implementation of the barycentric Sun and planets. Under unusual conditions,
e.g. if the caller switched from JPL to Swiss Ephemeris or vice-versa, an error
of an arc second appeared with the barycentric sun and 0.001 arc sec with the
barycentric planets. However, this did not touch normal geocentric
computations.

·Some VB declarations in swedecl.txt
contained errors and have been fixed. The VB sample has been extended to show
fixed star and house calculation. This fix is only in 1.03 releases from
29-oct-97 or later, not in the two 1.03 CDROMs we burned on 28-oct-97.

·A new function swe_houses_armc() has been added which can be used when a sidereal time (armc) is given but no actual date is known, e.g. for Composite charts.

·The body numbers of the hypothetical
bodies have been changed.

·The development environment for the
DLL and the sample programs have been changed from Watcom 10.5 to Microsoft
Visual C++ (5.0 and 1.5). This was necessary because the Watcom compiler created
LIB files which were not compatible with Microsoft C. The LIB files created by
Visual C however are compatible with Watcom.