- -
Programming interface to the Swiss -Ephemeris
- -- -
Copyright Astrodienst AG 1997-2011.
- -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.
- -- -
1. The programming -steps to get a planet’s position5
- -2. The functions -swe_calc_ut() and swe_calc()7
- - - -2.2. Error handling and return values. 7
- - - - - - - - - -2.4. Options chosen by flag bits (long iflag)13
- - - - - - - -2.4.4. Coordinate systems, degrees and radians. 14
- -2.4.5. Specialties (going beyond common interest). 14
- -a. True or apparent positions14
- - - - - - - - - -f. True or mean equinox of date15
- -g. J2000 positions and positions referred to other -equinoxes15
- - - -2.5. Position and Speed (double xx[6]). 15
- -3. The function -swe_get_planet_name()15
- - - - - - - - - - - - - - - -6. Eclipse and -planetary phenomena functions19
- -6.0. -Example of a typical eclipse calculation19
- -6.1. swe_sol_eclipse_when_loc() and -swe_lun_occult_when_loc()20
- -6.2. swe_sol_eclipse_when_glob()20
- - - -6.4. swe_sol_eclipse_where ()22
- -6.5. swe_lun_occult_when_loc()23
- -6.6. swe_lun_occult_when_glob()24
- -6.7. swe_lun_occult_where ()25
- -6.8. swe_lun_eclipse_when ()26
- - - -6.10. swe_rise_trans() and swe_rise_trans_true_hor() -(risings, settings, meridian transits)27
- -6.11. swe_pheno_ut() and swe_pheno(), planetary phenomena. 28
- -6.12. swe_azalt(), horizontal coordinates, azimuth, -altitude28
- - - -6.14. swe_refrac(), swe_refract_extended(), refraction. 29
- -6.15. Heliacal risings etc.: swe_heliacal_ut(). 30
- -6.16. Magnitude limit for visibility: swe_vis_limit_mag(). 31
- -7. Date and time -conversion functions31
- -7.1 Calendar Date and Julian Day: swe_julday(), -swe_date_conversion(), /swe_revjul()31
- - - -7.3. Future insertion of leap seconds and the file -swe_leapsec.txt34
- -7.4. Mean solar time versus True solar time: -swe_time_equ()34
- -8. Delta T-related -functions34
- - - -8.2 swe_set_tid_acc(), swe_get_tid_acc(). 35
- -8.3. Future updates of Delta T and the file -swe_deltat.txt35
- -9. The function -swe_set_topo() for topocentric planet positions35
- -10. Sidereal mode functions. 35
- - - -10.2. swe_get_ayanamsa_ut() and swe_get_ayanamsa(). 37
- -11. The Ephemeris -file related functions37
- - - - - - - - - - - - - - - - - -13. The sign of -geographical longitudes in Swisseph functions41
- -14. Getting the -house position of a planet with swe_house_pos()41
- - - -15. Sidereal time -with swe_sidtime() and swe_sidtime0()43
- -16. Summary of -SWISSEPH functions44
- -16.1. Calculation of planets and stars. 44
- -Planets, moon, asteroids, lunar nodes, apogees, -fictitious bodies44
- - - -Set the geographic location for topocentric planet -computation44
- -Set the sidereal mode for sidereal planet positions. 44
- -16.2 Eclipses and planetary phenomena. 45
- -Find the next eclipse for a given geographic position. 45
- -Find the next eclipse globally45
- -Compute the attributes of a solar eclipse for a given -tjd, geographic long., latit. and height45
- -Find out the geographic position where a central eclipse -is central or a non-central one maximal45
- -Find the next occultation of a body by the moon for a -given geographic position46
- -Find the next occultation globally46
- - - -Compute the attributes of a lunar eclipse at a given time. 46
- -Compute risings, settings and meridian transits of a body. 46
- - - -16.3. Date and time conversion47
- -Delta T from Julian day number47
- -Julian day number from year, month, day, hour, with check -whether date is legal48
- -Julian day number from year, month, day, hour48
- -Year, month, day, hour from Julian day number48
- -Local time to UTC and UTC to local time. 48
- - - - - - - -Get tidal acceleration used in swe_deltat(). 49
- -Set tidal acceleration to be used in swe_deltat(). 49
- - - -16.4. Initialization, setup, and closing functions. 49
- -Set directory path of ephemeris files. 49
- - - - - -House cusps, ascendant and MC50
- -Extended house function; to compute tropical or sidereal -positions50
- -Get the house position of a celestial point. 50
- -Get the Gauquelin sector position for a body. 51
- - - -Coordinate transformation, from ecliptic to equator or -vice-versa52
- -Coordinate transformation of position and speed, from -ecliptic to equator or vice-versa52
- - - -16.7. Other functions that may be useful52
- -Normalize argument into interval [0..DEG360]. 52
- -Distance in centisecs p1 - p2 normalized to [0..360]. 52
- - - -Distance in centisecs p1 - p2 normalized to [-180..180]. 52
- - - -Round second, but at 29.5959 always down. 53
- -Double to long with rounding, no overflow check. 53
- - - - - -Centiseconds -> longitude or latitude string. 53
- -Centiseconds -> degrees string53
- - - -17.1 DLL Interface for brain damaged compilers. 53
- -18. Using the DLL -with Visual Basic 5.0. 54
- -19. Using the DLL -with Borland Delphi and C++ Builder54
- -19.1 Delphi 2.0 and higher (32-bit). 54
- - - -20. Using the -Swiss Ephemeris with Perl55
- - - -21. The source -code distribution57
- -22. The PLACALC -compatibility API57
- - - -24. Swisseph with -different hardware and compilers58
- -25. Debugging and -Tracing Swisseph58
- -25.1. If you are using the DLL58
- -25.2 If you are using the source code. 59
- - - - - -Changes from version 1.78 to 1.7961
- -Changes from version 1.77 to 1.7861
- -Changes from version 1.76 to 1.7761
- -Changes from version 1.75 to 1.7662
- -Changes from version 1.74 to version 1.75. 62
- -Changes from version 1.73 to version 1.74. 62
- -Changes from version 1.72 to version 1.73. 63
- -Changes from version 1.71 to version 1.72. 63
- -Changes from version 1.70.03 to version 1.71. 63
- -Changes from version 1.70.02 to version 1.70.03. 63
- -Changes from version 1.70.01 to version 1.70.02. 63
- -Changes from version 1.70.00 to version 1.70.01. 63
- -Changes from version 1.67 to version 1.70. 63
- -Changes from version 1.66 to version 1.67. 64
- -Changes from version 1.65 to version 1.66. 64
- -Changes from version 1.64.01 to version 1.65.00. 64
- -Changes from version 1.64 to version 1.64.01. 64
- -Changes from version 1.63 to version 1.64. 64
- -Changes from version 1.62 to version 1.63. 64
- -Changes from version 1.61.03 to version 1.62. 65
- -Changes from version 1.61 to 1.61.01. 65
- -Changes from version 1.60 to 1.6165
- -Changes from version 1.51 to 1.6065
- -Changes from version 1.50 to 1.5165
- -Changes from version 1.40 to 1.5065
- -Changes from version 1.31 to 1.4066
- -Changes from version 1.30 to 1.3166
- -Changes from version 1.27 to 1.3066
- -Changes from version 1.26 to 1.2766
- -Changes from version 1.25 to 1.2666
- -Changes from version 1.22 to 1.2366
- -Changes from version 1.21 to 1.2267
- -Changes from version 1.20 to 1.2167
- -Changes from version 1.11 to 1.2067
- -Changes from version 1.10 to 1.1167
- -Changes from version 1.04 to 1.1067
- -Changes from Version 1.03 to 1.0467
- -Changes from Version 1.02 to 1.0367
- -Changes from Version 1.01 to 1.0268
- -Changes from Version 1.00 to 1.0168
- - - - - - - - - - - - - - - -- -
- -
To compute a celestial bodyor point with SWISSEPH, you have to do the following steps (use swetest.c as an example). The details of -the functions will be explained in the following chapters.
- -- -
1. Set -the directory path of the ephemeris files, e.g.:
- -swe_set_ephe_path(”C:\\SWEPH\\EPHE”);
- -- -
2.. From -the birth date, compute the Julian day number:
- -jul_day_UT -= swe_julday(year, month, day, hour, gregflag);
- -- -
3.. Compute a planet or other bodies:
- -ret_flag = swe_calc_ut(jul_day_UT, -planet_no, flag, lon_lat_rad, err_msg);
- -or a -fixed star:
- -ret_flag = swe_fixstar_ut(star_nam, -jul_day_UT, flag, lon_lat_rad, err_msg);
- -- -
Note:
- -The functions swe_calc_ut() -and swe_fixstar_ut() were introduced with Swisseph version 1.60.
- -If you use a Swisseph version -older than 1.60 or if you want to work with Ephemeris -Time, you have to -proceed as follows instead:
- -- -
First, if necessary, convert Universal Time -(UT) to Ephemeris Time (ET):
- -jul_day_ET = jul_day_UT + swe_deltat(jul_day_UT);
- -- -
Then Compute a planet or other bodies:
- -ret_flag = swe_calc(jul_day_ET, -planet_no, flag, lon_lat_rad, err_msg);
- -or a fixed star:
- -ret_flag = swe_fixstar(star_nam, -jul_day_ET, flag, lon_lat_rad, err_msg);
- -- -
5.. At -the end of your computations close all files and free memory calling swe_close();
- -- -
Here is a miniature sample program, it is in the -source distribution as swemini.c
- -- -
#include "swephexp.h" /* this includes "sweodef.h" */
- -int main()
- -{
- --char *sp, sdate[AS_MAXCH], snam[40], serr[AS_MAXCH];
- --int jday = 1, jmon = 1, jyear = 2000;
- -double jut = 0.0;
- -double tjd_ut, te, x2[6];
- -long iflag, iflgret;
- -int p;
- -iflag = SEFLG_SPEED;
- -while (TRUE) {
- --printf("\nDate (d.m.y) ?");
- --gets(sdate);
- -/* -stop if a period . is entered */
- --if (*sdate == '.')
- --return OK;
- --if (sscanf (sdate, "%d%*c%d%*c%d", -&jday,&jmon,&jyear) < 1) exit(1);
- -/*
- -* -we have day, month and year and convert to Julian day number
- -*/
- --tjd_ut = swe_julday(jyear,jmon,jday,jut,SE_GREG_CAL);
- -/*
- -* compute Ephemeris time from Universal -time by adding delta_t
- -* not required for Swisseph versions -smaller than 1.60
- -*/
- --/* te = tjd_ut + swe_deltat(tjd_ut); */
- --printf("date: %02d.%02d.%d at 0:00 Universal time\n", jday, -jmon, jyear);
- --printf("planet -\tlongitude\tlatitude\tdistance\tspeed long.\n");
- -/*
- -* a loop over all planets
- -*/
- --for (p = SE_SUN; p <= SE_CHIRON; p++) {
- --if (p == SE_EARTH) continue;
- -/*
- -* do the coordinate calculation for this -planet p
- -*/
- -iflgret = swe_calc_ut(tjd_ut, p, iflag, -x2, serr);
- --/* Swisseph versions older than 1.60 require the following
- --* statement instead */
- -/* iflgret = swe_calc(te, p, iflag, x2, -serr); */
- -/*
- -* if there is a problem, a negative -value is returned and an
- -* error message is in serr.
- -*/
- --if (iflgret < 0)
- -printf("error: %s\n", -serr);
- --/*
- -* get the name of the planet p
- -*/
- --swe_get_planet_name(p, snam);
- -/*
- -* print the coordinates
- -*/
- --printf("%10s\t%11.7f\t%10.7f\t%10.7f\t%10.7f\n",
- -snam, x2[0], x2[1], x2[2], x2[3]);
- --}
- -}
- --return OK;
- -}
- -swe_calc_ut() -was introduced with Swisseph version 1.60 and makes planetary -calculations a bit simpler. For the steps required, see the chapter The programming steps to get a planet’s position.
- -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:
- - - -int swe_calc_ut -( double tjd_ut, int ipl, int iflag, double* xx, char* serr),
- - - -tjd_ut =Julian day, -Universal Time
- -ipl =body number
- -iflag =a 32 bit integer -containing bit flags that indicate what kind of computation is wanted
- -xx =array of 6 doubles -for longitude, latitude, distance, speed in long., speed in lat., and speed in -dist.
- -serr[256] =character string to return error messages in case of -error.
- -- -
and
- -int swe_calc(double -tjd_et, int ipl, int iflag, double *xx, char *serr),
- -same but
- -tjd_et = Julian -day, Ephemeris time, where tjd_et = -tjd_ut + swe_deltat(tjd_ut)
- -- -
A detailed description of these -variables will be given in the following sections.
- -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:
- -- -
· -if an illegal body number has been specified
- -· -if a Julian day beyond the ephemeris -limits has been specified
- -· -if the length of the ephemeris file is -not correct (damaged file)
- -· -on read error, e.g. a file index -points to a position beyond file length ( data on file are corrupt )
- -· -if the copyright section in the -ephemeris file has been destroyed.
- -- -
If any of these errors occurs,
- -- -
· -the return code of the function is -1,
- -· -the position and speed variables are -set to zero,
- -· -the type of error is indicated in the -error string serr.
- -- -
To tell swe_calc()which -celestial body or factor should be computed, a fixed set of body numbers is -used. The body numbers are defined in swephexp.h:
- -/* planet -numbers for the ipl parameter in swe_calc() */
- -- -
#define SE_ECL_NUT -1
- -#define SE_SUN 0
- -#define SE_MOON 1
- -#define SE_MERCURY 2
- -#define SE_VENUS 3
- -#define SE_MARS 4
- -#define SE_JUPITER 5
- -#define SE_SATURN 6
- -#define SE_URANUS 7
- -#define SE_NEPTUNE 8
- -#define SE_PLUTO 9
- -#define SE_MEAN_NODE 10
- -#define SE_TRUE_NODE 11
- -#define SE_MEAN_APOG 12
- -#define SE_OSCU_APOG 13
- -#define SE_EARTH 14
- -#define SE_CHIRON 15
- -#define SE_PHOLUS 16
- -#define SE_CERES 17
- -#define SE_PALLAS 18
- -#define SE_JUNO 19
- -#define SE_VESTA 20
- -#define SE_INTP_APOG 21
- -#define SE_INTP_PERG 22
- -- -
#define SE_NPLANETS 23
- -#define SE_FICT_OFFSET 40
- -#define SE_NFICT_ELEM 15
- -- -
/* -Hamburger or Uranian "planets" */
- -- -
#define SE_CUPIDO 40
- -#define SE_HADES 41
- -#define SE_ZEUS 42
- -#define SE_KRONOS 43
- -#define SE_APOLLON 44
- -#define SE_ADMETOS 45
- -#define SE_VULKANUS 46
- -#define SE_POSEIDON 47
- -- -
/* other -fictitious bodies */
- -- -
#define SE_ISIS 48
- -#define SE_NIBIRU 49
- -#define SE_HARRINGTON 50
- -#define SE_NEPTUNE_LEVERRIER 51
- -#define SE_NEPTUNE_ADAMS 52
- -#define SE_PLUTO_LOWELL 53
- -#define SE_PLUTO_PICKERING 54
- -- -
#define -SE_AST_OFFSET 10000
- -- -
- -
- -
Body numbers of other asteroids are above SE_AST_OFFSET (=10000) and have to be constructed as -follows:
- -ipl = SE_AST_OFFSET + -Minor_Planet_Catalogue_number;
- -e.g. Eros : ipl = SE_AST_OFFSET + 433
- -The names of the asteroids and their -catalogue numbers can be found in seasnam.txt.
- -Examples are:
- -- -
5 Astraea
- -6 Hebe
- -7 Iris
- -8 Flora
- -9 Metis
- -10 Hygiea
- -30 Urania
- -42 Isis not identical with -"Isis-Transpluto"
- -153 Hilda (has an own asteroid belt at 4 AU)
- -227 Philosophia
- -251 Sophia
- -259 Aletheia
- -275 Sapientia
- -279 Thule (asteroid close to Jupiter)
- -375 Ursula
- -433 Eros
- -763 Cupido different from Witte's Cupido
- -944 Hidalgo
- -1181 Lilith (not identical with Dark Moon -'Lilith')
- -1221 Amor
- -1387 Kama
- -1388 Aphrodite
- -1862 Apollo (different from Witte's Apollon)
- -3553 Damocles highly eccentric orbit betw. Mars -and Uranus
- -3753 Cruithne ("second moon" of earth)
- -4341 Poseidon Greek Neptune (different from -Witte's Poseidon)
- -4464 Vulcano fire god (different from Witte's -Vulkanus and intramercurian Vulcan)
- -5731 Zeus Greek Jupiter (different from -Witte's Zeus)
- -7066 Nessus third named Centaur (beween Saturn -and Pluto)
- -- -
- -
There are two ephemeris files for -each asteroid (except the main asteroids), a long one and a short one:
- -- -
se09999.se1 long-term ephemeris of asteroid number -9999, 3000 BC – 3000 AD
- -se09999s.se1 short ephemeris of asteroid number 9999, -1500 – 2100 AD
- -- -
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
- -- -
ipl = SE_FICT_OFFSET_1 + -number_of_elements_set;
- -- -
e.g. for Kronos: ipl = 39 + 4 = 43.
- -- -
The file seorbel.txt -has the following structure:
- -- -
# Orbital elements of fictitious planets
- -# 27 Jan. 2000
- -#
- -# This file is part of the Swiss Ephemeris, from Version 1.60 -on.
- -#
- -# Warning! These planets do not exist!
- -#
- -# The user can add his or her own elements.
- -# 960 is the maximum number of fictitious planets.
- -#
- -# The elements order is as follows:
- -# 1. epoch of elements (Julian day)
- -# 2. equinox (Julian day or "J1900" or -"B1950" or "J2000" or “JDATE”)
- -# 3. mean anomaly at epoch
- -# 4. semi-axis
- -# 5. eccentricity
- -# 6. argument of perihelion (ang. distance of perihelion from -node)
- -# 7. ascending node
- -# 8. inclination
- -# 9. name of planet
- -#
- -# use '#' for comments
- -# to compute a body with swe_calc(), use planet number
- -# ipl = SE_FICT_OFFSET_1 + number_of_elements_set,
- -# e.g. number of Kronos is ipl = 39 + 4 = 43
- -#
- -# Witte/Sieggruen planets, refined by James Neely
- -J1900, -J1900, 163.7409, 40.99837, 0.00460, 171.4333, 129.8325, 1.0833, Cupido # 1
- -J1900, -J1900, 27.6496, 50.66744, 0.00245, -148.1796, 161.3339, 1.0500, Hades # 2
- -J1900, -J1900, 165.1232, 59.21436, 0.00120, 299.0440, -0.0000, 0.0000, Zeus # 3
- -J1900, -J1900, 169.0193, 64.81960, 0.00305, 208.8801, -0.0000, 0.0000, Kronos # 4
- -J1900, -J1900, 138.0533, 70.29949, 0.00000, 0.0000, 0.0000, 0.0000, -Apollon # 5
- -J1900, -J1900, 351.3350, 73.62765, 0.00000, -0.0000, 0.0000, 0.0000, -Admetos # 6
- -J1900, -J1900, 55.8983, 77.25568, 0.00000, 0.0000, -0.0000, 0.0000, Vulcanus # 7
- -J1900, -J1900, 165.5163, 83.66907, 0.00000, 0.0000, 0.0000, 0.0000, Poseidon # 8
- -#
- -# Isis-Transpluto; elements from "Die Sterne" 3/1952, -p. 70ff.
- -# Strubell does not give an equinox. 1945 is taken in order to
- -# reproduce the as best as ASTRON ephemeris. (This is a strange -
- -# choice, though.)
- -# The epoch according to Strubell is 1772.76.
- -# 1772 is a leap year!
- -# The fraction is counted from 1 Jan. 1772
- -2368547.66, 2431456.5, -0.0, 77.775, 0.3, 0.7, 0, 0, Isis-Transpluto # 9
- -# Nibiru, elements from Christian Woeltge, Hannover
- -1856113.380954, -1856113.380954, 0.0, 234.8921, 0.981092, 103.966, -44.567, 158.708, Nibiru # 10
- -# Harrington, elements from Astronomical Journal 96(4), Oct. -1988
- -2374696.5, J2000, 0.0, -101.2, 0.411, 208.5, 275.4, 32.4, Harrington # 11
- -# according to W.G. Hoyt, "Planets X and Pluto", -Tucson 1980, p. 63
- -2395662.5, 2395662.5, -34.05, 36.15, 0.10761, 284.75, 0, 0, Leverrier (Neptune) # 12
- -2395662.5, 2395662.5, -24.28, 37.25, 0.12062, 299.11, 0, 0, Adams (Neptune) # 13
- -2425977.5, 2425977.5, 281, -43.0, 0.202, 204.9, 0, 0, Lowell (Pluto) # 14
- -2425977.5, -2425977.5, 48.95, 55.1, 0.31, 280.1, 100, 15, Pickering (Pluto) # 15
- -J1900,JDATE, -252.8987988 + 707550.7341 * T, 0.13744, 0.019, 322.212069+1670.056*T, -47.787931-1670.056*T, 7.5, Vulcan # 16
- -# Selena/White Moon
- -J2000,JDATE, 242.2205555, -0.05279142865925, 0.0, 0.0, 0.0, 0.0, Selena/White Moon, geo # 17
- -- -
All orbital -elements except epoch and equinox may have T -terms, where
- -T = (tjd – epoch) -/ 36525.
- -(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.
- -- -
iflgret = swe_calc(tjd_et, -SE_ECL_NUT, 0, x, serr);
- -- -
x is an -array of 6 doubles as usual. They will be filled as follows:
- -- -
x[0] = true obliqutiy of the Ecliptic -(includes nutation)
- -x[1] = mean obliquity of the Ecliptic
- -x[2] = nutation in longitude
- -x[3] = nutation in obliquity
- -x[4] = x[5] = 0
- -- -
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:
- -iflag = -SEFLG_SPEED | SEFLG_TRUEPOS; (or: iflag = SEFLG_SPEED + SEFLG_TRUEPOS;) // C
- -iflag = -SEFLG_SPEED or SEFLG_TRUEPOS;(or: iflag = -SEFLG_SPEED + SEFLG_TRUEPOS;) -// Pascal
- -- -
With this value ofiflag, swe_calc() will compute true positions ( i.e. not accounted for light-time ) -with speed.
- -The flag bits, which are defined in swephexp.h, are:
- -- -
#define -SEFLG_JPLEPH 1L // use JPL ephemeris -
- -#define -SEFLG_SWIEPH 2L // use SWISSEPH -ephemeris, default
- -#define -SEFLG_MOSEPH 4L // use Moshier -ephemeris
- -- -
#define -SEFLG_HELCTR 8L // -return heliocentric position
- -#define -SEFLG_TRUEPOS 16L // return true positions, not apparent
- -#define -SEFLG_J2000 32L // -no precession, i.e. give J2000 equinox
- -#define -SEFLG_NONUT 64L // -no nutation, i.e. mean equinox of date
- -#define -SEFLG_SPEED3 128L // -speed from 3 positions (do not use it, SEFLG_SPEED is
- -// -faster and preciser.)
- -#define -SEFLG_SPEED 256L // -high precision speed (analyt. comp.)
- -#define -SEFLG_NOGDEFL 512L // turn off gravitational deflection
- -#define -SEFLG_NOABERR 1024L // turn off 'annual' aberration of light
- -#define -SEFLG_EQUATORIAL 2048L // equatorial positions are wanted
- -#define -SEFLG_XYZ 4096L // -cartesian, not polar, coordinates
- -#define -SEFLG_RADIANS 8192L // -coordinates in radians, not degrees
- -#define -SEFLG_BARYCTR 16384L // -barycentric positions
- -#define -SEFLG_TOPOCTR (32*1024L) // topocentric positions
- -#define SEFLG_SIDEREAL (64*1024L) // sidereal -positions
- -#define SEFLG_ICRS (128*1024L) // ICRS (DE406 reference frame)
- -- -
The flags to choose an ephemeris -are: (s. swephexp.h)
- -- -
SEFLG_JPLEPH /* use JPL ephemeris */
- -SEFLG_SWIEPH /* use Swiss Ephemeris */
- -SEFLG_MOSEPH /* use Moshier ephemeris */
- -- -
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.
- -- -
Swe_calc()does -not compute speed if you do not add the speed flag SEFLG_SPEED. E.g.
- -iflag |= SEFLG_SPEED;
- -The computation of speed is usually cheap, -so you may set this bit by default even if you do not need the speed.
- -- -
- -
SEFLG_EQUATORIAL returns -equatorial positions: rectascension and declination.
- -SEFLG_XYZ returns x, -y, z coordinates instead of longitude, latitude, and distance.
- -SEFLG_RADIANS returns -position in radians, not degrees.
- -- -
E.g. to compute rectascension and -declination, write:
- -iflag = SEFLG_SWIEPH | SEFLG_SPEED | -SEFLG_EQUATORIAL;
- -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.
- -To compute the truegeometrical position of a planet, -disregarding light-time, you have to add the flag SEFLG_TRUEPOS.
- -To compute topocentric -positions, i.e. positions referred to the place of the observer (the birth -place) rather than to the center of the earth, do as follows:
- -· -call swe_set_topo(geo_lon, -geo_lat, altitude_above_sea) (The longitude and latitude must be in degrees, the altitude in meters.)
- -· -add the flag SEFLG_TOPOCTR toiflag
- -· -call swe_calc(...)
- -To compute a heliocentric position, -add SEFLG_HELCTR.
- -A heliocentric position can be -computed for all planets including the moon. For the sun, lunar nodes and lunar apogees the coordinates are -returned as zero; no error message appears.
- -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 true equinox of the date ( i.e. with nutation ). -If you want the mean equinox, you can turn nutation off, using the flag bit -SEFLG_NONUT.
- -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.
- -To compute sidereal positions, set -bit SEFLG_SIDEREAL and use the function swe_set_sid_mode() in order to define the ayanamsha you want. For more information, read the description of this -function.
- -- -
- -
swe_calc()returns -the coordinates of position and velocity in the following order:
- -- -
|
- Ecliptic position - |
-
- Equatorial position ( SEFLG_EQUATORIAL - ) - |
-
|
- Longitude - |
-
- Rectascension - |
-
|
- Latitude - |
-
- Declination - |
-
|
- Distance in AU - |
-
- distance in AU - |
-
|
- Speed in - longitude (deg/day) - |
-
- Speed in - rectascension (deg/day) - |
-
|
- Speed in - latitude (deg/day) - |
-
- Speed in - declination (deg/day) - |
-
|
- Speed in - distance (AU/day) - |
-
- Speed in - distance (AU/day) - |
-
- -
If you need rectangular -coordinates ( SEFLG_XYZ ), swe_calc() returns x, y, z, dx, dy, dz in AU.
- -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.
- - - -This function allows to find a planetary or asteroid name, when the planet -number is given. The function definition is
- -char* swe_get_planet_name(int -ipl, char *spname);
- -- -
If an asteroid name is wanted, the -function does the following:
- -- -
· -The name is first looked for in the -asteroid file.
- -· -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 file seasnam.txt can be updated by the user. To do this, download the names list -from the Minor Planet Center http://cfa-www.harvard.edu/iau/lists/MPNames.html, -rename it as seasnam.txt and move it into your ephemeris directory.
- -- -
The file seasnam.txt need not be ordered in any way. There must be one asteroid per -line, first its catalogue number, then its name. The asteroid number may or may -not be in brackets.
- -Example:
- -- -
(3192) A'Hearn
- -(3654) AAS
- -(8721) AMOS
- -(3568) ASCII
- -(2848) ASP
- -(677) Aaltje
- -...
- -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:
- -- -
long swe_fixstar_ut(char* -star, double -tjd_ut, long -iflag, -double* xx, -char* serr);
- -where
- -star =name of -fixed star to be searched, returned name of found star
- -tjd_ut =Julian day -in Universal Time
- -iflag =an integer -containing several flags that indicate what kind -of computation is wanted
- -xx =array of 6 -doubles for longitude, latitude, distance, speed in long., speed in lat., and -speed in dist.
- -serr[256] =character string to contain error messages in case of -error.
- -For more info, see below under 4.2. -swe_fixstar()
- -- -
long swe_fixstar(char -*star, -double tjd_et, long iflag, double* xx, char* serr);
- -same, but -tjd_et= Julian day in Ephemeris Time
- -- -
The
-parameter star must provide for at least 41 characters for the returned star name
-(= 2 x SE_MAX_STNAME + 1, where SE_MAX_STNAME is defined in swephexp.h). If a star is found, its name is returned in this field in the
-format
-traditional_name,
-nomenclature_namee.g. "Aldebaran,alTau".
- -
The function has three modes to search for a star in the filefixstars.cat:
- -- -
· -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.
- -- -
long swe_fixstar_mag(char *star, double* mag, char* serr);
- -- -
Function calculates the magnitude of -a fixed star. The function returns OK or ERR. The magnitude value is returned -in the parameter mag.
- -For the definition and use of the -parameter star see function swe_fixstar(). The -parameter serr and is, as usually, an error -string pointer.
- -- -
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 definitions are:
- -- -
int32 swe_nod_aps_ut(double tjd_ut, int32 ipl, int32 iflag, int32 method, double *xnasc, double *xndsc, double *xperi, double *xaphe, char *serr);
- -where
- -tjd_ut =Julian -day in Universal Time
- -ipl =planet -number
- -iflag =same -as with swe_calc_ut() and swe_fixstar_ut()
- -method =another -integer that specifies the calculation method, see explanations below
- -xnasc =array -of 6 doubles for ascending node
- -xndsc =array -of 6 doubles for descending node
- -xperi =array -of 6 doubles for perihelion
- -xaphe =array -of 6 doubles for aphelion
- -serr[256] =character -string to contain error messages in case of error.
- -int32 swe_nod_aps(double -tjd_et, int32 ipl, int32 iflag, int32 method, double *xnasc, double *xndsc, -double *xperi, double *xaphe, char *serr);
- -same, but
- -tjd_et = Julian day in Ephemeris Time
- -- -
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.
- -- -
- -
There are the following functions -for eclipse and occultation calculations.
- -- -
Solar eclipses:
- -· -swe_sol_eclipse_when_loc( tjd...) finds -the next eclipse for a given geographic position.
- -· -swe_sol_eclipse_when_glob( tjd...) -finds the next eclipse globally.
- -· -swe_sol_eclipse_where() computes the -geographic location of a solar eclipse for a given tjd.
- -· -swe_sol_eclipse_how() computes -attributes of a solar eclipse for a given tjd, -geographic longitude, -latitude and height.
- -- -
Occultations of planets by the moon:
- -These functions can also be used for -solar eclipses. But they are slightly less efficient.
- -· -swe_lun_occult_when_loc( tjd...) finds -the next occultation for a body and a given geographic position.
- -· -swe_lun_occult_when_glob( tjd...) finds -the next occultation of a given body globally.
- -· -swe_lun_occult_where() computes the -geographic location of an occultation for a given tjd.
- -- -
Lunar eclipses:
- -· -swe_lun_eclipse_when(tjd...) finds the -next lunar eclipse.
- -· -swe_lun_eclipse_how() computes the attributes of a lunar eclipse for a given tjd.
- -- -
Risings, settings, and meridian -transits of planets and stars:
- -· -swe_rise_trans()
- -· -swe_rise_trans_true_hor( ) -returns rising and setting times for a local horizon with altitude != 0
- -- -
Planetary phenomena:
- -· -swe_pheno_ut() and swe_pheno() compute phase angle, phase, elongation, apparent diameter, and -apparent magnitude of the Sun, the Moon, all planets and asteroids.
- -- -
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):
- -- -
double tret[10], -attr[20], geopos[10];
- -char -serr[255];
- -int32 -whicheph = 0; /* default ephemeris */
- -double -tjd_start = 2451545; /* Julian day number for 1 Jan 2000 */
- -int32 -ifltype = SE_ECL_TOTAL ¦ SE_ECL_CENTRAL ¦ SE_ECL_NONCENTRAL;
- -/* find -next eclipse anywhere on earth */
- -eclflag = -swe_sol_eclipse_when_glob(tjd_start, whicheph, -ifltype, tret, 0, serr);
- -if (eclflag == -ERR)
- -return ERR;
- -/* the -time of the greatest eclipse has been returned in tret[0];
- -* now we can find geographical position of -the eclipse maximum */
- -tjd_start -= tret[0];
- -eclflag = -swe_sol_eclipse_where(tjd_start, whicheph, geopos, attr, serr);
- -if (eclflag == -ERR)
- -return ERR;
- -/* the -geographical position of the eclipse maximum is in geopos[0] and geopos[1];
- -* now we can calculate the four contacts for -this place. The start time is chosen
- -* a day before the maximum eclipse: */
- -tjd_start -= tret[0] - 1;
- -eclflag = -swe_sol_eclipse_when_loc(tjd_start, whicheph, geopos, tret, attr, 0, serr);
- -if (eclflag == -ERR)
- -return ERR;
- -/* now -tret[] contains the following values:
- -* tret[0] = time of greatest eclipse (Julian -day number)
- -* tret[1] = first contact
- -* tret[2] = second contact
- -* tret[3] = third contact
- -* tret[4] = fourth contact */
- -- -
- -
To find the next -eclipse for a given geographic position, use swe_sol_eclipse_when_loc().
- -- -
int32 swe_sol_eclipse_when_loc(
- -double -tjd_start, /* start date for search, -Jul. day UT */
- -int32 ifl, /* -ephemeris flag */
- -double -*geopos, /* 3 doubles for geo. lon, -lat, height eastern longitude is positive,
- --western longitude is negative, -northern latitude is positive,
- --southern latitude is negative */
- -double -*tret, /* return array, 10 doubles, -see below */
- -double -*attr, /* return array, 20 doubles, -see below */
- -AS_BOOL -backward, /* TRUE, if backward search -*/
- -char -*serr); /* return error string */
- -- -
The function returns:
- -/* retflag -1 (ERR) on error (e.g. if swe_calc() for -sun or moon fails)
- -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
- -- -
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)
- -- -
attr[0] fraction -of solar diameter covered by moon;
- -with total/annular eclipses, it results in -magnitude acc. to IMCCE.
- -attr[1] ratio -of lunar diameter to solar one
- -attr[2] fraction -of solar disc covered by moon (obscuration)
- -attr[3] diameter -of core shadow in km
- -attr[4] azimuth -of sun at tjd
- -attr[5] true -altitude of sun above horizon at tjd
- -attr[6] apparent -altitude of sun above horizon at tjd
- -attr[7] elongation -of moon in degrees
- -attr[8] magnitude acc. to NASA;
- -= attr[0] for -partial and attr[1] for annular and total eclipses
- -attr[9] saros -series number
- -attr[10] saros -series member number
- -*/
- -- -
- -
To find the next -eclipse globally:
- -int32 swe_sol_eclipse_when_glob(
- -double tjd_start, /* start date for search, Jul. day UT */
- -int32 ifl, /* -ephemeris flag */
- -int32 ifltype, /* eclipse type wanted: SE_ECL_TOTAL etc. or 0, if any eclipse -type */
- -double *tret, /* return array, 10 doubles, see below */
- -AS_BOOL backward, /* TRUE, if backward search */
- -char *serr); /* return error string */
- -- -
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_TOTAL ¦ 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.
- -- -
The function returns:
- -- -
/* -retflag -1 (ERR) on error (e.g. if -swe_calc() for sun or moon fails)
- -SE_ECL_TOTAL -or SE_ECL_ANNULAR or SE_ECL_PARTIAL or SE_ECL_ANNULAR_TOTAL
- -SE_ECL_CENTRAL
- -SE_ECL_NONCENTRAL
- -- -
tret[0] time -of maximum eclipse
- -tret[1] time, -when eclipse takes place at local apparent noon
- -tret[2] time -of eclipse begin
- -tret[3] time -of eclipse end
- -tret[4] time -of totality begin
- -tret[5] time -of totality end
- -tret[6] time -of center line begin
- -tret[7] time -of center line end
- -tret[8] time -when annular-total eclipse becomes total not implemented so far
- -tret[9] time -when annular-total eclipse becomes annular again not implemented so far
- -- -
declare as tret[10] at -least !
- -*/
- -- -
To calculate the attributes of an eclipse for a given geographic position -and time:
- -- -
int32 swe_sol_eclipse_how(
- -double -tjd_ut, /* time, Jul. day UT */
- -int32 ifl, /* -ephemeris flag */
- -double -*geopos /* geogr. longitude, latitude, -height above sea
- -* eastern longitude is -positive,
- -* western longitude is negative,
- -* northern latitude is positive,
- -* southern latitude is negative */
- -double -*attr, /* return array, 20 doubles, -see below */
- -char -*serr); /* return error string */
- -- -
/* retflag - -1 (ERR) on error (e.g. if swe_calc() -for sun or moon fails)
- -SE_ECL_TOTAL or SE_ECL_ANNULAR or -SE_ECL_PARTIAL
- -0, -if no eclipse is visible at geogr. position.
- -- -
attr[0] fraction -of solar diameter covered by moon;
- -with total/annular eclipses, it results in -magnitude acc. to IMCCE.
- -attr[1] ratio -of lunar diameter to solar one
- -attr[2] fraction -of solar disc covered by moon (obscuration)
- -attr[3] diameter -of core shadow in km
- -attr[4] azimuth -of sun at tjd
- -attr[5] true -altitude of sun above horizon at tjd
- -attr[6] apparent -altitude of sun above horizon at tjd
- -attr[7] elongation -of moon in degrees
- -attr[8] magnitude acc. to NASA;
- -= attr[0] for -partial and attr[1] for annular and total eclipses
- -attr[9] saros -series number
- -attr[10] saros -series member number
- -- -
- -
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.
- -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.
- -- -
int32 swe_sol_eclipse_where(
- -double tjd_ut, /* time, Jul. day UT */
- -int32 ifl, /* -ephemeris flag */
- -double *geopos, /* return array, 2 doubles, geo. long. and lat.
- -* eastern longitude is positive,
- -* western longitude is negative,
- -* northern latitude is positive,
- -* southern latitude is negative */
- -double *attr, /* return array, 20 doubles, see below */
- -char *serr); /* return error string */
- -The function returns:
- -- -
/* -1 (ERR) on error (e.g. if swe_calc() for sun or moon fails)
- -0 if there is no solar eclipse at tjd
- --SE_ECL_TOTAL
- --SE_ECL_ANNULAR
- --SE_ECL_TOTAL | SE_ECL_CENTRAL
- --SE_ECL_TOTAL | SE_ECL_NONCENTRAL
- --SE_ECL_ANNULAR | SE_ECL_CENTRAL
- -SE_ECL_ANNULAR | SE_ECL_NONCENTRAL
- -SE_ECL_PARTIAL
- -- -
-geopos[0]: geographic longitude -of central line
- --geopos[1]: geographic latitude -of central line
- -- -
-not implemented so far:
- --geopos[2]: geographic longitude -of northern limit of umbra
- --geopos[3]: geographic latitude -of northern limit of umbra
- --geopos[4]: geographic longitude -of southern limit of umbra
- --geopos[5]: geographic latitude -of southern limit of umbra
- --geopos[6]: geographic longitude -of northern limit of penumbra
- --geopos[7]: geographic latitude -of northern limit of penumbra
- --geopos[8]: geographic longitude -of southern limit of penumbra
- --geopos[9]: geographic latitude -of southern limit of penumbra
- -- -
-eastern longitudes are positive,
- --western longitudes are negative,
- --northern latitudes are positive,
- --southern latitudes are negative
- -- -
-attr[0] fraction of solar -diameter covered by the moon
- --attr[1] ratio of lunar diameter -to solar one
- --attr[2] fraction of solar disc -covered by moon (obscuration)
- --attr[3] diameter of core shadow -in km
- --attr[4] azimuth of sun at tjd
- --attr[5] true altitude of sun -above horizon at tjd
- --attr[6] apparent altitude of -sun above horizon at tjd
- --attr[7] angular distance of -moon from sun in degrees
- -attr[8] eclipse -magnitude (= attr[0] or attr[1] depending on eclipse type)
- -attr[9] saros -series number
- -attr[10] saros -series member number
- -- -
declare as attr[20]!
- -*/
- -- -
To find the next occultation of a planet or star -by the moon for a given location, use swe_lun_occult_when_loc().
- -The same -function can also be used for local solar eclipses instead of -swe_sol_eclipse_when_loc(), but is a bit less efficient.
- -- -
/* Same declaration as -swe_sol_eclipse_when_loc().
- -* -In addition:
- -* -int32 ipl planet number of occulted body
- -* -char* starname name of occulted star. Must be NULL or -"", if a planetary
- -* occultation is to be calculated. For use of -this field,
- -* see swe_fixstar().
- -* -int32 ifl ephemeris flag. If you want to have only one conjunction
- -* of the moon with the body tested, add the -following flag:
- -* backward |= SE_ECL_ONE_TRY. If this flag is -not set,
- -* the function will search for an occultation -until it
- -* finds one. For bodies with ecliptical -latitudes > 5,
- -* the function may search successlessly until -it reaches
- -* the end of the ephemeris.
- -*/
- -int32 swe_lun_occult_when_loc(
- -double -tjd_start, /* start date for search, -Jul. day UT */
- -int32 ipl, /* -planet number */
- -char* starname, /* -star name, must be NULL or ”” if not a star */
- -int32 ifl, /* -ephemeris flag */
- -double -*geopos, /* 3 doubles for geo. lon, -lat, height eastern longitude is positive,
- --western longitude is negative, -northern latitude is positive,
- --southern latitude is negative */
- -double -*tret, /* return array, 10 doubles, -see below */
- -double -*attr, /* return array, 20 doubles, -see below */
- -AS_BOOL -backward, /* TRUE, if backward search -*/
- -char -*serr); /* return error string */
- -- -
If an occultation of any planet is wanted, call the function for all planets you want to -consider and find the one with the smallest tret[1] (first contact). (If -searching backward, find the one with the greatest tret[1]). For efficiency, -set ifl |= SE_ECL_ONE_TRY. With this flag, only the next conjunction of the -moon with the bodies is checked. If no occultation has been found, repeat the -calculation with tstart = tstart + 20.
- -- -
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)
- -- -
attr[0] fraction -of solar diameter covered by moon (magnitude)
- -attr[1] ratio -of lunar diameter to solar one
- -attr[2] fraction -of solar disc covered by moon (obscuration)
- -attr[3] diameter -of core shadow in km
- -attr[4] azimuth -of sun at tjd
- -attr[5] true -altitude of sun above horizon at tjd
- -attr[6] apparent -altitude of sun above horizon at tjd
- -attr[7] elongation -of moon in degrees */
- -- -
To find the next occultation of a planet or star -by the moon globally (not for a particular geographic location), use -swe_lun_occult_when_glob().
- -The same -function can also be used for global solar eclipses instead of -swe_sol_eclipse_when_glob(), but is a bit less efficient.
- -- -
/* Same declaration as -swe_sol_eclipse_when_glob().
- -* -In addition:
- -* -int32 ipl planet number of occulted body
- -* -char* starname name of occulted star. Must be NULL or -"", if a planetary
- -* occultation is to be calculated. For use of -this field,
- -* see -swe_fixstar().
- -* -int32 ifl ephemeris flag. If you want to have only one conjunction
- -* of the moon with the body tested, add the -following flag:
- -* backward |= SE_ECL_ONE_TRY. If this flag is -not set,
- -* the function will search for an occultation -until it
- -* finds one. For bodies with ecliptical -latitudes > 5,
- -* the function may search successlessly until -it reaches
- -* the -end of the ephemeris.
- -*/
- -int32 swe_lun_occult_when_glob(
- -double -tjd_start, /* start date for search, -Jul. day UT */
- -int32 ipl, /* -planet number */
- -char* starname, /* -star name, must be NULL or ”” if not a star */
- -int32 ifl, /* -ephemeris flag */
- -int32 ifltype, /* -eclipse type wanted */
- -double -*geopos, /* 3 doubles for geo. lon, -lat, height eastern longitude is positive,
- --western longitude is negative, -northern latitude is positive,
- --southern latitude is negative */
- -double -*tret, /* return array, 10 doubles, -see below */
- -AS_BOOL -backward, /* TRUE, if backward search -*/
- -char -*serr); /* return error string */
- -- -
If an occultation of any planet is wanted, call the function for all planets you want to -consider and find the one with the smallest tret[1] (first contact). (If -searching backward, find the one with the greatest tret[1]). For efficiency, -set ifl |= SE_ECL_ONE_TRY. With this flag, only the next conjunction of the -moon with the bodies is checked. If no occultation has been found, repeat the -calculation with tstart = tstart + 20.
- -- -
The function returns:
- -- -
/* -retflag
- --1 (ERR) on error (e.g. if swe_calc() -for sun or moon fails)
- -0 -(if no occultation / eclipse has been found)
- -SE_ECL_TOTAL -or SE_ECL_ANNULAR or SE_ECL_PARTIAL or SE_ECL_ANNULAR_TOTAL
- -SE_ECL_CENTRAL
- -SE_ECL_NONCENTRAL
- -- -
tret[0] time -of maximum eclipse
- -tret[1] time, -when eclipse takes place at local apparent noon
- -tret[2] time -of eclipse begin
- -tret[3] time -of eclipse end
- -tret[4] time -of totality begin
- -tret[5] time -of totality end
- -tret[6] time -of center line begin
- -tret[7] time -of center line end
- -tret[8] time -when annular-total eclipse becomes total not implemented so far
- -tret[9] time -when annular-total eclipse becomes annular again not implemented so far
- -- -
declare as tret[10] at -least !
- -*/
- -- -
- -
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.
- -- -
int32 swe_lun_occult_where (
- -double tjd_ut, /* time, Jul. day UT */
- -int32 ipl, /* -planet number */
- -char* starname, /* -star name, must be NULL or ”” if not a star */
- -int32 ifl, /* -ephemeris flag */
- -double *geopos, /* return array, 2 doubles, geo. long. and lat.
- -* eastern longitude is positive,
- -* western longitude is negative,
- -* northern latitude is positive,
- -* southern latitude is negative */
- -double *attr, /* return array, 20 doubles, see below */
- -char *serr); /* return error string */
- -The function returns:
- -- -
/* -1 (ERR) on error (e.g. if swe_calc() for sun or moon fails)
- -0 if there is no solar eclipse (occultation) -at tjd
- --SE_ECL_TOTAL
- --SE_ECL_ANNULAR
- --SE_ECL_TOTAL | SE_ECL_CENTRAL
- --SE_ECL_TOTAL | SE_ECL_NONCENTRAL
- --SE_ECL_ANNULAR | SE_ECL_CENTRAL
- -SE_ECL_ANNULAR | SE_ECL_NONCENTRAL
- -SE_ECL_PARTIAL
- -- -
-geopos[0]: geographic longitude -of central line
- --geopos[1]: geographic latitude -of central line
- -- -
-not implemented so far:
- --geopos[2]: geographic longitude -of northern limit of umbra
- --geopos[3]: geographic latitude -of northern limit of umbra
- --geopos[4]: geographic longitude -of southern limit of umbra
- --geopos[5]: geographic latitude -of southern limit of umbra
- --geopos[6]: geographic longitude -of northern limit of penumbra
- --geopos[7]: geographic latitude -of northern limit of penumbra
- --geopos[8]: geographic longitude -of southern limit of penumbra
- --geopos[9]: geographic latitude -of southern limit of penumbra
- -- -
-eastern longitudes are positive,
- --western longitudes are negative,
- --northern latitudes are positive,
- --southern latitudes are negative
- -- -
-attr[0] fraction of solar -diameter covered by moon (magnitude)
- --attr[1] ratio of lunar diameter -to solar one
- --attr[2] fraction of solar disc -covered by moon (obscuration)
- --attr[3] diameter of core shadow -in km
- --attr[4] azimuth of sun at tjd
- --attr[5] true altitude of sun -above horizon at tjd
- --attr[6] apparent altitude of -sun above horizon at tjd
- --attr[7] angular distance of -moon from sun in degrees
- -- -
declare as attr[20]!
- -*/
- -To find the next -lunar eclipse:
- -- -
int32 swe_lun_eclipse_when(
- -double tjd_start, /* start date for search, Jul. day UT */
- -int32 ifl, /* -ephemeris flag */
- -int32 ifltype, /* eclipse type wanted: SE_ECL_TOTAL etc. or 0, if any eclipse type */
- -double *tret, /* return array, 10 doubles, see below */
- -AS_BOOL backward, /* TRUE, if backward search */
- -char *serr); /* return error string */
- -- -
Recommended -values for ifltype:
- -/* search for any lunar eclipse, no matter which type */
- -ifltype = -0;
- -/* search -a total lunar eclipse */
- -ifltype = -SE_ECL_TOTAL;
- -/* search -a partial lunar eclipse */
- -ifltype = -SE_ECL_PARTIAL;
- -/* search -a penumbral lunar eclipse */
- -ifltype = -SE_ECL_PENUMBRAL;
- -- -
If your code -does not work, please study the sample code in swetest.c.
- -- -
The function returns:
- -- -
/* retflag -1 (ERR) on error (e.g. if swe_calc() for sun or moon fails)
- -SE_ECL_TOTAL -or SE_ECL_PENUMBRAL or SE_ECL_PARTIAL
- --tret[0] time of maximum eclipse
- --tret[1]
- --tret[2] time of partial phase -begin (indices consistent with solar eclipses)
- --tret[3] time of partial phase -end
- --tret[4] time of totality begin
- --tret[5] time of totality end
- --tret[6] time of penumbral phase -begin
- --tret[7] time of penumbral phase -end
- -*/
- -- -
- -
This function computes the attributes of a lunar eclipse at a given time:
- -- -
int32 swe_lun_eclipse_how(
- -double tjd_ut, /* time, Jul. day UT */
- -int32 ifl, /* -ephemeris flag */
- -double *geopos, /* input array, geopos, geolon, geoheight
- -eastern longitude is positive,
- -western longitude is negative,
- -northern latitude is positive,
- -southern latitude is negative */
- -double *attr, /* return array, 20 doubles, see below */
- -char *serr); /* return error string */
- -- -
The function returns:
- -- -
/* retflag -1 (ERR) on error (e.g. if swe_calc() for sun or moon fails)
- -SE_ECL_TOTAL -or SE_ECL_PENUMBRAL or SE_ECL_PARTIAL
- -0 -if there is no eclipse
- -- -
attr[0] umbral -magnitude at tjd
- -attr[1] penumbral -magnitude
- -attr[4] azimuth -of moon at tjd. Not implemented so far
- -attr[5] true -altitude of moon above horizon at tjd. Not implemented so far
- -attr[6] apparent -altitude of moon above horizon at tjd. Not implemented so far
- -attr[7] distance -of moon from opposition in degrees
- -attr[8] eclipse magnitude (= attr[0])
- -attr[9] saros series number
- -attr[10] saros series member number
- -- -
-declare -as attr[20] at least !
- -*/
- -- -
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. Their definitions are as follows:
- -- -
int32 swe_rise_trans(
- -double tjd_ut, /* search after this time (UT) */
- -int32 ipl, /* planet number, if -planet or moon */
- -char *starname, /* star name, if star */
- -int32 epheflag, /* ephemeris flag */
- -int32 rsmi, /* integer specifying -that rise, set, orone of the two meridian transits is
- -wanted. see definition below */
- -double *geopos, /* array of three doubles containing
- -* geograph. long., lat., height of observer -*/
- -double atpress, /* atmospheric pressure in mbar/hPa */
- -double attemp, /* atmospheric temperature in deg. C */
- -double *tret, /* return address -(double) for rise time etc. */
- -char *serr); /* return address for -error message */
- -- -
int32 swe_rise_trans_true_hor(
- -double tjd_ut, /* search after this time (UT) */
- -int32 ipl, /* planet number, if -planet or moon */
- -char *starname, /* star name, if star */
- -int32 epheflag, /* ephemeris flag */
- -int32 rsmi, /* integer specifying -that rise, set, orone of the two meridian transits is
- -wanted. see definition below */
- -double *geopos, /* array of three doubles containing
- -* geograph. long., lat., height of observer -*/
- -double atpress, /* atmospheric pressure in mbar/hPa */
- -double attemp, /* atmospheric temperature in deg. C */
- -double horhgt, /* height of local horizon in deg at the point where the body -rises or sets*/
- -double *tret, /* return address -(double) for rise time etc. */
- -char *serr); /* return address for -error message */
- -- -
The second function has one -additional parameter horhgt for the height of the local horizon at the point -where the body rises or sets.
- -- -
The variable -rsmi can have the following values:
- -- -
/* -for swe_rise_transit() and swe_rise_transit_true_hor() */
- -#define SE_CALC_RISE 1
- -#define SE_CALC_SET 2
- -#define -SE_CALC_MTRANSIT 4 /* upper meridian transit (southern for -northern geo. latitudes) */
- -#define -SE_CALC_ITRANSIT 8 /* lower meridian transit (northern, below -the horizon) */
- -/* -the following bits can be added (or’ed) to SE_CALC_RISE or SE_CALC_SET */
- -#define -SE_BIT_DISC_CENTER 256 /* for rising or setting of disc center -*/
- -#define SE_BIT_DISC_BOTTOM -8192 /* for rising or setting -of lower limb of disc */
- -#define -SE_BIT_NO_REFRACTION 512 /* if refraction is not to be -considered */
- -#define -SE_BIT_CIVIL_TWILIGHT 1024 /* in order to calculate civil twilight -*/
- -#define -SE_BIT_NAUTIC_TWILIGHT 2048 /* -in order to calculate nautical twilight */
- -#define -SE_BIT_ASTRO_TWILIGHT 4096 /* in order to calculate astronomical -twilight */
- -#define SE_BIT_FIXED_DISC_SIZE (16*1024) /* neglect the effect of -distance on disc size */
- -- -
rsmi = 0 will return risings.
- -The rising times depend on the atmospheric pressure and temperature. atpress expects the atmospheric pressure in millibar (hectopascal); attemp the temperature in degrees Celsius.
- -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.
- -- -
- -
- -
These functions compute phase, phase angle, elongation, apparent diameter, -apparent magnitude for the Sun, the Moon, all planets and asteroids. The -two functions do exactly the same but expect a different time parameter.
- -- -
int32 swe_pheno_ut(
- -double tjd_ut, /* time Jul. Day UT */
- -int32 ipl, /* planet number */
- -int32 iflag, /* -ephemeris flag */
- -double *attr, /* return array, 20 doubles, see below */
- -char *serr); /* return error string */
- -- -
int32 swe_pheno(
- -double tjd_et, /* time Jul. Day ET */
- -int32 ipl, /* planet number */
- -int32 iflag, /* ephemeris flag */
- -double *attr, /* return array, 20 doubles, see below */
- -char *serr); /* return error string */
- -- -
The function returns:
- -/*
- --attr[0] = phase angle (earth-planet-sun)
- --attr[1] = phase (illumined fraction of disc)
- --attr[2] = elongation of planet
- --attr[3] = apparent diameter of disc
- --attr[4] = apparent magnitude
- -- -
-declare -as attr[20] at least !
- -- -
-Note: the lunar magnitude is quite a complicated thing,
- --but our algorithm is very simple.
- --The phase of the moon, its distance from the earth and
- --the sun is considered, but no other factors.
- -- -
iflag also allows SEFLG_TRUEPOS, SEFLG_HELCTR
- -*/
- -- -
- -
swe_azalt()computes the horizontal coordinates -(azimuth and altitude) of a planet or a star from either ecliptical or -equatorial coordinates.
- -- -
void swe_azalt(
- -double tjd_ut, // -UT
- --int32 calc_flag, // SE_ECL2HOR or SE_EQU2HOR
- -double *geopos, // array of 3 doubles: geograph. long., -lat., height
- -double atpress, // atmospheric pressure in mbar (hPa)
- -double attemp, // atmospheric temperature in degrees -Celsius
- -double *xin, // array of 3 doubles: position of body in -either ecliptical or equatorial -coordinates,
- -// depending on calc_flag
- -double *xaz); // return array of 3 doubles, containing -azimuth, true altitude, apparent altitude
- -- -
If calc_flag=SE_ECL2HOR, -set xin[0]= ecl. long., xin[1]= ecl. lat., (xin[2]=distance (not required));
- -else
- -if calc_flag= -SE_EQU2HOR, set xin[0]=rectascension, xin[1]=declination, (xin[2]= distance -(not required));
- -- -
#define -SE_ECL2HOR 0
- -#define -SE_EQU2HOR 1
- -- -
The return values are:
- -xaz[0] = azimuth, -i.e. position degree, measured from the south point to west.
- -xaz[1] = true altitude -above horizon in degrees.
- -xaz[2] = apparent (refracted) altitude -above horizon in degrees.
- -- -
The apparent altitude of a body -depends on the atmospheric pressure and temperature. If only the true altitude -is required, these parameters can be neglected.
- -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.
- -- -
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).
- -It is defined as follows:
- -- -
void swe_azalt_rev(
- --double tjd_ut,
- -int32 calc_flag, /* either SE_HOR2ECL or SE_HOR2EQU */
- --double *geopos, /* array of 3 -doubles for geograph. pos. of observer */
- --double *xin, /* array of 2 doubles for azimuth and true -altitude of planet */
- --double *xout); // return array -of 2 doubles for either ecliptic or
- -// -equatorial coordinates, depending on calc_flag
- -- -
For the definition of the azimuth -and true altitude, see chapter 4.9 on swe_azalt().
- -#define -SE_HOR2ECL 0
- -#define -SE_HOR2EQU 1
- -The refraction -function swe_refrac()calculates either the true altitude from -the apparent altitude or the apparent altitude from the apparent altitude. Its -definition is:
- -- -
double swe_refrac(
- -double inalt,
- -double atpress, /* atmospheric pressure in mbar (hPa) */
- -double attemp, /* atmospheric temperature in degrees Celsius */
- -int32 calc_flag); /* either SE_TRUE_TO_APP or SE_APP_TO_TRUE */
- -where
- -#define SE_TRUE_TO_APP 0
- -#define SE_APP_TO_TRUE 1
- -- -
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!)
- -- -
double swe_refract_extended(
- -double inalt, /* altitude of object above geometric horizon in degrees, where
- -geometric horizon = plane perpendicular to -gravity */
- -double geoalt, /* altitude of observer above sea level in meters */
- -double atpress, /* atmospheric pressure in mbar (hPa) */
- -double lapse_rate, /* (dattemp/dgeoalt) = [°K/m] */
- -double attemp, /* atmospheric temperature in degrees Celsius */
- -int32 calc_flag); /* either SE_TRUE_TO_APP or SE_APP_TO_TRUE */
- -- -
function returns:
- -case 1, conversion from true -altitude to apparent altitude:
- -- apparent altitude, if body appears -above is observable above ideal horizon
- -- true altitude (the input value), -otherwise
- --"ideal horizon" is the horizon as seen above an ideal sphere -(as seen from a plane over the ocean with
- --a clear sky)
- -case 2, conversion from apparent -altitude to true altitude:
- -- the true altitude resulting from -the input apparent altitude, if this value is a plausible apparent altitude,
- --i.e. if it is a position above the ideal horizon
- -- the input altitude otherwise
- -- -
in addition the array dret[] returns -the following values
- -- dret[0] true altitude, if -possible; otherwise input value
- -- dret[1] apparent altitude, if -possible; otherwise input value
- -- dret[2] refraction
- -- dret[3] dip of the horizon
- -- -
The body is above the horizon if the -dret[0] != dret[1]
- -- -
The function swe_heliacal_ut()the Julian day of the next heliacal -phenomenon after a given start date. It works between geographic latitudes 60s -– 60n.
- -- -
int32 swe_heliacal_ut(
- -double tjdstart, /* Julian day number of start date for the search of the -heliacal event */
- -double *dgeo /* geographic position (details below) */
- -double *datm, /* atmospheric conditions (details below) */
- -double *dobs, /* observer description (details below) */
- -char *objectname, /* name string of fixed star or planet -*/
- -int32 event_type, /* event type (details below) */
- -int32 helflag, /* calculation flag, bitmap (details below) */
- -double *dret, /* result: array of at least 50 doubles, of which 3 are used at -the moment */
- -char * serr /* error string */
- -);
- -- -
Function -returns OK or ERR
- -- -
Details for dgeo[] (array of -doubles):
- -dgeo[0]: geographic longitude
- -dgeo[1]: geographic latitude
- -dgeo[2]: geographic altitude (eye -height) in meters
- -- -
Details for datm[] (array of -doubles):
- -datm[0]: atmospheric pressure in mbar -(hPa)
- -datm[1]: atmospheric temperature in -degrees Celsius
- -datm[2]: relative humidity in %
- -datm[3]: if datm[3]>=1, then it is -Meteorological Range [km]
- -- if 1>datm[3]>0, -then it is the total atmsopheric coeffcient (ktot)
- -datm[3]=0, then the -other atmospheric parameters determine the total
- -- atmsopheric coeffcient (ktot)
- -Default values:
- -If this is too much for you, set all -these values to 0. The software will then set the following defaults:
- -Pressure 1013.25, temperature 15, -relative humidity 40. The values will be modified depending
- -on the altitude of the observer above -sea level.
- -If the extinction coefficient -(meteorological range) datm[3] is 0, the software will calculate its value
- -from datm[0..2].
- -- -
Details for dobs[] (array of -doubles):
- -dobs[0]: age of observer in years (default = 36)
- -dobs[1]: Snellen ratio of observers -eyes (default = 1 = normal)
- -The -following parameters are only relevant if the flag SE_HELFLAG_OPTICAL_PARAMS is -set:
- -dobs[2]: 0 = monocular, 1 = binocular -(actually a boolean)
- -dobs[3]: telescope magnification: 0 = -default to naked eye (binocular), 1 = naked eye
- -dobs[4]: optical aperture (telescope -diameter) in mm
- -dobs[5]: optical transmission
- -- -
Details for event_type:
- -event_type = SE_HELIACAL_RISING (1): -morning first (exists for all visible planets and stars)
- -event_type = SE_HELIACAL_SETTING (2): -evening last (exists for all visible planets and stars)
- -event_type = SE_EVENING_FIRST (3): -evening first (exists for Mercury, Venus, and the Moon)
- -event_type = SE_MORNING_LAST (4): -morning last (exists for Mercury, Venus, and the Moon)
- -- -
Details for helflag:
- -helflag contains ephemeris flag, like -iflag in swe_calc() etc. In addition it can contain the following bits:
- -SE_HELFLAG_LONG_SEARCH (128): A -heliacal event is searched until found.
- -If this bit is NOT set and no -event is found within 5 synodic periods, the function stops
- -searching and returns ERR.
- -SE_HELFLAG_HIGH_PRECISION (256): More -rigorous but also slower algorithms are used
- -SE_HELFLAG_OPTICAL_PARAMS (512): Use -this with calculations for optical instruments.
- -Unless this bit is set, the -values of dobs[2-5] are ignored.
- -SE_HELFLAG_NO_DETAILS (1024): provide -the date, but not details like visibility start, optimum, and end.
- -This bit makes the program a bit -faster.
- -- -
Details for return array dret[] -(array of doubles):
- -dret[0]: start visibility (Julian day -number)
- -dret[1]: optimum visibility (Julian -day number)
- -dret[2]: end of visibility (Julian day -number)
- -- -
The function swe_vis_lim_mag()determines the limiting visual magnitude -in dark skies:
- -- -
double swe_vis_limit_mag(
- -double tjdut, /* Julian day number */
- -double *dgeo /* geographic position (details under -swe_heliacal_ut() */
- -double *datm, /* atmospheric conditions (details under swe_heliacal_ut()) */
- -double *dobs, /* observer description (details under swe_heliacal_ut()) */
- -char *objectname, /* name string of fixed star or planet -*/
- -int32 helflag, /* calculation flag, bitmap (details under swe_heliacal_ut()) */
- -double *dret, /* result: magnitude required of the object to be visible */
- -char * serr /* error string */
- -);
- -- -
Function -returns
- --1 on -error
- --2 object -is below horizon
- -0 OK, -photopic vision
- -&1 OK, scotopic vision
- -&2 OK, near limit photopic/scotopic vision
- -- -
These functions are needed to -convert calendar dates to the astronomical time scale which measures time in -Julian days.
- -double swe_julday(int -year, int month, int day, double hour, int gregflag);
- -- -
int swe_date_conversion -(
- -int -y , int m , int d , /* year, month, -day */
- -- double hour, /* hours (decimal, with fraction) */
- -- char c, /* -calendar ‘g’[regorian]|’j’[ulian] */
- -double -*tjd); /* return value for -Julian day */
- -- -
void swe_revjul -(
- -double -tjd, /* -Julian day number */
- -int -gregflag, /* Gregorian calendar: 1, Julian calendar: 0 */
- -int -*year, /* -target addresses for year, etc. */
- -int -*month, int *day, double *hour);
- -- -
swe_julday()and swe_date_conversion() compute a Julian -day number from year, month, day, and hour. swe_date_conversion()checks in addition whether -the date is legal. It returns OK or ERR.
- -swe_revjul() is the reverse function of -swe_julday().It computes year, month, day and hour from a Julian day -number.
- -- -
The variable gregflag tells the function whether the input date is Julian calendar ( gregflag = SE_JUL_CAL) or Gregorian calendar ( gregflag = SE_GREG_CAL).
- -Usually, you will set gregflag= SE_GREG_CAL.
- -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)
- -* an error -message (on error)
- -* The function returns OK or ERR.
- -*/ -
- -int32 swe_utc_to_jd (
- -int32 -iyear, int32 imonth, int32 iday,
- -int32 ihour, int32 imin, double -dsec, /* note : second is a -decimal */
- -gregflag, /* Gregorian calendar: 1, Julian calendar: 0 */
- -dret /* -return array, two doubles:
- -* dret[0] = Julian day in ET (TT)
- -* dret[1] = Julian day in UT (UT1) */
- -serr /* -error string */
- -)
- -- -
/* input: Julian day number in ET (TT), -calendar flag
- -* -output: year, month, day, hour, min, sec in UTC */
- -void swe_jdet_to_utc (
- -double tjd_et, /* Julian day number in ET (TT) */
- -gregflag, /* Gregorian calendar: 1, Julian calendar: 0 */
- -int32 *iyear, -int32 *imonth, int32 *iday,
- -int32 *ihour, int32 *imin, double -*dsec, /* note : second is a -decimal */
- -)
- -- -
/* input: Julian day number in UT (UT1), -calendar flag
- -* -output: year, month, day, hour, min, sec in UTC */
- -void swe_jdut1_to_utc (
- -double tjd_ut, /* Julian day number in ET (TT) */
- -gregflag, /* Gregorian calendar: 1, Julian calendar: 0 */
- -int32 *iyear, -int32 *imonth, int32 *iday,
- -int32 *ihour, int32 *imin, double -*dsec, /* note : second is a -decimal */
- -)
- -- -
How do I get correct planetary -positions, sidereal time, and house cusps, starting from a wall clock date and -time?
- -- -
int32 -iday, imonth, iyear, ihour, imin, retval;
- -int32 gregflag = SE_GREG_CAL;
- -double d_timezone = 5.5 ; /* time zone = Indian Standard Time; note: -east is positive */
- -double dsec, tjd_et, tjd_ut;
- -double dret[2];
- -char serr[256];
- -…
- -/* if -date and time is in time zone different from UTC, the time zone offset must be -subtracted
- -* first in order to get UTC: */
- -swe_utc_time_zone(iyear, imonth, iday, ihour, imin, dsec, d_timezone,
- -&iyear_utc, -&imonth_utc, &iday_utc, &ihour_utc, &imin_utc, &dsec_utc)
- -/* -calculate Julian day number in UT (UT1) and ET (TT) from UTC */
- -retval = -swe_utc_to_jd (iyear_utc, imonth_utc, iday_utc, -ihour_utc, imin_utc, dsec_utc, gregflag, dret, serr);
- -if (retval == ERR) {
- -fprintf(stderr, -serr); /* error handling */
- -}
- -tjd_et = dret[0]; /* this is ET (TT) */
- -tjd_ut = dret[1]; /* this is UT (UT1) */
- -/* calculate planet with tjd_et */
- -swe_calc(tjd_et, -…);
- -/* calculate houses with tjd_ut */
- -swe_houses(tjd_ut, …)
- -- -
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().
- -…
- -/* first, we calculate UTC from TT (ET) */
- -swe_jdet_to_utc(tjd_et, gregflag, -&iyear_utc, &imonth_utc, &iday_utc, &ihour_utc, &imin_utc, -&dsec_utc);
- -/* now, UTC to local time (note the -negative sign before d_timezone): */
- -swe_utc_time_zone(iyear_utc, imonth_utc, iday_utc, ihour_utc, imin_utc, -dsec_utc,
- --d_timezone, &iyear, &imonth, &iday, &ihour, &imin, -&dsec)
- -- -
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
- -# yyyymmdd, e.g. "20081231" for -21 december 2008
- -20081231
- -- -
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 birth time of a historical -person 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).
- -- -
There is a function for computing -the correction value.
- -- -
/* equation of time function returns the -difference between local apparent and local mean time.
- -e = LAT – LMT. tjd is ephemeris time */
- -int swe_time_equ(double -tjd, double* -e, char* serr);
- -- -
If you first compute tjd on the basis of the registered Local Apparent Time, you convert it to Local Mean Time -with:
- -tjd_mean = tjd_app + e;
- -- -
/* delta t from Julian day number */
- -double swe_deltat(double tjd);
- -/* get tidal acceleration used in -swe_deltat() */
- -double swe_get_tid_acc(void); -
- -/* set tidal acceleration to be used in -swe_deltat() */
- -void swe_set_tid_acc(double -t_acc);
- -- -
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):
- -tjde = tjd + swe_deltat(tjd); where tjd = Julian day in UT, tjde= in 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
- -- -
swe_set_tid_acc(acceleration); // Do this before calling deltat() !
- -- -
The values that acceleration can have are listed in swephexp.h. (e.g. SE_TIDAL_200, etc.)
- -To find out the built-in value of -the tidal acceleration, you can call
- -acceleration = swe_get_tidacc();
- -- -
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
- -# table of the Swiss Ephemeris.
- -# Format: year and seconds (decimal)
- -2003 64.47
- -2004 65.80
- -2005 66.00
- -2006 67.00
- -2007 68.00
- -2008 68.00
- -2009 69.00
- -- -
void swe_set_topo(double -geolon, -double geolat, double altitude);
- -/* eastern longitude is positive, western longitude is negative,
- -northern latitude is positive, -southern latitude is negative */
- -- -
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.:
- -- -
swe_set_topo(geo_lon, geo_lat, altitude_above_sea);
- -iflag | = SEFLG_TOPOCTR;
- -- -
for (i = 0; i -< NPLANETS; i++) {
- -iflgret = swe_calc( tjd, ipl, iflag, xp, -serr );
- -printf(”%f\n”, xp[0]);
- -}
- -- -
The parameters set by swe_set_topo() survive swe_close().
- -- -
void swe_set_sid_mode (int32 sid_mode, double t0, -double ayan_t0);
- -- -
This function can be used to specify -the mode for sidereal computations.
- -swe_calc() or swe_fixstar() has then to be called with the bit SEFLG_SIDEREAL.
- -If swe_set_sid_mode() is not called, the default ayanamsha(Fagan/Bradley) is used.
- -If a predefined mode is wanted, the -variable sid_modehas to be set, while t0 and ayan_t0 are not considered, i.e. can be 0. The predefined sidereal modes are:
- -- -
#define SE_SIDM_FAGAN_BRADLEY 0
- -#define SE_SIDM_LAHIRI 1
- -#define SE_SIDM_DELUCE 2
- -#define SE_SIDM_RAMAN 3
- -#define SE_SIDM_USHASHASHI 4
- -#define SE_SIDM_KRISHNAMURTI 5
- -#define SE_SIDM_DJWHAL_KHUL 6
- -#define SE_SIDM_YUKTESHWAR 7
- -#define SE_SIDM_JN_BHASIN 8
- -#define SE_SIDM_BABYL_KUGLER1 9
- -#define SE_SIDM_BABYL_KUGLER2 10
- -#define SE_SIDM_BABYL_KUGLER3 11
- -#define SE_SIDM_BABYL_HUBER 12
- -#define SE_SIDM_BABYL_ETPSC 13
- -#define SE_SIDM_ALDEBARAN_15TAU 14
- -#define SE_SIDM_HIPPARCHOS 15
- -#define SE_SIDM_SASSANIAN 16
- -#define SE_SIDM_GALCENT_0SAG 17
- -#define SE_SIDM_J2000 18
- -#define SE_SIDM_J1900 19
- -#define SE_SIDM_B1950 20
- -#define SE_SIDM_SURYASIDDHANTA 21
- -#define SE_SIDM_SURYASIDDHANTA_MSUN 22
- -#define SE_SIDM_ARYABHATA 23
- -#define SE_SIDM_ARYABHATA_MSUN 24
- -#define -SE_SIDM_USER 255
- -- -
For information about the sidereal -modes, read the chapter on sidereal calculations in swisseph.doc.
- -To define your own sidereal mode, -use SE_SIDM_USER (= 255) and set the reference date (t0) and the initial value of theayanamsha -(ayan_t0).
- -ayan_t0 = -tropical_position_t0 – sidereal_position_t0.
- -Without additional specifications, -the traditional method is used. The ayanamsha measured on the ecliptic of t0 is subtracted from tropical -positions referred to the ecliptic of date.
- -- -
Note, this method will NOT provide -accurate results if you want coordinates referred to the ecliptic of one of the -following equinoxes:
- -#define SE_SIDM_J2000 18
- -#define SE_SIDM_J1900 19
- -#define SE_SIDM_B1950 20
- -Instead, -you have to use a correct coordinate transformation as described in the -following:
- -- -
Special uses of the sidereal functions:
- -- -
a) correct transformation of ecliptic coordinates to the ecliptic of -a particular date
- -- -
If a correct transformation to the -ecliptic of t0 is required the following bit can be added (‘ored’) to -the value of the variable sid_mode:
- -- -
/* for projection onto ecliptic of t0 */
- -#define -SE_SIDBIT_ECL_T0 256
- -E.g.:
- -swe_set_sid_mode(SE_SIDM_J2000 + SE_SIDBIT_ECL_T0, 0, 0);
- -iflag |= -SEFLG_SIDEREAL;
- -for (i = 0; i -< NPLANETS; i++) {
- -iflgret = swe_calc(tjd, ipl, iflag, xp, -serr);
- -printf(”%f\n”, xp[0]);
- -}
- -- -
This procedure is required for the -following sidereal modes, i.e. for transformation to the ecliptic of one of the -standard equinoxes:
- -#define SE_SIDM_J2000 18
- -#define SE_SIDM_J1900 19
- -#define SE_SIDM_B1950 20
- -- -
b) calculating precession-corrected transits
- -- -
The function swe_set_sidmode() can also be used for calculating ”precession-corrected transits”. -There are two methods, of which you have to choose the one that is more -appropriate for you:
- -- -
1. If you already have tropical -positions of a natal chart, you can proceed as follows:
- -- -
iflgret = swe_calc(tjd_et_natal, SE_ECL_NUT, 0, x, serr);
- -nut_long_nata = x[2];
- -swe_set_sid_mode( SE_SIDBIT_USER + SE_SIDBIT_ECL_T0, -tjd_et, nut_long_natal );
- -- -
where tjd_et_natal is the Julian day of the natal chart (Ephemeris time).
- -After this calculate the transits, -using the function swe_calc() with the sidereal bit:
- -- -
iflag |= -SEFLG_SIDEREAL;
- -iflgret = -swe_calc(tjd_et_transit, ipl_transit, iflag, xpt, serr);
- -- -
2. If you do not -have tropical natal positions yet, if you do not need them and are just -interested in transit times, you can have it simpler:
- -swe_set_sid_mode( SE_SIDBIT_USER + SE_SIDBIT_ECL_T0, -tjd_et, 0 );
- -iflag |= -SEFLG_SIDEREAL;
- -iflgret = swe_calc(tjd_et_natal, ipl_natal, iflag, xp, serr);
- -iflgret = swe_calc(tjd_et_transit, ipl_transit, iflag, xpt, serr);
- -- -
In this case, the -natal positions will be tropical but without nutation. Note that you should not -use them for other purposes.
- -- -
c) solar system rotation plane
- -- -
For sidereal positions referred to -the solar system rotation plane, use the flag
- -- -
/* for projection onto solar system -rotation plane */
- -#define SE_SIDBIT_SSY_PLANE 512
- -- -
Note: the parameters set by swe_set_sid_mode() survive calls of the function swe_close().
- -double swe_get_ayanamsa_ut(double -tjd_ut);
- -double swe_get_ayanamsa(double -tjd_et);
- -- -
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.
- -int swe_set_ephe_path(char -*path);
- -- -
Usually an application will want to -set its own ephemeris path by calling swe_set_ephe_path(), e.g.
- -swe_set_ephe_path(”C:\\SWEPH\\EPHE”);
- -- -
The argument can be a single
-directory name or a list of directories, which are then searched in sequence.
-The argument of this call is ignored if the environment variable SE_EPHE_PATH exists and is not empty.
-If you want to make sure that your program overrides
-any environment variable setting, you can use putenv() to
-set it to an empty string.
- -
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.
- -/* close Swiss Ephemeris */
- -void swe_close(void);
- -- -
At the end of your computations you -can release most resources (open files and allocated memory) used by the Swiss -Ephemeris DLL.
- -The following parameters survive a -call of swe_calc():
- -· -the ephemeris path set by swe_set_ephe_path()
- -· -the JPL file name set by swe_set_jpl_file()
- -· -the geographical location set by swe_set_topo() for topocentric planetary positions
- -· -the sidereal mode set by swe_set_sid_mode() for sidereal planetary positions
- -- -
As soon as you make a call to swe_calc() or swe_fixstar(), the Swiss Ephemeris -re-opens again.
- -- -
/* set name of JPL ephemeris file */
- -int swe_set_jpl_file(char -*fname);
- -- -
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”.
- -If 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.
- -- -
- -
/* find out version number of your Swiss -Ephemeris version */
- -char *swe_version(char *svers);
- -/* svers is a string variable with -sufficient space to contain the version number (255 char) */
- -- -
The Function returns a pointer to the string -svers, i.e. to the version number of the Swiss Ephemeris that your software is -using.
- -- -
/* house cusps, ascendant and MC */
- -int swe_houses(
- -double tjd_ut, /* Julian day number, UT */
- -double geolat, /* geographic latitude, in degrees */
- -double geolon, /* geographic longitude, in degrees
- -* eastern longitude is positive,
- -* western longitude is negative,
- -* northern latitude is positive,
- -* southern latitude is negative */
- -int hsys, /* house method, ascii code of one of the -letters PKORCAEVXHTBG */
- -double *cusps, /* array for 13 doubles */
- -double *ascmc); /* array for 10 doubles */
- -int swe_houses_armc(
- -double armc, /* ARMC */
- -double geolat, /* geographic latitude, in degrees */
- -double eps, /* ecliptic obliquity, in -degrees */
- -int hsys, /* house method, ascii code of one of the -letters PKORCAEVXHTBG */
- -double *cusps, /* array for 13 doubles */
- -double *ascmc); /* array for 10 doubles */
- -- -
/* extended function; to compute tropical -or sidereal positions */
- -int swe_houses_ex(
- -double -tjd_ut, /* Julian day number, UT */
- -int32 -iflag, /* -0 or SEFLG_SIDEREAL or SEFLG_RADIANS */
- -double -geolat, /* geographic latitude, in -degrees */
- -double -geolon, /* geographic longitude, in -degrees
- -* eastern longitude is positive,
- -* western longitude is negative,
- -* northern latitude is positive,
- -* southern latitude is negative */
- -int -hsys, /* house method, ascii code of one of the letters PKORCAEVXHTBG -*/
- -double -*cusps, /* array for 13 doubles */
- -double *ascmc); /* array for 10 doubles */
- -- -
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 no extended function for swe_houses_armc(). Therefore, if you want to compute such -obscure things as sidereal composite house cusps, the procedure will be -more complicated:
- -- -
/* sidereal composite house computation; -with true epsilon, but without nutation in longitude */
- -swe_calc(tjd_et1, SE_ECL_NUT, 0, x1, serr);
- -swe_calc(tjd_et2, SE_ECL_NUT, 0, x2, serr);
- -armc1 = swe_sidtime(tjd_ut1) * 15;
- -armc2 = swe_sidtime(tjd_ut2) * 15;
- -armc_comp = composite(armc1, -armc2); /* this is a function created by the user */
- -eps_comp = (x1[0] + x2[0]) / 2;
- -nut_comp = -(x1[2] + x2[2]) / 2;
- -tjd_comp = -(tjd_et1 + tjd_et2) / 2;
- -aya = swe_get_ayanamsa(tjd_comp);
- -swe_houses_armc(armc_comp, geolat, eps_comp, hsys, cusps, ascmc);
- -for (i = 1; i -<= 12; i++)
- -cusp[i] = swe_degnorm(cusp[i] – aya – -nut_comp);
- -for (i = 0; i -< 10; i++)
- -ascmc[i] = swe_degnorm(asc_mc[i] – -aya – nut_comp);
- -- -
Output and input parameters.
- -The first array element cusps[0] -is always 0, the twelve houses follow in cusps[1] .. [12], the reason -being that arrays in C begin with the index 0. The indices are therefore:
- -cusps[0] = 0
- -cusps[1] = house 1
- -cusps[2] = house 2
- -etc.
- -- -
In the array ascmc, the function returns the following -values:
- -ascmc[0] = Ascendant
- -ascmc[1] = MC
- -ascmc[2] = ARMC
- -ascmc[3] = Vertex
- -ascmc[4] = "equatorial ascendant"
- -ascmc[5] = "co-ascendant" (Walter Koch)
- -ascmc[6] = "co-ascendant" (Michael Munkasey)
- -ascmc[7] = "polar ascendant" (M. Munkasey)
- -- -
The following defines can be used to find these -values:
- -#define SE_ASC 0
- -#define SE_MC 1
- -#define SE_ARMC 2
- -#define -SE_VERTEX 3
- -#define -SE_EQUASC 4 /* "equatorial ascendant" */
- -#define -SE_COASC1 5 /* -"co-ascendant" (W. Koch) */
- -#define -SE_COASC2 6 /* -"co-ascendant" (M. Munkasey) */
- -#define -SE_POLASC 7 /* "polar -ascendant" (M. Munkasey) */
- -#define -SE_NASCMC 8
- -- -
ascmcmust be an array of 10 doubles. -ascmc[8... 9] are 0 and may -be used for additional points in future releases.
- -- -
The following house systems are -implemented so far
- -hsys = ‘P’ Placidus
- -‘K’ Koch
- -‘O’ Porphyrius
- -‘R’ Regiomontanus
- -‘C’ Campanus
- -‘A’ or ‘E’ Equal (cusp 1 is Ascendant)
- -‘V’ Vehlow -equal (Asc. in middle of house 1)
- -‘W’ Whole sign
- -‘X’ axial -rotation system / meridian system / zariel
- -‘H’ azimuthal -or horizontal system
- -‘T’ Polich/Page -(“topocentric” system)
- -‘B’ Alcabitus
- -‘M’ Morinus
- -‘U’ Krusinski-Pisa
- -‘G’ Gauquelin sectors
- -- -
Placidus and Koch house cusps cannot be -computed beyond the polar circle. In such cases, swe_houses() switches to Porphyry houses (each quadrant is divided into three -equal parts) and returns the error code ERR.
- -- -
The Vertex -is the point on the ecliptic that is located in precise western direction. The opposition of the Vertex is the Antivertex, -the ecliptic east point.
- -- -
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.
- -E.g. 87w39 = -87.65° (Chicago IL/USA) and 8e33 = +8.55° (Zurich, -Switzerland).
- -There is no such controversy about -northern and southern geographical latitudes. North is always positive and -south is negative.
- -- -
To compute the house position of a -given body for a given ARMC, you may use the
- -double swe_house_pos(
- -double -armc, /* -ARMC */
- -double -geolat, /* geographic latitude, in -degrees */
- -double -eps, /* -ecliptic obliquity, in degrees */
- -int -hsys, /* house method, one of the letters PKRCAV */
- -double -*xpin, /* array of 2 doubles: ecl. -longitude and latitude of the planet */
- -char *serr); /* return area for error -or warning message */
- -- -
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. -
- -· -Alcabitus is not yet supported in -release 1.61.01
- -- -
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.
- -· -swe_gauquelin_sector - detailed below.
- -- -
Function -swe_gauquelin_sector() is declared as follows:
- -- -
int32 swe_gauquelin_sector(
- -double tjd_ut, /* search after this time (UT) */
- -int32 ipl, /* planet number, if -planet, or moon */
- -char *starname, /* star name, if star */
- -int32 iflag, /* flag for ephemeris and SEFLG_TOPOCTR */
- -int32 imeth, /* method: 0 = with lat., 1 = without lat.,
- -/* 2 = from rise/set, 3 = from rise/set with refraction -*/
- -double *geopos, /* array of three doubles containing
- -* geograph. long., lat., height of observer -*/
- -double atpress, /* atmospheric -pressure, only useful with imeth=3;
- -* if 0, default = 1013.25 mbar is used*/
- -double attemp, /* atmospheric -temperature in degrees Celsius, only useful with imeth=3 */
- -double *dgsect, /* return address for -gauquelin sector position */
- -char *serr); /* return address for -error message */
- -- -
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:
- -1. Sector positions from ecliptical -longitude AND latitude:
- --There are two ways of doing this:
- -· -Call swe_house_pos() with hsys = 'G', -xpin[0] = ecliptical longitude of planet, and xpin[1] = ecliptical
- -latitude. This function returns the sector position as a value -between 1.0 and 36.9999999.
- -· -Call swe_gauquelin_sector() with -imeth=0. This is less efficient than swe_house_pos because it
- -recalculates the whole planet whereas swe_house_pos() has an input -array for ecliptical positions
- -calculated before.
- -- -
2. Sector positions computed from -ecliptical longitudes without ecliptical latitudes:
- --There are two ways of doing this:
- -· -Call swe_house_pos() with hsys = 'G', -xpin[0] = ecl. longitude of planet, and xpin[1] = 0. This function
- -returns the sector position as a value between 1.0 and 36.9999999.
- -· -Call swe_gauquelin_sector() with -imeth=1. Again this is less efficient than swe_house_pos.
- -- -
3. Sector positions of a planet from -rising and setting times of planets.
- --The rising and setting of the disk center is used:
- -· -Call swe_gauquelin_sector() with -imeth=2.
- -- -
4. Sector positions of a planet from -rising and setting times of planets, taking into account atmospheric -refraction.
- --The rising and setting of the disk center is used:
- -· -Call swe_gauquelin_sector() with imeth -= 3.
- -- -
5. Sector positions of a planet from -rising and setting times of planets.
- --The rising and setting of the disk edge is used:
- -· -Call swe_gauquelin_sector() with -imeth=4.
- -- -
6. Sector positions of a planet from -rising and setting times of planets, taking into account atmospheric -refraction.
- -The rising and setting -of the disk edge is used:
- -· -Call swe_gauquelin_sector() with imeth -= 5.
- -- -
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.
- -- -
double swe_sidtime(double -tjd_ut); /* Julian day number, UT */
- -double swe_sidtime0(
- -double -tjd_ut, /* Julian day number, UT */
- -double -eps, /* -obliquity of ecliptic, in degrees */
- -double -nut); /* -nutation in longitude, in degrees */
- -- -
- -
long swe_calc_ut(
- -double -tjd_ut, /* Julian day number, -Universal Time */
- -int ipl, /* planet number */
- -long iflag, /* flag bits */
- -double *xx, /* target address for 6 position values: -longitude, latitude, distance,
- -long. speed, lat. speed, dist. speed */
- -char *serr); /* 256 bytes for error string */
- -- -
long swe_calc(
- -double -tjd_et, /* Julian day number, -Ephemeris Time */
- -int ipl, /* planet number */
- -long iflag, /* flag bits */
- -double *xx, /* target address for 6 position values: longitude, -latitude, distance,
- -long. speed, lat. speed, dist. speed */
- -char *serr); /* 256 bytes for error string */
- -long swe_fixstar_ut(
- -char -*star, /* -star name, returned star name 40 bytes */
- -double -tjd_ut, /* Julian day number, Universal -Time */
- -long iflag, /* flag bits */
- -double -*xx, /* target address for 6 -position values: longitude, latitude, distance,
- -long. -speed, lat. speed, dist. speed */
- -char *serr); /* 256 bytes for error string */
- -- -
long swe_fixstar(
- -char -*star, /* -star name, returned star name 40 bytes */
- -double -tjd_et, /* Julian day number, -Ephemeris Time */
- -long iflag, /* flag bits */
- -double -*xx, /* target address for 6 position values: longitude, latitude, -distance,
- -long. speed, lat. speed, dist. speed */
- -char *serr); /* 256 bytes for error string */
- -void swe_set_topo (
- -double -geolon, /* geographic longitude */
- -double -geolat, /* geographic latitude
- -eastern longitude is positive,
- -western longitude is negative,
- -northern latitude is positive,
- -southern latitude is negative */
- -double -altitude); /* altitude above sea */
- -void swe_set_sid_mode (
- -int32 sid_mode,
- -double t0, /* reference epoch */
- -double ayan_t0); /* initial ayanamsha at t0 */
- -- -
/* to get the ayanamsha for a date */
- -double swe_get_ayanamsa(double -tjd_et);
- -int32 swe_sol_eclipse_when_loc(
- -double tjd_start, /* start date for search, Jul. day UT */
- -int32 ifl, /* -ephemeris flag */
- -double *geopos, /* 3 doubles for geo. lon, -lat, height */
- -* eastern longitude is positive,
- -* -western longitude is negative,
- -* -northern latitude is positive,
- -* -southern latitude is negative */
- -double *tret, /* return array, 10 -doubles, see below */
- -double *attr, /* return array, 20 -doubles, see below */
- -AS_BOOL backward, /* TRUE, if backward search */
- -char *serr); /* return error string */
- -int32 swe_sol_eclipse_when_glob(
- -double tjd_start, /* start date for search, Jul. day UT */
- -int32 ifl, /* -ephemeris flag */
- -int32 ifltype, /* eclipse type wanted: -SE_ECL_TOTAL etc. */
- -double *tret, /* return array, 10 -doubles, see below */
- -AS_BOOL backward, /* TRUE, if backward search */
- -char *serr); /* return error string */
- -int32 swe_sol_eclipse_how(
- -double tjd_ut, /* time, Jul. day UT */
- -int32 ifl, /* -ephemeris flag */
- -double *geopos, /* geogr. longitude, -latitude, height */
- -* eastern longitude is positive,
- -* -western longitude is negative,
- -* -northern latitude is positive,
- -* -southern latitude is negative */
- -double *attr, /* return array, 20 -doubles, see below */
- -char *serr); /* return error string */
- -int32 swe_sol_eclipse_where (
- -double tjd_ut, /* time, Jul. day UT */
- -int32 ifl, /* ephemeris flag */
- -double *geopos, /* return array, 2 -doubles, geo. long. and lat. */
- -* eastern longitude is positive,
- -* -western longitude is negative,
- -* -northern latitude is positive,
- -* -southern latitude is negative */
- -double *attr, /* return array, 20 -doubles, see below */
- -char *serr); /* return error string */
- -- -
or
- -- -
int32 swe_lun_occult_where (
- -double tjd_ut, /* time, Jul. day UT */
- -int32 ipl, /* -planet number */
- -char* starname, /* -star name, must be NULL or ”” if not a star */
- -int32 ifl, /* -ephemeris flag */
- -double *geopos, /* return array, 2 doubles, geo. long. and lat.
- -* eastern longitude is positive,
- -* western longitude is negative,
- -* northern latitude is positive,
- -* southern latitude is negative */
- -double *attr, /* return array, 20 doubles, see below */
- -char *serr); /* return error string */
- -(can also be used for solar eclipses )
- -- -
int32 swe_lun_occult_when_loc(
- -double -tjd_start, /* start date for search, -Jul. day UT */
- -int32 ipl, /* -planet number */
- -char* starname, /* -star name, must be NULL or ”” if not a star */
- -int32 ifl, /* -ephemeris flag */
- -double -*geopos, /* 3 doubles for geo. lon, -lat, height eastern longitude is positive,
- --western longitude is negative, -northern latitude is positive,
- --southern latitude is negative */
- -double -*tret, /* return array, 10 doubles, -see below */
- -double -*attr, /* return array, 20 doubles, -see below */
- -AS_BOOL -backward, /* TRUE, if backward search -*/
- -char -*serr); /* return error string */
- -(can also be used for solar eclipses )
- -- -
int32 swe_lun_occult_when_glob(
- -double -tjd_start, /* start date for search, -Jul. day UT */
- -int32 ipl, /* -planet number */
- -char* starname, /* -star name, must be NULL or ”” if not a star */
- -int32 ifl, /* -ephemeris flag */
- -int32 ifltype, /* -eclipse type wanted */
- -double -*geopos, /* 3 doubles for geo. lon, -lat, height eastern longitude is positive,
- --western longitude is negative, -northern latitude is positive,
- --southern latitude is negative */
- -double -*tret, /* return array, 10 doubles, -see below */
- -double -*attr, /* return array, 20 doubles, -see below */
- -AS_BOOL -backward, /* TRUE, if backward search -*/
- -char -*serr); /* return error string */
- -int32 swe_lun_eclipse_when(
- -double tjd_start, /* start date for search, Jul. day UT */
- -int32 ifl, /* ephemeris flag */
- -int32 ifltype, /* eclipse type wanted: -SE_ECL_TOTAL etc. */
- -double *tret, /* return array, 10 -doubles, see below */
- -AS_BOOL backward, /* TRUE, if backward search */
- -char *serr); /* return error string */
- -int32 swe_lun_eclipse_how(
- -double tjd_ut, /* time, Jul. day UT */
- -int32 ifl, /* -ephemeris flag */
- -double *geopos, /* input array, geopos, -geolon, geoheight */
- -eastern longitude is positive,
- --western longitude is negative,
- --northern latitude is positive,
- --southern latitude is negative */
- -double *attr, /* return array, 20 -doubles, see below */
- -char *serr); /* return error string */
- -- -
int32 swe_rise_trans(
- -double tjd_ut, /* search after this time (UT) */
- -int32 ipl, /* planet number, if -planet or moon */
- -char *starname, /* star name, if star */
- -int32 epheflag, /* ephemeris flag */
- -int32 rsmi, /* integer specifying -that rise, set, or one of the two meridian transits is
- --wanted. see definition below */
- -double *geopos, /* array of three doubles containing geograph. long., lat., -height of observer */
- -double atpress, /* atmospheric pressure in mbar/hPa */
- -double attemp, /* atmospheric temperature in deg. C */
- -double *tret, /* return address (double) for rise time etc. */
- -char *serr); /* return address for error message */
- -- -
int32 swe_rise_trans_true_hor(
- -double tjd_ut, /* search after this time (UT) */
- -int32 ipl, /* planet number, if -planet or moon */
- -char *starname, /* star name, if star */
- -int32 epheflag, /* ephemeris flag */
- -int32 rsmi, /* integer specifying -that rise, set, orone of the two meridian transits is
- -wanted. see definition below */
- -double *geopos, /* array of three doubles containing
- -* geograph. long., lat., height of observer -*/
- -double atpress, /* atmospheric pressure in mbar/hPa */
- -double attemp, /* atmospheric temperature in deg. C */
- -double horhgt, /* height of local horizon in deg at the point where the body -rises or sets*/
- -double *tret, /* return address -(double) for rise time etc. */
- -char *serr); /* return address for -error message */
- -- -
- -
int32 swe_pheno_ut(
- -double tjd_ut, /* time Jul. Day UT */
- -int32 ipl, /* planet number */
- -int32 iflag, /* -ephemeris flag */
- -double *attr, /* return array, 20 -doubles, see below */
- -char *serr); /* return error string */
- -int32 swe_pheno(
- -double tjd_et, /* time Jul. Day ET */
- -int32 ipl, /* planet number */
- -int32 iflag, /* ephemeris flag */
- -double *attr, /* return array, 20 -doubles, see below */
- -char *serr); /* return error string */
- -- -
void swe_azalt(
- --double tjd_ut, /* UT */
- -int32 calc_flag, /* SE_ECL2HOR or SE_EQU2HOR */
- -double *geopos, /* array of 3 doubles: geogr. long., lat., -height */
- -- double atpress, /* atmospheric pressure in mbar (hPa) */
- --double attemp, /* atmospheric -temperature in degrees Celsius */
- -double *xin, /* array of 3 doubles: position of body in -either ecliptical or equatorial -coordinates, depending on calc_flag */
- -double *xaz); /* return array of 3 doubles, containing -azimuth, true altitude, apparent altitude */
- -- -
void swe_azalt_rev(
- --double tjd_ut,
- -int32 calc_flag, /* either SE_HOR2ECL or SE_HOR2EQU */
- --double *geopos, /* array of 3 -doubles for geograph. pos. of observer */
- --double *xin, /* array of 2 doubles for azimuth and true -altitude of planet */
- -double *xout); /* return array of 2 doubles for either -ecliptic or equatorial coordinates, depending on calc_flag */
- -double swe_refrac(
- -double inalt,
- -double atpress, /* atmospheric pressure in mbar (hPa) */
- -double attemp, /* atmospheric temperature in degrees Celsius */
- -int32 calc_flag); /* either SE_TRUE_TO_APP or SE_APP_TO_TRUE */
- -- -
* -Ephemeris time (ET) = Universal time (UT) + swe_deltat(UT)*/
- -double swe_deltat(double -tjd);
- -/*Return value: OK or ERR */
- -int swe_date_conversion (
- -int -y , int m , int d , /* year, month, -day */
- -- double hour, /* hours (decimal, with fraction) */
- -- char c, /* -calendar ‘g’[regorian]|’j’[ulian] */
- -double *tjd); /* target address for Julian day */
- -double swe_julday(
- -int year, int month, int day, double hour, -
- -int gregflag); /* Gregorian calendar: 1, Julian calendar: 0 */
- -- -
- -
- -
- -
- -
- -
void swe_revjul (
- -double -tjd, /* Julian day number */
- -int -gregflag, /* Gregorian calendar: 1, -Julian calendar: 0 */
- -int -*year, /* -target addresses for year, etc. */
- -int -*month, int *day, double *hour);
- -/* 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_timezone(
- --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)
- -* an error -message (on error)
- -* The function returns OK or ERR.
- -*/ -
- -void swe_utc_to_jd (
- -int32 -iyear, int32 imonth, int32 iday,
- -int32 ihour, int32 imin, double -dsec, /* note : second is a -decimal */
- -gregflag, /* Gregorian calendar: 1, Julian calendar: 0 */
- -dret /* -return array, two doubles:
- -* dret[0] = Julian day in ET (TT)
- -* dret[1] = Julian day in UT (UT1) */
- -serr /* -error string */
- -)
- -/* input: Julian day number in ET (TT), -calendar flag
- -* -output: year, month, day, hour, min, sec in UTC */
- -void swe_jdet_to_utc (
- -double tjd_et, /* Julian day number in ET (TT) */
- -gregflag, /* Gregorian calendar: 1, Julian calendar: 0 */
- -int32 *iyear, -int32 *imonth, int32 *iday,
- -int32 *ihour, int32 *imin, double -*dsec, /* note : second is a -decimal */
- -)
- -/* input: Julian day number in UT (UT1), -calendar flag
- -* -output: year, month, day, hour, min, sec in UTC */
- -void swe_jdut1_to_utc (
- -double tjd_ut, /* Julian day number in ET (TT) */
- -gregflag, /* Gregorian calendar: 1, Julian calendar: 0 */
- -int32 *iyear, -int32 *imonth, int32 *iday,
- -int32 *ihour, int32 *imin, double -*dsec, /* note : second is a -decimal */
- -)
- -double swe_get_tid_acc(void);
- -void swe_set_tid_acc(double t_acc);
- -/ * function returns the difference -between local apparent and local mean time.
- -e = LAT – -LMT. tjd_et is -ephemeris time */
- -int swe_time_equ(double -tjd_et, double *e, char *serr);
- -int swe_set_ephe_path(char *path);
- -- -
/* set name of JPL ephemeris file */
- -int swe_set_jpl_file(char *fname);
- -- -
/* close Swiss Ephemeris */
- -void swe_close(void);
- -double swe_sidtime(double tjd_ut); /* Julian day number, UT */
- -- -
double swe_sidtime0(
- -double -tjd_ut, /* Julian day number, UT */
- -double -eps, /* obliquity of ecliptic, in -degrees */
- -double -nut); /* nutation, in degrees */
- -int swe_houses(
- -double -tjd_ut, /* Julian day number, UT */
- -double -geolat, /* geographic latitude, in -degrees */
- -double -geolon, /* geographic longitude, in -degrees
- -eastern longitude is positive,
- -western longitude is negative,
- -northern latitude is positive,
- -southern latitude is negative */
- -int -hsys, /* house method, one of the letters PKRCAV */
- -double* -cusps, /* array for 13 doubles */
- -double* -ascmc); /* array for 10 doubles */
- -int swe_houses_ex(
- -double -tjd_ut, /* Julian day number, UT */
- -int32 -iflag, /* -0 or SEFLG_SIDEREAL or SEFLG_RADIANS */
- -double -geolat, /* geographic latitude, in -degrees */
- -double -geolon, /* geographic longitude, in -degrees
- -eastern longitude is positive,
- -western longitude is negative,
- -northern latitude is positive,
- -southern latitude is negative */
- -int -hsys, /* house method, one of the letters PKRCAV */
- -double* -cusps, /* array for 13 doubles */
- -double* -ascmc); /* array for 10 doubles */
- -- -
int swe_houses_armc(
- -double -armc, /* ARMC */
- -double -geolat, /* geographic latitude, in -degrees */
- -double -eps, /* ecliptic obliquity, in -degrees */
- -int -hsys, /* house method, one of the letters PKRCAV */
- -double -*cusps, /* array for 13 doubles */
- -double -*ascmc); /* array for 10 doubles */
- -- -
double swe_house_pos (
- -double -armc, /* ARMC */
- -double -geolat, /* geographic latitude, in -degrees
- --eastern longitude is positive,
- -western longitude is negative,
- -northern latitude is positive,
- -southern latitude is negative */
- -double -eps, /* ecliptic obliquity, in -degrees */
- -int -hsys, /* house method, one of the letters PKRCAV */
- -double -*xpin, /* array of 2 doubles: ecl. -longitude and latitude of the planet */
- --char *serr); /* return area for -error or warning message */
- -- -
- -
double swe_gauquelin_sector(
- -double tjd_ut, /* search after this time (UT) */
- -int32 ipl, /* planet number, if -planet, or moon */
- -char *starname, /* star name, if star */
- -int32 iflag, /* flag for ephemeris and SEFLG_TOPOCTR */
- -int32 imeth, /* method: 0 = with lat., 1 = without lat.,
- -/* 2 = from rise/set, 3 = from rise/set with refraction -*/
- -double *geopos, /* array of three doubles containing
- -* geograph. long., lat., height of observer -*/
- -double atpress, /* atmospheric -pressure, only useful with imeth=3;
- -* if 0, default = 1013.25 mbar is used*/
- -double attemp, /* atmospheric -temperature in degrees Celsius, only useful with imeth=3 */
- -double *dgsect, /* return address for -gauquelin sector position */
- -char *serr); /* return address for error -message */
- -- -
- -
- -
equator -> ecliptic : eps must be positive
- -ecliptic -> equator : -eps must be negative eps, longitude and latitude are in degrees! */
- -- -
void swe_cotrans(
- -double *xpo, /* 3 doubles: -long., lat., dist. to be converted; distance remains unchanged, can be set to -1.00 */
- -double *xpn, /* 3 doubles: long., lat., dist. Result -of the conversion */
- -double -eps); /* obliquity of ecliptic, in -degrees. */
- -/ * equator -> ecliptic : -eps must be positive
- --ecliptic -> equator : eps must be negative
- --eps, long., lat., and speeds in long. and lat. are in degrees! */
- -void swe_cotrans_sp(
- -double -*xpo, /* 6 doubles, input: long., -lat., dist. and speeds in long., lat and dist. */
- -double -*xpn, /* 6 doubles, position and -speed in new coordinate system */
- -double -eps); /* obliquity of ecliptic, in -degrees. */
- -char* swe_get_planet_name(
- -int ipl, /* -planet number */
- -char* plan_name); /* address for planet name, at least 20 char */
- -- -
/* normalization of any degree number to -the range 0 ... 360 */
- -double swe_degnorm(double -x);
- -- -
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.
- -/ * former function name: csnorm() */
- -extern EXP32 centisec FAR PASCAL_CONV -EXP16 swe_csnorm(centisec p);
- -/ * former function name: difcsn() */
- -extern EXP32 centisec FAR PASCAL_CONV -EXP16 swe_difcsn(centisec p1, centisec p2);
- -/* former function name: difdegn() */
- -extern EXP32 double FAR PASCAL_CONV EXP16 swe_difdegn (double p1, double p2);
- -/* former function name: difcs2n() */
- -extern EXP32 centisec FAR PASCAL_CONV -EXP16 swe_difcs2n(centisec p1, centisec p2);
- -- -
/* former function name: difdeg2n() */
- -extern EXP32 double FAR PASCAL_CONV EXP16 swe_difdeg2n(double p1, double p2);
- -/* -former function name: roundsec() */
- -extern EXP32 centisec FAR PASCAL_CONV -EXP16 swe_csroundsec(centisec x);
- -/* former function name: d2l() */
- -extern EXP32 long FAR PASCAL_CONV EXP16 swe_d2l(double x);
- -/*Monday = 0, ... Sunday = 6 former function name: day_of_week() */
- -extern EXP32 int FAR PASCAL_CONV EXP16 swe_day_of_week(double jd);
- -/* former function name: TimeString() */
- -extern EXP32 char *FAR PASCAL_CONV EXP16 swe_cs2timestr(CSEC t, int sep, AS_BOOL -suppressZero, char *a);
- -/* former function name: LonLatString() */
- -extern EXP32 char *FAR PASCAL_CONV EXP16 swe_cs2lonlatstr(CSEC t, char pchar, char -mchar, char *s);
- -/* former function name: DegreeString() */
- -extern EXP32 char *FAR PASCAL_CONV EXP16 swe_cs2degstr(CSEC t, char *a);
- -- -
There is a 32 bit DLL: swedll32.dll
- -- -
You can use our programs swetest.cand swewin.cas examples.To compile swetestor swewin with a DLL:
- -- -
1. The compiler needs the following files:
- -swetest.corswewin.c
- -swedll32.dll
- -swedll32.lib (if you choose -implicit linking)
- -swephexp.h
- -swedll.h
- -sweodef.h
- -- -
2. Define the following macros (-d):
- -USE_DLL
- -3. Build swetest.exe from swetest.cand swedll32.lib. -
- -Build swewin.exe -from swewin.c,swewin.rc, and swedll32.lib
- -We -provide some project files which we have used to build our test samples. You -will need to adjust the project files to your environment.
- -We have -worked with Microsoft -Visual C++ 5.0 (32-bit). The DLLs where built -with the Microsoft compilers.
- -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:
- -
-Private Function set_strlen(c$) As String
i = InStr(c$, Chr$(0))
c$ = Left(c$, i - 1)
set_strlen = c$
-End Function
-plname = String(20,0) ‘ initialize
-string to length 20
-swe_get_planet_name(SE_SUN, plname)
-plname = set_strlen(plname)
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)
- -
- -
The information in this section was -contributed by Markus Fabian, Bern, Switzerland.
- -- -
In Delphi 2.0 the declaration of the -function swe_calc() looks like this:
- -- -
xx : Array[0..5] of double;
- -function swe_calc (tjd : double; // Julian day number
- -ipl : Integer; // planet number
- -iflag : -Longint; // flag bits
- -var -xx[0] : double;
- -sErr : PChar // -Error-String;
- -) : Longint; -stdcall; far; external 'swedll32.dll' Name '_swe_calc@24';
- -- -
A nearly complete set of declarations is in -file \sweph\delphi2\swe_d32.pas.
- -A small sample project for Delphi 2.0 is -also included in the same directory (starting with release 1.25 from -June 1998). This sample requires the DLL to exist in the same directory as the -sample.
- -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:
- -IMPLIB –f –c swe32bor.lib -\sweph\bin\swedll32.dll
- -- -
In the C++ Builder project the following -settings must be made:
- -- -
· -Menu Options->Projects->Directories/Conditionals: add the conditional define USE_DLL
- -· -Menu -Project->Add_to_project: add the library file swe32bor.lib to -your project.
- -· -In the project source, add the -include file -"swephexp.h"
- -- -
In the header file swedll.h the declaration for Dllimport must be
- -#define DllImport extern "C" __declspec( dllimport )
- -This is provided automatically by the __cplusplus switch for release 1.24 and -higher. For earlier releases the change must be made manually.
- -- -
Changes for c++builder 2010
- -Swiss Ephemeris developer Jean Cremers, -Netherlands, reported in August 2010 that a different procedure is needed for -new versions of c++builder. This is his report:
- -- -
The method -described in the file swephprg.htm 'Using the DLL with Borland Delphi and C++ Builder' does not -work for the current c++builder (I use c++ builder 6).
- -The command -'IMPLIB –f –c swe32bor.lib \sweph\bin\swedll32.dll' will give 2 errors 'unable -to open file' and will create the file '-f.lib'.
- -It seems implib -cannot handle the switches anymore, indeed when left out the file swe32bor.lib -is generated but the file is in the coff format.
- -A solution is to -use the coff2omf.exe utility that comes with c++builder like this 'coff2omf.exe -swedll32.dll swe32bor.lib', it will generate a usable lib for c++builder.
- -- -
The steps to use -sweph with c++builder then become:
- -- -
----
- -With the -following command command you create a special lib file in the current -directory:
- -coff2omf.exe -swedll32.dll \sweph\bin\swe32bor.lib
- -- -
In the C++ -Builder project the following settings must be made:
- -- -
Menu -Options->Projects->Directories/Conditionals: add the conditional define -USE_DLL
- -Menu Project->Add_to_project: add the library -file swe32bor.lib to your project.
- -In the project -source, add the include file "swephexp.h"
- -----
- -- -
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
- -- -
- -
- Unpack the -file PerlSwissEph-1.76.00.tar.gz (or whatever newest version there is)
- -- Open the file Makefile.PL, and edit it -according to your requirements. Then run it.
- -- make install
- -- -
If you work on a Windows machine and prefer -to use the Swiss Ephemeris DLL, you may want to study Rüdiger Plantiko's Perl -module for the Swiss Ephemeris at http://www.astrotexte.ch/sources/SwissEph.zip. -There is also a documentation in German language by Rüdiger Plantiko at http://www.astrotexte.ch/sources/swe_perl.html).
- -- -
- -
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.
- -All new software should use the SwissEph API directly.
- -- -
The following files are in the directory \sweph\doc
- -- -
sweph.cdr
- -sweph.gif
- -swephin.cdr
- -swephin.gif
- -swephprg.doc Documentation -for programming, a MS Word-97 file
- -swephprg.rtf
- -swisseph.doc General -information on Swiss Ephemeris
- -swisseph.rtf
- -- -
The files with suffix .CDR are Corel Draw -7.0 documents with the Swiss Ephemeris icons.
- -- -
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:
- -Mean -Node, Mean Apogee:
- -HPUX PA-Risc non-optimized versus optimized -code:
- --differences are smaller than 0.001 arcsec/day
- -- -
HPUX PA-Risc -versus Intel Pentium gcc non-optimzed
- -differences are -smaller than 0.001 arcsec/day
- -- -
Intel Pentium gss non-optimzed versus -O9 -optimized:
- -Mean -Node, True node, Mean Apogee: difference smaller -than 0.001 arcsec/day
- -Osculating -Apogee: differences smaller than 0.03 arcsec
- -- -
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.
- -- -
Besides the ordinary Swisseph function, -there are two additional DLLs that allow you tracing your Swisseph function -calls:
- -Swetrs32.dll is for single task debugging, i.e. if only one application at a -time calls Swisseph functions.
- -Two output files -are written:
- -a) swetrace.txt: reports all Swisseph functions that are being called.
- -b) swetrace.c: contains C code equivalent to the Swisseph calls that your -application did.
- -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.
- -- -
Output samples swetrace.txt:
- -- -
swe_deltat: 2451337.870000 0.000757
- -swe_set_ephe_path: path_in = path_set = \sweph\ephe\
- -swe_calc: 2451337.870757 -1 258 23.437404 23.439365 -0.003530 -0.001961 0.000000 0.000000
- -swe_deltat: 2451337.870000 0.000757
- -swe_sidtime0: 2451337.870000 sidt = 1.966683 eps = 23.437404 nut = -0.003530
- -swe_sidtime: 2451337.870000 1.966683
- -swe_calc: 2451337.870757 0 258 77.142261 -0.000071 1.014989 0.956743 -0.000022 0.000132
- -swe_get_planet_name: 0 Sun
- -- -
- -
swetrace.c:
- -#include -"sweodef.h"
- -#include -"swephexp.h"
- -- -
void -main()
- -{
- -double tjd, t, nut, eps; int i, ipl, retc; -long iflag;
- -double armc, geolat, cusp[12], ascmc[10]; -int hsys;
- -double xx[6]; long iflgret;
- -char s[AS_MAXCH], star[AS_MAXCH], -serr[AS_MAXCH];
- -- -
/*SWE_DELTAT*/
- -tjd = -2451337.870000000; t = swe_deltat(tjd);
- --printf("swe_deltat: %f\t%f\t\n", tjd, t);
- -- -
/*SWE_CALC*/
- -tjd = -2451337.870757482; ipl = 0; iflag = 258;
- -iflgret = -swe_calc(tjd, ipl, iflag, xx, serr); /* -xx = 1239992 */
- -- -
/*SWE_CLOSE*/
- -swe_close();
- -- -
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.
- -For further explanations, see 21.1.
- -- -
- -
|
- Updated - |
-
- By - |
-
- - |
- |||
|
- 30-sep-97 - |
-
- Alois - |
-
- added - chapter 10 (sample programs) - |
- |||
|
- 7-oct-97 - |
-
- Dieter - |
-
- inserted - chapter 7 (house calculation) - |
- |||
|
- 8-oct-97 - |
-
- Dieter - |
-
- Appendix - ”Changes from version 1.00 to 1.01” - |
- |||
|
- 12-oct-1997 - |
-
- Alois - |
-
- Added new - chapter 10 Using the DLL with Visual Basic - |
- |||
|
- 26-oct-1997 - |
-
- Alois - |
-
- improved implementation and documentation - of swe_fixstar() - |
- |||
|
- 28-oct-1997 - |
-
- Dieter - |
-
- Changes from Version 1.02 to 1.03 - |
- |||
|
- 29-oct-1997 - |
-
- Alois - |
-
- added VB sample extension, fixed VB - declaration errors - |
- |||
|
- 9-Nov-1997 - |
-
- Alois - |
-
- added Delphi declaration sample - |
- |||
|
- 8-Dec-97 - |
-
- Dieter - |
-
- remarks concerning computation of - asteroids, changes to version 1.04 - |
- |||
|
- 8-Jan-98 - |
-
- Dieter - |
-
- changes from version 1.04 to 1.10. - |
- |||
|
- 12-Jan-98 - |
-
- Dieter - |
-
- changes from version 1.10 to 1.11. - |
- |||
|
- 21-Jan-98 - |
-
- Dieter - |
-
- calculation of topocentric planets and - house positions (1.20) - |
- |||
|
- 28-Jan-98 - |
-
- Dieter - |
-
- Delphi 1.0 sample and declarations for 16- - and 32-bit Delphi (1.21) - |
- |||
|
- 11-Feb-98 - |
-
- Dieter - |
-
- version 1.23 - |
- |||
|
- 7-Mar-1998 - |
-
- Alois - |
-
- version 1.24 support for Borland C++ - Builder added - |
- |||
|
- 4-June-1998 - |
-
- Alois - |
-
- version 1.25 sample for Borland Delphi-2 - added - |
- |||
|
- 29-Nov-1998 - |
-
- Alois - |
-
- version 1.26 source code information added - §16, Placalc API added - |
- |||
|
- 1-Dec-1998 - |
-
- Dieter - |
-
- chapter 19 and some additions in beginning - of Appendix. - |
- |||
|
- 2-Dec-1998 - |
-
- Alois - |
-
- Equation of Time explained (in §4), changes - version 1.27 explained - |
- |||
|
- 3-Dec-1998 - |
-
- Dieter - |
-
- Note on ephemerides of 1992 QB1 and 1996 - TL66 - |
- |||
|
- 17-Dec-1998 - |
-
- Alois - |
-
- Note on extended time range of 10'800 years - |
- |||
|
- 22 Dec 1998 - |
-
- Alois - |
-
- Appendix - A - |
- |||
|
- 12-Jan-1999 - |
-
- Dieter - |
-
- Eclipse functions added, version 1.31 - |
- |||
|
- 19-Apr-99 - |
-
- Dieter - |
-
- version 1.4 - |
- |||
|
- 8-Jun-99 - |
-
- Dieter - |
-
- Chapter 21 on tracing an debugging Swisseph - |
- |||
|
- 27-Jul-99 - |
-
- Dieter - |
-
- Info about sidereal calculations - |
- |||
|
- 16-Aug-99 - |
-
- Dieter - |
-
- version 1.51, minor bug fixes - |
- |||
|
- 15-Feb-00 - |
-
- Dieter - |
-
- many things for version 1.60 - |
- |||
|
- 19-Mar-00 - |
-
- Vic Ogi - |
-
- SWEPHPRG.DOC - re-edited - |
- |||
|
- 17-apr-02 - |
-
- Dieter - |
-
- Documentation for version 1.64 - |
- |||
|
- 26-Jun-02 - |
-
- Dieter - |
-
- Version 1.64.01 - |
- |||
|
- 31-dec-2002 - |
-
- Alois - |
-
- edited doc to remove references to 16-bit - version - |
- |||
|
- 12-jun-2003 - |
-
- Alois/Dieter - |
-
- Documentation for version 1.65 - |
- |||
|
- 10-Jul-2003 - |
-
- Dieter - |
-
- Documentation for version 1.66 - |
-
- - |
- ||
|
- 25-May-2004 - |
-
- Dieter - |
-
- Documentation of eclipse functions updated - |
-
- - |
- ||
|
- 31-Mar-2005 - |
-
- Dieter - |
-
- Documentation for version 1.67 - |
-
- - |
- ||
|
- 3-May-2005 - |
-
- Dieter - |
-
- Documentation for version 1.67.01 - |
-
- - |
- ||
|
- 22-Feb-2006 - |
-
- Dieter - |
-
- Documentation for version 1.70.00 - |
-
- - |
- ||
|
- 2-May-2006 - |
-
- Dieter - |
-
- Documentation for version 1.70.01 - |
-
- - |
- ||
|
- 5-Feb-2006 - |
-
- Dieter - |
-
- Documentation for version 1.70.02 - |
-
- - |
- ||
|
- 30-Jun-2006 - |
-
- Dieter - |
-
- Documentation for version 1.70.03 - |
-
- - |
- ||
|
- 28-Sep-2006 - |
-
- Dieter - |
-
- Documentation for version 1.71 - |
- |||
|
- 29-May-2008 - |
-
- Dieter - |
-
- Documentation for version 1.73 - |
- |||
|
- 18-Jun-2008 - |
-
- Dieter - |
-
- Documentation for version 1.74 - |
- |||
|
- 27-Aug-2008 - |
-
- Dieter - |
-
- Documentation for version 1.75 - |
- |||
|
- 7-April-2009 - |
-
- Dieter - |
-
- Documentation of version 1.76 - |
- |||
| - | - | - | - | - | - |
- -
|
- Release - |
-
- Date - |
-
- - |
- ||
|
- 1.00 - |
-
- 30-sep-1997 - |
-
- - |
- ||
|
- 1.01 - |
-
- 9-oct-1997 - |
-
- houses(), sidtime() made more convenient for developer, Vertex added. - |
- ||
|
- 1.02 - |
-
- 16-oct-1997 - |
-
- houses() - changed again, Visual Basic support, new numbers for fictitious planets This - release was pushed to all existing licensees at this date. - |
- ||
|
- 1.03 - |
-
- 28-Oct-1997 - |
-
- minor bug - fixes, improved swe_fixstar() functionality. This - release was not pushed, as the changes and bug fixes are minor; no changes of - function definitions occurred. - |
- ||
|
- 1.04 - |
-
- 8-Dec-1997 - |
-
- minor bug - fixes; more asteroids. - |
- ||
|
- 1.10 - |
-
- 9-Jan-1998 - |
-
- bug fix, s. - Appendix. This release was pushed to all existing licensees at this date. - |
- ||
|
- 1.11 - |
-
- 12-Jan-98 - |
-
- small - improvements - |
- ||
|
- 1.20 - |
-
- 20-Jan-98 - |
-
- New: topocentric planets - and house positions; a minor bug fix - |
- ||
|
- 1.21 - |
-
- 28-Jan-98 - |
-
- Delphi - declarations and sample for Delphi 1.0 - |
- ||
|
- 1.22 - |
-
- 2-Feb-98 - |
-
- Asteroids - moved to subdirectory. Swe_calc() finds them - there. - |
- ||
|
- 1.23 - |
-
- 11-Feb-98 - |
-
- two minor - bug fixes. - |
- ||
|
- 1.24 - |
-
- 7-Mar-1998 - |
-
- Documentation - for Borland C++ Builder added, see section 14.3 - |
- ||
|
- 1.25 - |
-
- 4-June-1998 - |
-
- Sample for - Borland Delphi-2 added - |
- ||
|
- 1.26 - |
-
- 29-Nov-1998 - |
-
- full source - code made available, Placalc API documented - |
- ||
|
- 1.27 - |
-
- 2-dec-1998 - |
-
- Changes to SE_EPHE_PATH and swe_set_ephe_path() - |
- ||
|
- 1.30 - |
-
- 17-Dec-1998 - |
-
- Time range - extended to 10'800 years - |
- ||
|
- 1.31 - |
-
- 12-Jan-1999 - |
-
- New: Eclipse functions - added - |
- ||
|
- 1.40 - |
-
- 19-Apr-99 - |
-
- New: planetary phenomena - added; bug fix in swe_sol_ecl_when_glob(); - |
- ||
|
- 1.50 - |
-
- 27-Jul-99 - |
-
- New: SIDEREAL planetary - positions and houses; new fixstars.cat - |
- ||
|
- 1.51 - |
-
- 16-Aug-99 - |
-
- Minor bug - fixes - |
- ||
|
- 1.60 - |
-
- 15-Feb-2000 - |
-
- Major - release with many new features and - some minor bug fixes - |
- ||
|
- 1.61 - |
-
- 11-Sep-2000 - |
-
- Minor - release, additions to se_rise_trans(), swe_houses(), ficitious planets - |
- ||
|
- 1.61.01 - |
-
- 18-Sep-2000 - |
-
- Minor - release, added Alcabitus house system - |
- ||
|
- 1.61.02 - |
-
- 10-Jul-2001 - |
-
- Minor - release, fixed bug which prevented asteroid files > 22767 to be accepted - |
- ||
|
- 1.61.03 - |
-
- 20-Jul-2001 - |
-
- Minor - release, fixed bug which was introduced in 1.61.02: Ecliptic was computed in - Radians instead of degrees - |
- ||
|
- 1.62.00 - |
-
- 23-Jul-2001 - |
-
- Minor - release, several bug fixes, code for fictitious satellites of the earth, - asteroid files > 55535 are accepted - |
- ||
|
- 1.62.01 - |
-
- 16-Oct-2001 - |
-
- Bug fix, - string overflow in sweph.c::read_const(), - |
- ||
|
- 1.63.00 - |
-
- 5-Jan-2002 - |
-
- Added house - calculation to sweetest.c and swetest.exe - |
- ||
|
- 1.64.00 - |
-
- 6-Mar-2002 - |
-
- House - system ‘G’ for house functions and function swe_gauquelin_sector() for - Gauquelin sector calculations -Occultations of planets and fixed stars - by the moon -New Delta T algorithms - |
- ||
|
- 1.64.01 - |
-
- 26-Jun-2002 - |
-
- Bug fix in - swe_fixstar(). Stars with decl. between –1° and 0° were wrong - |
- ||
|
- 1.65.00 - |
-
- 12-Jun-2003 - |
-
- Long - variables replaced by INT32 for 64-bit compilers - |
- ||
|
- 1.66.00 - |
-
- 10-Jul-2003 - |
-
- House - system ‘M’ for Morinus houses - |
- ||
|
- 1.67.00 - |
-
- 31-Mar-2005 - |
-
- Update Delta T - |
- ||
|
- 1.67.01 - |
-
- 3-May-2005 - |
-
- Docu for - sidereal calculations (Chap. 10) updated (precession-corrected transits) - |
- ||
|
- 1.70.00 - |
-
- 22-Feb-2006 - |
-
- all - relevant IAU resolutions up to 2005 have been implemented - |
- ||
|
- 1.70.01 - |
-
- 2-May-2006 - |
-
- minor bug - fix - |
- ||
|
- 1.70.02 - |
-
- 5-May-2006 - |
-
- minor bug - fix - |
- ||
|
- 1.70.03 - |
-
- 30-June-2006 - |
-
- bug fix - |
- ||
|
- 1.71 - |
-
- 28-Sep-2006 - |
-
- Swiss - Ephemeris functions able to calculate minor planet no 134340 Pluto - |
- ||
|
- 1.72 - |
-
- 28-Sep-2007 - |
-
- New - function swe_refract_extended(), Delta T update, minor bug fixes - |
- ||
|
- 1.73 - |
-
- 29-May-2008 - |
-
- New - function swe_fixstars_mag(), Whole Sign houses - |
- ||
|
- 1.74 - |
-
- 18-Jun-2008 - |
-
- Bug fixes - |
- ||
|
- 1.75 - |
-
- 27-Aug-2008 - |
-
- Swiss - Ephemeris can read newer JPL ephemeris files; bug fixes - |
- ||
|
- 1.76 - |
-
- 7-April-2009 - |
-
- Heliacal - risings, UTC and minor improvements/bug fixes - |
- ||
|
- 1.77 - |
-
- 26-Jan-2010 - |
-
- swe_deltat(), - swe_fixstar() improved, swe_utc_time_zone_added - |
- ||
|
- 1.78 - |
-
- 3-Aug-2012 - |
-
- New - precession, improvement of some eclipse functions, some minor bug fixes - |
- ||
|
- 1.79 - |
-
- 18-Apr-2013 - |
-
- New - precession, improvement of some eclipse functions, some minor bug fixes - |
- ||
| - | - | - | - | - |
- -
- Improved precision in eclipse calculations: -2nd and 3rd contact with solar eclipses, penumbral and -partial phases with lunar eclipses.
- -- 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.
- -- -
- precession is now calculated according to Vondrák, Capitaine, -and Wallace 2011.
- -- Delta t for current years updated.
- -- new function: swe_rise_trans_true_hor() -for risings and settings at a local horizon with known height.
- -- functions swe_sol_eclipse_when_loc(), -swe_lun_occult_when_loc(): return values tret[5] and tret[6] (sunrise and -sunset times) added, which had been 0 so far.
- -- function swe_lun_eclipse_how(): return -values attr[4-6] added (azimuth and apparent and true altitude of moon).
- -- 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.
- -- -
- Delta T:
- --- Current values were updated.
- --- File sedeltat.txt understands doubles.
- --- 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)
- --- minor bug fix in swemmoon.c, Moshier's lunar ephemeris (thanks to -Bhanu Pinnamaneni)
- --- solar and lunar eclipse functions provide additional data:
- --attr[8] magnitude, attr[9] saros series number, attr[10] saros series -member number
- -- -
New features:
- -- Functions for the calculation of -heliacal risings and related phenomena, s. chap. 6.15-6.17.
- -- Functions for conversion between UTC -and JD (TT/UT1), s. chap. 7.2 and 7.3.
- -- File sedeltat.txt allows the user to -update Delta T himself regularly, s. chap. 8.3
- -- Function swe_rise_trans(): twilight -calculations (civil, nautical, and astronomical) added
- -- Function swe_version() returns version -number of Swiss Ephemeris.
- -- Swiss Ephemeris for Perl programmers -using XSUB
- -- -
Other updates:
- -- Delta T updated (-2009).
- -- -
Minor bug fixes:
- -- swe_house_pos(): minor bug with -Alcabitius houses fixed
- -- swe_sol_eclipse_when_glob(): totality -times for eclipses jd2456776 and jd2879654 fixed (tret[4], tret[5])
- -- 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.
- -- -
- Function swe_gauquelin_sector() was -extended.
- -- -
- Minor bug fixes.
- -The Swiss Ephemeris is made available -under a dual licensing system:
- -a) -GNU public license version 2 or later
- -b) -Swiss Ephemeris Professional License
- -For more details, see at the beginning of -this file and at the beginning of every source code file.
- -- -
Minor bug fixes:
- -- Bug in swe_fixstars_mag() fixed.
- -- Bug in swe_nod_aps() fixed. With -retrograde asteroids (20461 Dioretsa, 65407 2002RP120), the calculation of -perihelion and aphelion was not correct.
- -- The ephemeris of asteroid 65407 -2002RP120 was updated. It had been wrong before 17 June 2008.
- -New features:
- -- Whole Sign houses implemented (W)
- -- swe_house_pos() now also handles -Alcabitius house method
- -- function swe_fixstars_mag() provides -fixed stars magnitudes
- -- -
- Delta T values for recent years were -updated
- -- Delta T -calculation before 1600 was updated to Morrison/Stephenson 2004..
- -- New function swe_refract_extended(), in -cooperation with archaeoastronomer Victor -Reijs.
- -This -function allows correct calculation of refraction for altitudes above sea > -0, where the ideal horizon and
- --Planets that are visible may have a negative height.
- -- Minor bugs in -swe_lun_occult_when_glob() and swe_lun_eclipse_how() were fixed.
- -- -
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.
- -- -
Code to do with (#define NO_MOSHIER ) war -removed.
- -Bug fixed in speed calculation for -interpolated lunar apsides. With ephemeris positions close to 0 Aries, speed -calculations were completely wrong. E.g. swetest -pc -bj3670817.276275689 -(speed = 1448042° !)
- -Thanks, once more, to Thomas Mack, for -testing the software so well.
- -- -
Bug fixed in speed calculation for -interpolated lunar apsides. Bug could result in program crashes if the speed -flag was set.
- -- -
Update of -algorithms to IAU standard recommendations:
- -All relevant IAU resolutions up to 2005 -have been implemented. These include:
- -- the "frame bias" rotation from -the JPL reference system ICRS to J2000. The correction of position ~= 0.0068 -arc sec in right ascension.
- -- the precession model P03 -(Capitaine/Wallace/Chapront 2003). The correction in longitude is smaller than -1 arc second from 1000 B.C. on.
- -- the nutation model IAU2000B (can be -switched to IAU2000A)
- -- corrections to epsilon
- -- corrections to sidereal time
- -- fixed stars input data can be -"J2000" or "ICRS"
- -- fixed stars conversion FK5 -> J2000, -where required
- -- fixed stars data file was updated with -newer data
- -- constants in sweph.h updated
- -For more info, see the documentation -swisseph.doc, chapters 2.1.2.1-3.
- -- -
New features:
- -- Ephemerides of "interpolated lunar -apogee and perigee", as published by Dieter Koch in 2000 (swetest -pcg).
- --For more info, see the documentation swisseph.doc, chapter 2.2.4.
- -- House system according to Bogdan -Krusinski (character ‘U’).
- --For more info, see the documentation swisseph.doc, chapter 6.1.13.
- -- -
Bug fixes:
- -- Calculation of magnitude was wrong with -asteroid numbers < 10000 (10-nov-05)
- -- -
- -
Delta-T updated with new measured values -for the years 2003 and 2004, and better estimates for 2005 and 2006.
- -Bug fixed #define SE_NFICT_ELEM 15
- -- -
New features:
- -House system according to Morinus (system -‘M’).
- -- -
‘long’ variables were changed to ‘INT32’ -for 64-bit compilers.
- -- -
- -
- Bug fixed in swe_fixstar(). Declinations -between –1° and 0° were wrongly taken as positive.
- -Thanks to John Smith, Serbia, who found -this bug.
- -- Several minor bug fixes and cosmetic code -improvements suggested by Thomas Mack, Germany.
- --swetest.c: options –po and –pn work now.
- --Sweph.c: speed of mean node and mean lunar apogee were wrong in rare -cases, near 0 Aries.
- -- -
New features:
- -1) Gauquelin sectors:
- -- swe_houses() etc. can be called with -house system character ‘G’ to calculate Gauquelin sector boundaries.
- -- swe_house_pos() can be called with house -system ‘G’ to calculate sector positions of planets.
- -- swe_gauquelin_sector() is new and -calculates Gauquelin sector positions with three methods: without ecl. latitude, -with ecl. latitude, from rising and setting.
- -- -
2) Waldemath Black Moon elements have been -added in seorbel.txt (with thanks to Graham Dawson).
- -- -
3) Occultations of the planets and fixed -stars by the moon
- -- swe_lun_occult_when_loc() calculates -occultations for a given geographic location
- -- swe_lun_occult_when_glob() calculates -occultations globally
- -- -
4) Minor bug fixes in swe_fixstar() -(Cartesian coordinates), solar eclipse functions, swe_rise_trans()
- -- -
5) sweclips.c integrated into swetest.c. -Swetest now also calculates eclipses, occultations, risings and settings.
- -- -
6) new Delta T algorithms
- -- -
New features:
- -The option –house was added to swetest.c so -that swetest.exe can now be used to compute complete horoscopes in textual -mode.
- -Bux fix: a minor bug in function -swe_co_trans was fixed. It never had an effect.
- -- -
New features:
- -1) Elements for hypothetical bodies that -move around the earth (e.g. Selena/White Moon) can be added to the file -seorbel.txt.
- -2) The software will be able to read -asteroid files > 55535.
- -- -
Bug fixes:
- -1) error in geocentric planetary descending -nodes fixed
- -2) swe_calc() now allows hypothetical -planets beyond SE_FICT_OFFSET + 15
- -3) position of hypothetical planets -slightly corrected (< 0.01 arc second)
- -- -
New features:
- -1. swe_houses and swe_houses_armc now -supports the Alcabitus house system. The function swe_house_pos() does not yet, -because we wanted to release quickly on user request.
- -- -
New features:
- -1. Function swe_rise_trans(): Risings and -settings also for disc center and without refraction
- -2. “topocentric” house system added to -swe_houses() and other house-related functions
- -3. Hypothetical planets (seorbel.txt), -orbital elements with t terms are possible now (e.g. for Vulcan according to -L.H. Weston)
- -- -
New features:
- -1. Universal time functions swe_calc_ut(), swe_fixstar_ut(), etc.
- -2. Planetary nodes, perihelia, aphelia, -focal points
- -3. Risings, settings, and meridian transits of the Moon, planets, asteroids, and stars.
- -4. Horizontal coordinates (azimuth and altitude)
- -5. Refraction
- -6. User-definable orbital elements
- -7. Asteroid names can be updated by user
- -8. Hitherto missing "Personal -Sensitive Points" according to M. Munkasey.
- -- -
Minor bug fixes:
- -· -Astrometric lunar positions (not relevant for astrology; swe_calc(tjd, SE_MOON, SEFLG_NOABERR)) had a maximum error of about 20 arc sec).
- -· -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.
- -- -
Minor bug fixes:
- -· -J2000 coordinates for the lunar node -and osculating apogee corrected. This bug did not affect ordinary computations -like ecliptical or equatorial positions.
- -· -minor bugs in swetest.c corrected
- -· -sweclips.exe recompiled
- -· -trace DLLs recompiled
- -· -some VB5 declarations corrected
- -New:SIDEREAL planetary -and house position.
- -· -The fixed star file fixstars.cat has been improved and enlarged by Valentin Abramov, Tartu, Estonia.
- -· -Stars have been ordered by -constellation. Many names and alternative spellings have been added.
- -· -Minor bug fix in solar eclipse -functions, sometimes relevant in border-line cases annular/total, partial/total.
- -· -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.
- -- -
New:Function for several -planetary phenomena added
- -Bug fix in swe_sol_ecl_when_glob(). The time for maximum eclipse at local apparent noon (tret[1]) was -sometimes wrong. When called from VB5, the program crashed.
- -- -
New: Eclipse functions added.
- -Minor bug fix: with previous versions, the -function -swe_get_planet_name() got the name wrong, if it -was an asteroid name and consisted of two or more words (e.g. Van Gogh)
- -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.
- -· -The asteroid subdirectory -ephe/asteroid has been split into directories ast0, ast1,... -with 1000 asteroid files per directory. -
- -· -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.
- -· -Note that the CHIRON ephemeris is should not be used -before 700 A.D.
- -· -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.
- -· -The topocentric flag now also works -with the fixed stars. (The effect of diurnal aberration is a few 0.1 arc -second.)
- -· -Bug fix: The return position of swe_cotrans_sp() has been 0, when the input distance was 0.
- -· -About 140 asteroids are on the CD.
- -· -Asteroid ephemerides have been moved -to the ephe\asteroid.
- -· -The DLL has been modified in such a -way that it can find them there.
- -· -All asteroids with catalogue number -below 90 are on the CD and a few additional ones.
- -Sample program and function declarations -for Delphi 1.0 added.
- -New:
- -· -A flag bit SEFLG_TOPOCTR allows to compute topocentric planet positions. Before calling swe_calc(), call swe_set_topo.
- -· -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.)
- -· -Bug fix: swe_cotrans() did not work in former versions.
- -No bug fix, but two minor improvements:
- -- -
·
-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.
- -· -More asteroids have been added in this -release.
- -· -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.
- -- -
· -The function swe_houses() has been changed.
- -· -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.
- -The computation of the sidereal time is now -much easier. The obliquity and nutation are now computed inside the function. -The structure of the function swe_sidtime() has -been changed as follows:
- -/* sidereal time */
- -double swe_sidtime(double tjd_ut); /* Julian day number, UT */
- -The old functions swe_sidtime0() has been kept for backward compatibility.
- -The calculation of houses has been -simplified as well. Moreover, the Vertex has been added.
- -The version 1.01 structure of swe_houses() is:
- -int swe_houses(
- -double -tjd_ut, /* julian day number, UT */
- -double -geolat, /* geographic latitude, in -degrees */
- -double -geolon, /* geographic longitude, in -degrees */
- -char -hsys, /* house method, one of the letters PKRCAV */
- -double -*asc, /* address for ascendant */
- -double -*mc, /* -address for mc */
- -double -*armc, /* address for armc */
- -double -*vertex, /* address for vertex */
- -double *cusps); /* address for 13 doubles: 1 empty + 12 houses */
- -- -
Note also, that the indices of the -cusps have changed:
- -cusp[0] = 0 (before: cusp[0] = house -1)
- -cusp[1] = house 1 (before: cusp[1] = house -2)
- -cusp[2] = house -2 (etc.)
- -etc.
- -The new pseudo-body SE_ECL_NUT replaces the two separate pseudo-bodies SE_ECLIPTIC -and SE_NUTATION in the function swe_calc().
- -- -
There are some important limits in regard -to what you can expect from an ephemeris module. We do not tell you:
- - - - - -· -which glyphs to use
- -· -when a -planet is stationary (it depends on you how slow you -want it to be)
- -· -how to compute universal time from -local time, i.e. what timezone a place is located in
- -· -how to compute progressions, solar -returns, composit charts, transit times and a lot else
- -· -what the -different calendars (Julian, Gregorian, ..) mean and -when they applied.
- -|
- Flag - |
-
- Body, Point - |
-
| - - | -- - | -
| - - | -- - | -
| - - | -- - | -
| - - | -- - | -
|
- - |
- - - | -
|
- - |
- - - | -
- -
|
- Position - |
-
- What is.. - |
-
- How to… - |
-
| - - | -- - | -- - | -
| - - | -- - | -- - | -
| - - | -- - | -- - | -
| - - | -- - | -- - | -
| - - | -- - | -- - | -
| - - | -- - | -- - | -
| - - | -- - | -- - | -
| - - | -
- - |
- - - | -
| - - | -
- - |
- - - | -
| - - | -
- - |
-
- - |
-
| - - | -
- - |
-
- - |
-
| - - | -
- - |
-
- - |
-
- -
- -
- -
|
- Errors - |
-
- Variable - |
-
| - - | -- - | -
| - - | -- - | -
| - - | -- - | -
| - - | -- - | -
| - - | -- - | -
| - - | -- - | -
| - - | -- - | -
| - - | -- - | -
| - - | -- - | -
|
- - |
- - - | -
|
- - |
- - - | -
|
- - |
- - - | -
|
- - |
- - - | -
|
- - |
- - - | -
|
- - |
- - - | -
- -
|
- Function - |
-
- Description - |
-
| - - | -
- Computes - the horizontal coordinates (azimuth and altitude) - |
-
| - - | -
- computes - either ecliptical or equatorial coordinates from azimuth and true altitude - |
-
| - - | -
- computes - the positions of planets, asteroids, lunar nodes and apogees - |
-
| - - | -
- Modified version of swe_calc - |
-
| - - | -
- releases - most resources used by the Swiss Ephemeris - |
-
| - - | -
- Coordinate - transformation, from ecliptic to equator or vice-versa - |
-
| - - | -
- Coordinate - transformation of position and speed, from ecliptic to equator or vice-versa - |
-
| - - | -
- computes a Julian day from - year, month, day, time and checks whether a date is legal - |
-
| - - | -
- normalization of any degree number to the range 0 ... 360 - |
-
| - - | -
- Computes - the difference between Universal Time (UT, GMT) and Ephemeris time - |
-
| - - | -
- computes fixed stars - |
-
| - - | -
- Modified version of swe_fixstar - |
-
| - - | -
- Computes - the ayanamsha - |
-
| - - | -
- Modified version of swe_get_ayanamsa - |
-
| - - | -
- Finds a - planetary or asteroid name by given number - |
-
| - - | -
- Gets the - tidal acceleration - |
-
| - - | -
- compute the - house - position of a given body for a given ARMC - |
-
| - - | -
- Calculates - houses for a given date and geographic position - |
-
| - - | -
- computes - houses from ARMC (e.g. with the composite - horoscope which has no date) - |
-
| - - | -
- the same as - swe_houses(). Has a parameter, which can be used, if siderealhouse - positions are wanted - |
-
| - - | -
- Conversion - from day, month, year, time to Julian date - |
-
| - - | -
- Computes - the attributes of a lunar eclipse at a given time - |
-
| - - | -
- Finds the next lunar eclipse - |
-
| - - | -
- Computes - planetary nodes and apsides: perihelia, aphelia, second focal points of the - orbital ellipses - |
-
| - - | -
- Modified version of swe_nod_aps - |
-
| - - | -
- Function - computes phase, - phase angle, elongation, apparent diameter, apparent magnitude - |
-
| - - | -
- Modified version ofswe_pheno - |
-
| - - | -
- The true/apparent - altitude convertion - |
-
| - - | -
- Conversion - from Julian - date to day, month, year, time - |
-
| - - | -
- Computes - the times of rising, setting and meridian transits - |
-
| - - | -
- Set - application’s own ephemeris path - |
-
| - - | -
- Sets JPL ephemeris directory path - |
-
| - - | -
- Specifies - the sidereal modes - |
-
| - - | -
- Sets tidal acceleration used in swe_deltat() - |
-
| - - | -
- Sets what - geographic position is to be used before topocentric planet positions for a certain birth place can be computed - |
-
| - - | -
- returns sidereal time on Julian day - |
-
| - - | -
- returns sidereal time on Julian day, obliquity and nutation -- |
-
| - - | -
- Calculates - the solar - eclipse attributes for a given geographic position - and time - |
-
| - - | -
- finds the next solar eclipse - globally - |
-
| - - | -
- finds the - next solar eclipse for a given geographic position - |
-
| - - | -
- finds out - the geographic position where an eclipse is -central or maximal - |
-
| - - | -
- returns the - difference between local apparent and local mean time - |
-
- -
|
- PlaCalc function - |
-
- Description - |
-
| - - | -
- Normalize - argument into interval [0..DEG360] - |
-
| - - | -
- Centiseconds - -> degrees string - |
-
| - - | -
- Centiseconds - -> longitude or latitude string - |
-
| - - | -
- Centiseconds - -> time string - |
-
| - - | -
- Round - second, but at 29.5959 always down - |
-
| - - | -
- Double to - long with rounding, no overflow check - |
-
| - - | -
- Day of week - Monday = 0, ... Sunday = 6 - |
-
| - - | -
- Distance in - centisecs p1 – p2 normalized to [-180..180] - |
-
| - - | -
- Distance in - centisecs p1 – p2 normalized to [0..360] - |
-
| - - | -
- Distance in - degrees - |
-
| - - | -
- Distance in - degrees - |
-
- -
End of SWEPHPRG.DOC
- -Computer ephemeris for developers of -astrological software3
- - - - - -2. Descripition of the ephemerides. 5
- -2.1 Planetary and lunar ephemerides. 5
- - - - - - - - - -2.1.2.1 Swiss Ephemeris and the Astronomical -Almanac7
- -2.1.2.2 Swiss Ephemeris and JPL Horizons -System8
- -2.1.2.3 Differences between Swiss Ephemeris -1.70 and older versions8
- -2.1.2.4 Differences between Swiss Ephemeris -1.78 and 1.779
- -2.1.3 The details of coordinate -transformation10
- -2.1.4 The Swiss Ephemeris compression -mechanism11
- -2.1.5 The extension of the time range to -10'800 years12
- -2.2 Lunar and Planetary Nodes and -Apsides13
- -2.2.1 Mean Lunar Node and Mean Lunar -Apogee ('Lilith', 'Black Moon')13
- - - -2.2.3 The Osculating Apogee (so-called -'True Lilith' or 'True Dark Moon')14
- -2.2.4 The Interpolated or Natural Apogee -and Perigee (Lilith and Priapus)15
- -2.2.5 Planetary Nodes and Apsides 15
- - - - - -How the asteroids were computed. 19
- -Ceres, Pallas, Juno, Vesta. 20
- - - - - -”Ceres” - an application program for asteroid -astrology20
- - - -2.5 Fixed stars and Galactic Center20
- - - - - - - - - - - - - - - -Dr. Waldemath’s Black Moon. 22
- -The Planets X of Leverrier, Adams, Lowell and -Pickering22
- - - - - -The problem of defining the zodiac. 23
- -The Babylonian tradition and the Fagan/Bradley -ayanamsha23
- - - -The Spica/Citra tradition and the Lahiri ayanamsha. 26
- -The sidereal zodiac and the Galactic Center26
- - - - - -In search of correct algorithms. 27
- - - -3. Apparent versus true planetary -positions30
- -4. Geocentric versus topocentric and -heliocentric positions30
- -5. Heliacal Events, Eclipses, Occultations, and -Other Planetary Phenomena31
- -5.1. Heliacal Events of the Moon, Planets and -Stars31
- - - -5.1.2. Aspect determining visibility. 32
- -5.1.2.1. Position of celestial objects. 32
- -5.1.2.2. Geographic location. 32
- -5.1.2.3. Optical properties of observer32
- -5.1.2.4. Meteorological circumstances. 32
- -5.1.2.5. Contrast between object and sky -background32
- -5.1.3. Functions to determine the heliacal -events32
- -5.1.3.1. Determining the contrast threshold -(swe_vis_limit_magn)32
- -5.1.3.2. Iterations to determine when the -studied object is really visible (swe_heliacal_ut)32
- - - -5.1.3.4. Visibility of Venus and the Moon -during day33
- -5.1.4. Future developments. 33
- - - -5.2. Eclipses, occultations, risings, settings, -and other planetary phenomena34
- - - - - - - - - - - - - - - -6.1.6 Vehlow-equal System.. 35
- -6.1.7. Axial Rotation System.. 35
- -6.1.8. The Morinus System.. 35
- - - -6.1.10. The Polich-Page (“topocentric”) system.. 35
- - - - - -6.1.13. Krusinski/Pisa/Goelzer system.. 36
- -6.2. Vertex, Antivertex, East Point and -Equatorial Ascendant, etc.36
- -6.3. House cusps beyond the polar circle. 37
- -6.3.1. Implementation in other calculation -modules:37
- -6.4. House position of a planet38
- -6.5. Gauquelin sector position of a -planet38
- - - - - -9. Swiss Ephemeris Functions. 41
- - - -Calculation of planets and stars. 41
- - - -Initialization, setup, and closing functions. 42
- - - - - -Other functions that may be useful43
- - - - - -A. The gravity deflection for a planet passing -behind the Sun44
- - - - - -© 1997 - 2011 -by
- -Astrodienst AG
- -Dammstr. 23
- -Postfach -(Station)
- -CH-8702 Zollikon / Zürich, Switzerland
- -Tel. -+41-44-392 18 18
- -Fax +41-44-391 75 74
- -Email -to devlopers swisseph@astro.ch
- -- -
Authors: -Dieter Koch and Dr. Alois Treindl
- -- -
Editing -history:
- -14-sep-97 -Appendix A by Alois
- -15-sep-97 -split docu, swephprg.doc now separate (programming interface)
- -16-sep-97 -Dieter: absolute precision of JPL, position and speed transformations
- -24-sep-97 -Dieter: main asteroids
- -27-sep-1997 -Alois: restructured for better HTML conversion, added public function list
- -8-oct-1997 -Dieter: chapter 4 (houses) added
- -28-nov-1997 -Dieter: chapter 5 (delta t) added
- -20-Jan-1998 -Dieter: chapter 3 (more than...) added, chapter 4 (houses) enlarged
- -14-Jul-98: -Dieter: more about the precision of our asteroids
- -21-jul-98: -Alois: houses in PLACALC and ASTROLOG
- -27-Jul-98: -Dieter: True node chapter improved
- -2-Sep-98: -Dieter: updated asteroid chapter
- -29-Nov-1998: -Alois: added info on Public License and source code availability
- -4-dec-1998: -Alois: updated asteroid file information
- -17-Dec-1998: -Alois: Section 2.1.5 added: extended time range to 10'800 years
- -17-Dec-1998: -Dieter: paragraphs on Chiron and Pholus ephemerides updated
- -12-Jan-1999: -Dieter: paragraph on eclipses
- -19-Apr-99: -Dieter: paragraph on eclipses and planetary phenomena
- -21-Jun-99: -Dieter: chapter 2.27 on sidereal ephemerides
- -27-Jul-99: -Dieter: chapter 2.27 on sidereal ephemerides completed
- -15-Feb-00: -Dieter: many things for Version 1.52
- -11-Sep-00: -Dieter: a few additions for version 1.61
- -24-Jul-01: -Dieter: a few additions for version 1.62
- -5-jan-2002: -Alois: house calculation added to swetest for version 1.63
- -26-feb-2002: -Dieter: Gauquelin sectors for version 1.64
- -12-jun-2003: -Alois: code revisions for compatibility with 64-bit compilers, version 1.65
- -10-jul-2003: -Dieter: Morinus houses for Version 1.66
- -12-jul-2004: -Dieter: documentation of Delta T algorithms implemented with version 1.64
- -7-feb-2005: -Alois: added note about mean lunar elements, section 2.2.1
- -22-feb-2006: -Dieter: added documentation for version 1.70, see section 2.1.2.1-3
- -17-jul-2007: -Dieter: updated documentation of Krusinski-Pisa house system.
- -28-nov-2007: -Dieter: documentation of new Delta T calculation for version 1.72, see section -7
- -17-jun-2008: -Alois: License change to dual license, GNU GPL or Professional License
- -31-mar-2009: -Dieter: heliacal events
- -26-Feb-2010: -Alois: manual update, deleted references to CDROM
- -25-Jan-2011: -Dieter: Delta T updated, v. 1.77.
- -2-Aug-2012: -Dieter: New precession, v. 1.78.
- -23-apr-2013: -Dieter: new ayanamshas
- -- -
Swiss -Ephemeris Release history:
- -1.00 30-sept-1997
- -1.01 9-oct-1997 simplified -houses() and sidtime() functions, Vertex added.
- -1.02 16-oct-1997 houses() changed again
- -1.03 28-oct-1997 minor fixes
- -1.04 8-Dec-1997 minor -fixes
- -1.10 9-Jan-1998 bug -fix, pushed to all licensees
- -1.11 12-Jan-98 minor -fixes
- -1.20 21-Jan-98 NEW: topocentric planets and house positions
- -1.21 28-Jan-98 Delphi -declarations and sample for Delphi 1.0
- -1.22 2-Feb-98 Asteroids moved to subdirectory. -Swe_calc() finds them there.
- -1.23 11-Feb-98 two -minor bug fixes.
- -1.24 7-Mar-1998 Documentation for Borland C++ -Builder added
- -1.25 4-June-1998 sample for Borland Delphi-2 added
- -1.26 29-Nov-1998 source added, Placalc API added
- -1.30 17-Dec-1998 NEW:Time range extended to 10'800 years
- -1.31 12-Jan-1999 NEW: Eclipses
- -1.40 19-Apr-1999 NEW: planetary phenomena
- -1.50 27-Jul-1999 NEW: sidereal ephemerides
- -1.52 15-Feb-2000 - Several NEW -features, minor bug fixes
- -1.60 15-Feb-2000 Major release with many new features and some minor bug fixes
- -1.61 11-Sep-2000 Minor release, additions to se_rise_trans(), swe_houses(), -ficitious planets
- -1.62 23-Jul-2001 Minor release, fictitious earth satellites, asteroid numbers -> 55535 possible
- -1.63 5-Jan-2002 Minor -release, house calculation added to swetest.c and swetest.exe
- -1.64 7-Apr-2002 NEW: occultations of planets, -minor bug fixes, new Delta T algorithms
- -1.65 12-Jun-2003 Minor release, small code renovations for 64-bit compilation
- -1.66 10-Jul-2003 NEW: Morinus -houses
- -1.67 31-Mar-2005 Minor release: Delta-T updated, minor bug fixes
- -1.70 - 2-Mar-2006 IAU resolutions up to 2005 implemented; "interpolated" -lunar apsides
- -1.72 28-nov-2007 Delta T calculation according to Morrison/Stephenson 2004
- -1.74 17-jun-2008 License model changed to dual license, GNU GPL or Professional -License
- -1.76 31-mar-2009 NEW: Heliacal events
- -1.77 25-jan-2011 Delta T calculation updated acc. to Espenak/Meeus 2006, new fixed -stars file
- -1.78 2-aug-2012 Precession -calculation updated acc. to Vondrák et alii 2012
- -1.79 23-apr-2013 New ayanamshas, improved precision of eclipse functions, minor -bug fixes
- -Swiss Ephemeris is a function -package for the computation of planetary positions. It includes the planets, -the moon, the lunar nodes, the lunar apogees, the main asteroids, Chiron, -Pholus, the fixed stars and several ”hypothetical” bodies. Hundreds of other -minor planets are included as well. Ephemeris files all numbered asteroids are -available for download.
- -The precision of the Swiss Ephemeris is very high. It is at least as -accurate as the Astromical Almanac, the standard planetary and lunar tables -astronomers refer to. Swiss Ephemeris will, as we hope, -be able to keep abreast to the scientific advances in ephemeris computation for -the coming decades. The expense will be small. In most cases an update of the -data files will do.
- -The Swiss Ephemeris package consists of a DLL, a -collection of ephemeris files and a few sample programs which demonstrate the -use of the DLL and the Swiss Ephemeris graphical label. The ephemeris files -contain compressed astronomical ephemerides (in equatorial rectangular -coordinates referred to the mean equinox 2000 and the solar system barycenter). -The DLL is mainly the code that reads these files and converts the raw data to -positions as required in astrology (calculation of light-time, transformation -to the geocenter and the true equinox of date, etc.).
- -Full C source code is included with the Swiss Ephemeris, so that -not-Windows programmers can create a linkable or shared library in their -environment and use it with their application.
- -The Swiss Ephemeris is not a product for end users. It is a toolset for
-programmers to build into their astrological software.
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 choses 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 choses 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.
- -The Swiss Ephemeris Professional Edition can be purchased from -Astrodienst for a one-time fixed fee for each commercial programming -project. The license is just a legal document. All actual software and data are -found in the public download area and are to be downloaded from there.
- -Professional license: The license fee for the first -license is Swiss Francs (CHF) 750.- , and CHF 400.- for each additional license by the same licensee. An unlimited -license is available for CHF 1550.-.
- -The Swiss Ephemeris package allows planetary and lunar computations from -any of the following three astronomical ephemerides:
- -The core part of Swiss Ephemeris is a compression of the JPL-Ephemeris -DE406. Using a sophisticated mechanism, -we succeeded in reducing JPL's 200 MB storage to only 18 MB. The agreement with -DE406 is within 1 milli-arcsecond -(0.001”). Since the inherent -uncertainty of the JPL ephemeris for most of its time range is much greater, -Swiss Ephemeris should be completely satisfying even for computations demanding -very high accuracy.
- -The time range of the JPL ephemeris is 3000 BC to 3000 AD or 6000 years. -We have extended this time range to 10'800 years, from 2 Jan 5401 BC to 31 Dec 5399. The details of this -extension are described below in section 2.1.5.
- -Each Swiss Ephemeris file covers a period of 600 years; there are 18 -planetary files, 18 Moon files and 18 main-asteroid files for the whole time -range of 10'800 years.
- -The file names are as follows:
- -|
- Planetary file - |
-
- Moon file - |
-
- Main asteroid file - |
-
- Time range - |
-
|
- seplm54.se1 - |
-
- semom54.se1 - |
-
- seasm54.se1 - |
-
- 5401 BC – 4802 BC - |
-
|
- seplm48.se1 - |
-
- semom48.se1 - |
-
- seasm48.se1 - |
-
- 4801 BC – 4202 BC - |
-
|
- seplm42.se1 - |
-
- semom42.se1 - |
-
- seasm42.se1 - |
-
- 4201 BC – 3602 BC - |
-
|
- seplm36.se1 - |
-
- semom36.se1 - |
-
- seasm36.se1 - |
-
- 3601 BC – 3002 BC - |
-
|
- seplm30.se1 - |
-
- semom30.se1 - |
-
- seasm30.se1 - |
-
- 3001 BC – 2402 BC - |
-
|
- seplm24.se1 - |
-
- semom24.se1 - |
-
- seasm24.se1 - |
-
- 2401 BC – 1802 BC - |
-
|
- seplm18.se1 - |
-
- semom18.se1 - |
-
- seasm18.se1 - |
-
- 1801 BC – 1202 BC - |
-
|
- seplm12.se1 - |
-
- semom12.se1 - |
-
- seasm12.se1 - |
-
- 1201 BC – 602 BC - |
-
|
- seplm06.se1 - |
-
- semom06.se1 - |
-
- seasm06.se1 - |
-
- 601 BC – 2 BC - |
-
|
- sepl_00.se1 - |
-
- semo_00.se1 - |
-
- seas_00.se1 - |
-
- 1 BC – 599 AD - |
-
|
- sepl_06.se1 - |
-
- semo_06.se1 - |
-
- seas_06.se1 - |
-
- 600 AD – 1199 AD - |
-
|
- sepl_12.se1 - |
-
- semo_12.se1 - |
-
- seas_12.se1 - |
-
- 1200 AD – 1799 AD - |
-
|
- sepl_18.se1 - |
-
- semo_18.se1 - |
-
- seas_18.se1 - |
-
- 1800 AD – 2399 AD - |
-
|
- sepl_24.se1 - |
-
- semo_24.se1 - |
-
- seas_24.se1 - |
-
- 2400 AD – 2999 AD - |
-
|
- sepl_30.se1 - |
-
- semo_30.se1 - |
-
- seas_30.se1 - |
-
- 3000 AD – 3599 AD - |
-
|
- sepl_36.se1 - |
-
- semo_36.se1 - |
-
- seas_36.se1 - |
-
- 3600 AD – 4199 AD - |
-
|
- sepl_42.se1 - |
-
- semo_42.se1 - |
-
- seas_42.se1 - |
-
- 4200 AD – 4799 AD - |
-
|
- sepl_48.se1 - |
-
- semo_48.se1 - |
-
- seas_48.se1 - |
-
- 4800 AD – 5399 AD - |
-
- -
The blue file names in the table -indicate that a file is derived directly from the JPL data, whereas the other -files are derived from Astrodienst's own numerical integration.
- -All Swiss Ephemeris files for Version 1 have the file suffix .se1.
- -A planetary file is about 500 -kb, a lunar file 1300 kb.
- -Swiss Ephemeris files are distributed with the SWISSEPH package. They -are also available for download from Astrodienst's web server.
- -The time range of the Swiss Ephemeris
- -Start date 2 Jan 5401 BC (jul. calendar) = JD -251291.5
- -End date 31 -Dec 5399 AD (greg. Cal.) = JD -3693368.5
- -A note -on year numbering:
- -There are -two numbering systems for years before the year 1 AD. The historical numbering -system (indicated with BC) has no year zero. Year 1 BC is followed directly by -year 1 AD.
- -The -astronomical year numbering system does have a year zero; years before the -common era are indicated by negative year numbers. The sequence is year -1, -year 0, year 1 AD.
- -The -historical year 1 BC corresponds to astronomical year 0,
- -the -historical your 2 BC corresponds to astronomical year -1, etc.
- -In this -document and other documents related to the Swiss Ephemeris we use both systems -of year numbering. When we write a negative year number, it is astronomical -style; when we write BC, it is historical style.
- -This is a semi-analytical approximation of the JPL planetary and lunar -ephemerides, currently based on the DE404 ephemeris, developed by Steve -Moshier. Its deviation from JPL is well below 1 arc second with the planets and -a few arc seconds with the moon. No data files are required for this -ephemeris, as all data are linked into the program code already.
- -This may be sufficient accuracy for most astrologers, since the moon -moves 1 arc second in 2 time seconds and the sun 2.5 arc seconds in one minute. -
- -However, if you work with the 'true' lunar node, which is derived from -the lunar ephemeris, you will have to accept an error of about 1 arc minute. To -get a position better than an arc second, you will have to spend 1.3 MB for the -lunar ephemeris file 'semo_18.se1' of Swiss Ephemeris.
- -The advantage of the Moshier ephemeris is that it needs no disk storage. -Its disadvantage besides the limited precision is reduced speed: it is about 10 -times slower than JPL and Swiss Ephemeris.
- -The Moshier Ephemeris covers the interval from 3000 BC to 3000 AD. -However, “the adjustment for the inner planets is strictly valid only from 1350 -B.C. to 3000 A.D., but may be used to 3000 B.C. with some loss of precision”. -And: “The Moon's position is calculated -by a modified version of the lunar theory of Chapront-Touze' and Chapront. This -has a precision of 0.5 arc second relative to DE404 for all dates between 1369 -B.C. and 3000 A.D. “ (Moshier, http://www.moshier.net/aadoc.html).
- -This is the full precision state-of-the-art ephemeris. It provides the -highest precision and is the basis of the Astronomical Almanac.
- -JPL is the Jet Propulsion Laboratory of NASA in Pasadena, CA, USA (see http://www.jpl.nasa.gov ). Since many years this -institute which is in charge of the planetary missions of NASA has been the -source of the highest precision planetary ephemerides. The currently newest -version of JPL ephemeris is the DE405/DE406. As most previous ephemerides, it -has been created by Dr. Myles Standish.
- -According to a paper (see below) by Standish and others on DE403 (of -which DE406 is only a slight refinement), the accuracy of this ephemeris can be -partly estimated from its difference from DE200:
- -With the inner planets, Standish shows that within the period -1600 – 2160 there is a maximum difference of 0.1 – 0.2” which is mainly due to -a mean motion error of DE200. This means that the absolute precision of DE406 -is estimated significantly better than 0.1” over that period. However, for the -period 1980 – 2000 the deviations between DE200 and DE406 are below 0.01” for all -planets, and for this period the JPL integration has been fit to measurements -by radar and laser interferometry, which are extremely precise.
- -With the outer planets, Standish's diagrams show that there are -large differences of several ” around 1600, and he says that these deviations -are due to the inherent uncertainty of extrapolating the orbits beyond the -period of accurate observational data.The uncertainty of Pluto exceeds -1” before 1910 and after 2010, and increases rapidly in more remote past or -future.
- -With the moon, there is an increasing difference of 0.9”/cty2 between 1750 and -2169. It comes mainly from errors in LE200 (Lunar Ephemeris).
- -The differences between DE200 and DE403 (DE406) can be summarized as -follows:
- -1980 – 2000 all -planets < -0.01”,
- -1600 – 1980 Sun – Jupiter a few 0.1”,
- -1900 – 1980 Saturn – Neptune a -few 0.1”,
- -1600 – 1900 Saturn – Neptune a -few ”,
- -1750 – 2169 Moon a few ”.
- -(see: E.M. Standish, X.X. Newhall, J.G. Williams, and W.M. Folkner, JPL -Planetary and Lunar Ephemerides, DE403/LE403, JPL Interoffice Memorandum -IOM 314.10-127, May 22, 1995, pp. 7f.)
- -- -
The DE406 is a 200 Megabyte file available for download from the JPL
-server ftp://navigator.jpl.nasa.gov/ephem/export or on CD-ROM from the astronomical publisher
-Willman-Bell, see http://www.willbell.com.
-
-Astrodienst has received permission from Dr. Standish to include the file on
-the Swiss Ephemeris CD-ROM.
There are several versions of the JPL Ephemeris. The version is -indicated by the DE-number. A higher number stands for a later update. SWISSEPH -should be able to read any JPL file from DE200 upwards.
- -The time range of this ephemeris (DE406) is:
- -start date 23 -Feb 3001 BC (28 Jan greg.) = JD 625360.5,
- -end date 3 Mar 3000 AD = JD 2816848.5.
- -Swiss Ephemeris is based on the latest -JPL file, and reproduces the full JPL precision with better than 1/1000 of an -arc second, while requiring only 18 Mb instead of 200 Mb. Therefore for most -applications it makes little sense to get the full JPL file, except to compare -the precision. Precision comparison can also be done at the Astrodienst web -server, because we have a test utility online which allows to compute planetary -positions for any date with any of the three ephemerides.
- -For the extension of the JPL time range to 5400 BC - 5400 AD please see -section 2.5.1 below.
- -The original JPL ephemeris gives barycentric equatorial Cartesian -positions of the equinox 2000. Moshier provides heliocentric positions. The conversions to apparent geocentric -ecliptical positions were done with the algorithms and constants of the -Astronomical Almanac as described in the ”Explanatory Supplement to the -Astronomical Almanac”. Using the DE200 data file, it is possible to reproduce -the positions given by the Astronomical Almanac 1995, 1996, and 1997 down to -the last digit. Editions of other years have not been checked.
- -Since 2003, the Astronomical Almanac has been using JPL ephemeris DE405, -and since Astronomical Almanac 2006 all relevant resolutions of the -International Astronomical Union (IAU) have been implemented. Versions 1.70 and -higher of the Swiss Ephemeris also follow these resolutions and reproduce the -sample calculation given by AA2006, page B61-B63, to the last digit, i.e. to better than 0.001 arc second. (To -avoid confusion when checking this, it may be useful to know that the JD given -on page B62 does not have enough digits in order to produce the correct final -result.)
- -The Swiss Ephemeris, from Version 1.70 on, reproduces astrometric planetary positions of the -JPL Horizons System precisely. However, there are small differences with the apparent positions. The reason is that -the Horizons System still uses the old precession model IAU 1976 (Lieske) and -nutation IAU 1980 (Wahr). This was confirmed by Jon Giorgini from JPL in an -E-mail of 3 Feb. 2006.
- -Note on 2 August 2012. It seems that this is still true, according to -the documentation of the Horizons System at: -http://ssd.jpl.nasa.gov/?horizons_doc#longterm
- -With version 1.70, the standard algorithms recommended by the IAU -resolutions up to 2005 were implemented. The following calculations have been -added or changed with Swiss Ephemeris version 1.70:
- -- "Frame Bias" transformation from ICRS to J2000.
- -- Nutation IAU 2000B (could be switched to 2000A by the user)
- -- Precession model P03 (Capitaine/Wallace/Chapront 2003), including -improvements in ecliptic obliquity and sidereal time that were achieved by this -model
- -The differences between the old and new planetary positions in ecliptic longitude (arc seconds) are:
- - - -2000 -0.00108
- -1995 0.02448
- -1980 0.05868
- -1970 0.10224
- -1950 0.15768
- -1900 0.30852
- -1800 0.58428
- -1799 -0.04644
- -1700 -0.07524
- -1500 -0.12636
- -1000 -0.25344
- -0 -0.53316
- --1000 -0.85824
- --2000 -1.40796
- --3000 -3.33684
- --4000 -10.64808
- --5000 -32.68944
- --5400 -49.15188
- -The discontinuity of the curve between 1800 and 1799 is explained by the -fact that the old Swiss Ephemeris used different precession models for -different time ranges: the model IAU 1976 by Lieske for 1800 - 2200, and the -precession model by Williams 1994 outside of that time range.
- -Note: In the literature there are no indications concerning the -long-term use of the precession model P03. It is said to be accurate to 0.00005 -arc second for CE 1000-3000. However, there is no reason to trust alternative -models (e.g. Bretagnon 2003) more for the whole period of the Swiss Ephemeris.
- -The differences between version 1.70 and older versions for the future -are as follows:
- -2000 -0.00108
- -2010 -0.01620
- -2050 -0.14004
- -2100 -0.29448
- -2200 -0.61452
- -2201 0.05940
- -3000 0.27252
- -4000 0.48708
- -5000 0.47592
- -5400 0.40032
- -The discontinuity in 2200 has the same explanation as -the one in 1800.
- -- -
Jyotish / sidereal -ephemerides:
- -The ephemeris changes by a constant value of about +0.3 arc second. This -is because all our ayanamsas have the start epoch 1900, for which epoch -precession was corrected by the same amount.
- -- -
Fictitious planets -/ Bodies from the orbital elements file seorbel.txt:
- -There are changes of several 0.1 arcsec, depending on the epoch of the -orbital elements and the correction of precession as can be seen in the tables -above.
- -- -
The differences for ecliptic obliquity in arc seconds (new - old) are:
- -5400 -1.71468
- -5000 -1.25244
- -4000 -0.63612
- -3000 -0.31788
- -2100 -0.06336
- -2000 -0.04212
- -1900 -0.02016
- -1800 0.01296
- -1700 0.04032
- -1600 0.06696
- -1500 0.09432
- -1000 0.22716
- -0 0.51444
- --1000 1.07064
- --2000 2.62908
- --3000 6.68016
- --4000 15.73272
- --5000 33.54480
- --5400 44.22924
- -- -
The differences for sidereal time in -seconds (new - old) are:
- -5400 -2.544
- -5000 -1.461
- -4000 -0.122
- -3000 0.126
- -2100 0.019
- -2000 0.001
- -1900 0.019
- -1000 0.126
- -0 -0.122
- --500 -0.594
- --1000 -1.461
- --2000 -5.029
- --3000 -12.355
- --4000 -25.330
- --5000 -46.175
- --5400 -57.273
- -Former versions of the Swiss Ephemeris had used the precession model by -Capitaine, Wallace, and Chapront of 2003 for the time range 1800-2200 and the -precession model J. G. Williams in Astron. J. 108, 711-724 (1994) for epochs -outside this time range.
- -Version 1.78 calculates precession and ecliptic obliquity according to -Vondrák, Capitaine, and Wallace, “New precession expressions, valid for long -time intervals”, A&A 534, A22 (2011), which is good for +- 200 millennia.
- -This change has almost no effect for historical epochs. Planetary -positions and the obliquity of the ecliptic change by less than an arc minute -in 5400 BC. However, for research concerning the prehistoric cave paintings of -Lascaux, Altamira, etc, some of which may represent celestial constellations, -fixed star positions are required for 15’000 BC or even earlier (the Chauvet -cave was painted in 33’000 BC). Such calculations are now possible using the -Swiss Ephemeris version 1.78 or higher. However, the Sun, Moon, and the planets -remain restricted to the time range 5400 BC to 5400 AD.
- -Differences in precession (v. 1.78 – v. 1.77, test star was Aldebaran):
- -Year Difference in arc sec
- --20000 -26715"
- --15000 -2690"
- --10000 -256"
- --5000 -3.95388" -
- --4000 -9.77904" -
- --3000 -7.00524" -
- --2000 -3.40560" -
- --1000 -1.23732" -
- -0 -0.33948" -
- -1000 -0.05436" -
- -1800 -0.00144" -
- -1900 -0.00036" -
- -2000 0.00000" -
- -2100 -0.00036" -
- -2200 -0.00072" -
- -3000 0.03528" -
- -4000 0.59904" -
- -5000 2.90160" -
- -10000 76"
- -15001 -227"
- -19000 -2839"
- -20000 -5218"
- -- -
Differences in -ecliptic obliquity
- -- -
Year Difference in arc sec
- --20000 11074.43664"
- --15000 3321.50652"
- --10000 632.60532"
- --5000 -33.42636"
- -0 0.01008"
- -1000 0.00972"
- -2000 0.00000"
- -3000 -0.01008"
- -4000 -0.05868"
- -10000 -72.91980"
- -15000 --772.91712"
- -20000 --3521.23488”
- -The following conversions are applied to the coordinates after reading -the raw positions from the ephemeris files and before output:
- -Correction for light-time. Since the planet's light -needs time to reach the earth, it is never seen where it actually is, but where -it was some time before. Light-time is a few minutes with the inner planets and -a few hours with distant planets like Uranus, Neptune and Pluto. For the moon, -the light-time correction is about one second. With planets, light-time -correction may be of the order of 20” in position, with the moon 0.5”
- -Conversion from the solar system barycenter to the -geocenter. Original JPL data are referred to the center of the gravity of the -solar system. Apparent planetary positions are referred to an imaginary -observer in the center of the earth.
- -Light deflection by the gravity of the sun. In gravitational -fields of the sun and the planets light rays are bent. However, within the -solar system only the sun has mass enough to deflect light significantly. -Gravity deflection is greatest for distant planets and stars, but never greater -than 1.8”. When a planet disappears behind the sun, the Explanatory -Supplement recommends to set the deflection = 0. To avoid discontinuities, -we chose another procedure. See Appendix A.
- -”Annual” aberration of light. The velocity of -light is finite, and therefore the apparent direction of a moving body from a -moving observer is never the same as it would be if both the planet and the -observer stood still. For comparison: if you run through the rain, the rain -seems to come from ahead even though it actually comes from above. Aberration -may reach 20”.
- -Frame Bias (ICRS to J2000). The JPL ephemeris -DE405/DE406 is referred to the International Celestial Reference System, a -time-independent, non-rotating reference system which was recommended by the -IAU in 1997. The planetary positions and speed vectors are rotated to the J2000 -system. This transformation makes a difference of only about 0.0068 arc seconds -in right ascension. (Implemented from Swiss Ephemeris 1.70 on)
- -Precession. The motion of the vernal -equinox, which is an effect of the influences of solar, lunar, and planetary -gravity on the equatorial bulge of the earth. Original JPL data are referred to -the mean equinox of the year 2000. Apparent planetary positions are referred to -the equinox of date. (From Swiss Ephemeris 1.78 on, we use the -precession model Vondrák/Capitaine/Wallace 2011.)
- -Nutation (true equinox of date). -A short-period oscillation of the vernal equinox. It results from the moons -gravity which acts on the equatorial bulge of the earth. The period of nutation -is identical to the period of a cycle of the lunar node, i.e. 18.6 years. The -difference between the true vernal point and the mean one is always below 17”. -(From Swiss Ephemeris 1.70 on, we use the nutation model IAU 2000. Older -versions used the nutation model IAU 1980 (Wahr).)
- -Transformation from equatorial to ecliptic coordinates.
- -- -
For precise speed of the planets and the moon, we had to make a -special effort, because the Explanatory Supplement does not give -algorithms that apply the above-mentioned transformations to speed. Since this -is not a trivial job, the easiest way would have been to compute three -positions in a small interval and determine the speed from the derivation of -the parabola going through them. However, double float calculation does not -guarantee a precision better than 0.1”/day. Depending on the time difference -between the positions, speed is either good near station or during fast motion. -Derivation from more positions and higher order polynomials would not help -either.
- -Therefore we worked out a way to apply directly all the transformations -to the barycentric speeds that can be derived from JPL or Swiss Ephemeris. The -speed precision is now better than 0.002” for all planets, and the computation -is even much faster than it would have been from three positions. A position -with speed takes in average only 1.66 times longer than one without speed, if a -JPL or a Swiss Ephemeris position is computed. With Moshier, however, a -computation with speed takes 2.5 times longer.
- -The idea behind our mechanism of ephemeris compression was developed by -Dr. Peter Kammeyer of the U.S. Naval Observatory in 1987.
- -To make it simple, it works as follows:
- -The lunar and the inner planets ephemerides require by far the largest -part of the storage. A more sophisticated mechanism is needed for them than for -the outer planets. Instead of the -positions we store the differences between JPL and the mean orbits of the -analytical theory VSOP87. These differences are much smaller than the position -values, wherefore they require less storage. -They are stored in Chebyshew polynomials covering a period of an -anomalistic cycle each. (By the way, this is the reason, why Swiss Ephemeris -begins only with 4 Nov -3000 (instead of 23 Feb -3000 as JPL). This is the date, when the last of the inner -planets Mars has its first perihelion after the start date of DE406.)
- -With the outer planets from Jupiter through Pluto we use a simpler -mechanism. We rotate the positions provided by DE406 to the mean plane of the -planet. This has the advantage that only two coordinates have high values, -whereas the third one becomes very small. The data are stored in Chebyshew -polynomials that cover a period of 4000 days each. (This is the reason, why Swiss Ephemeris stops in the year 2991 -AD. 4000 days later is a date beyond 3000 AD)
- -The JPL ephemeris covers the time range from 3000 BC to 3000 AD. While -this is an excellent range covering all precisely known historical events, -there are some types of astrological and historical research which would -welcome a longer time range.
- -In December 1998 we have made an effort to extend the time range by our -own numerical integration. The exact physical model used by Standish et. al. -for the numerical integration of the DE406 ephemeris is not fully documented -(at least we do not understand some details), so that we cannot use the same -integration program as had been used at JPL for the creation of the original -ephemeris.
- -The previous JPL ephemeris, the DE200, however has been reproduced by -Steve Moshier over a very long time range with his integration program, which -has been available to us. We have used this integration program with start -vectors taken at the end points of the DE406 time range. To test our numerical -integrator, we ran it upwards from 3000 BC to 600 BC for a period of 2400 years -and compared its results with the DE406 ephemeris itself. The agreement is -excellent for all planets except the Moon (see table below). The lunar orbit -creates a problem because the physical model for the Moon's libration and the -effect of the tides on lunar motion is quite different in the DE406 from the -model in the DE200. We have varied the tidal coupling parameter (love number) -and the longitudinal libration phase at the start epoch until we found the best -agreement over the 2400 year test range between our integration and the JPL -data. We could reproduce the Moon's motion over a the 2400 time range with a -maximum error of 12 arcseconds. For most of this time range the agreement is -better than 5 arcsec.
- -With these modified parameters we ran the integration backward in time -from 3000 BC to 5400 BC. It is reasonable to assume that the integration errors -in the backward integration are not significantly different from the -integration errors in the upward integration.
- -|
- planet - |
-
- max. error arcsec - |
-
- avg. error arcec - |
-
|
- Mercury - |
-
- 1.67 - |
-
- 0.61 - |
-
|
- Venus - |
-
- 0.14 - |
-
- 0.03 - |
-
|
- Earth - |
-
- 1.00 - |
-
- 0.42 - |
-
|
- Mars - |
-
- 0.21 - |
-
- 0.06 - |
-
|
- Jupiter - |
-
- 0.85 - |
-
- 0.38 - |
-
|
- Saturn - |
-
- 0.59 - |
-
- 0.24 - |
-
|
- Uranus - |
-
- 0.20 - |
-
- 0.09 - |
-
|
- Neptune - |
-
- 0.12 - |
-
- 0.06 - |
-
|
- Pluto - |
-
- 0.12 - |
-
- 0.04 - |
-
|
- Moon - |
-
- 12.2 - |
-
- 2.53 - |
-
|
- Sun bary. - |
-
- 6.3 - |
-
- 0.39 - |
-
- -
The same procedure was applied -at the upper end of the DE406 range, to cover an extension period from 3000 AD -to 5400 AD. The maximum integration errors as determined in the test run 3000 -AD down to 600 AD are given in the table below.
- -|
- planet - |
-
- max. error arcsec - |
-
- avg. error arcsec - |
-
|
- Mercury - |
-
- 2.01 - |
-
- 0.69 - |
-
|
- Venus - |
-
- 0.06 - |
-
- 0.02 - |
-
|
- Earth - |
-
- 0.33 - |
-
- 0.14 - |
-
|
- Mars - |
-
- 1.69 - |
-
- 0.82 - |
-
|
- Jupiter - |
-
- 0.09 - |
-
- 0.05 - |
-
|
- Saturn - |
-
- 0.05 - |
-
- 0.02 - |
-
|
- Uranus - |
-
- 0.16 - |
-
- 0.07 - |
-
|
- Neptune - |
-
- 0.06 - |
-
- 0.03 - |
-
|
- Pluto - |
-
- 0.11 - |
-
- 0.04 - |
-
|
- Moon - |
-
- 8.89 - |
-
- 3.43 - |
-
|
- Sun bary. - |
-
- 0.61 - |
-
- 0.05 - |
-
- -
We expect that in some time a full integration program modeled after the -DE406 integrator will become available. At that time we will rerun our -integration and report any significant differences.
- -- -
Our mean node and mean apogee are computed from Moshier's lunar routine, -which adjusts the ELP2000-85 lunar theory of Chapront-Touzé and Chapront to fit -the JPL ephemeris on the interval from 3000 BC to 3000 AD. Its deviation from -Chapront's mean node is 0 for J2000 and keeps below 20 arc seconds for the -whole period. With the apogee, the deviation reaches 3 arc minutes at 3000 BC
- -Lilith or the Dark Moon is either the apogee -(”aphelion”) of the lunar orbital ellipse or, for some people, its empty focal -point. As seen from the geocenter, this -makes no difference. Both of them are located in exactly the same direction. -But the definition makes a difference for topocentric ephemerides.
- -Because the Earth is located in one of the two focuses of the ellipse, -it has also been argued that the second focal point ought to be called ”Dark -Earth” rather than ”Dark Moon” (Ernst Ott).
- -The opposite point, the lunar perigee or orbital point closest to the Earth, -is also known as Priapus. However, if Lilith is understood as the second -focus, an opposite point makes no sense, of course.
- -Originally, the term ”Dark Moon” was used for a hypothetical second body -that was believed to move around the earth. There are still ephemerides around -for such a body, but today’s observational skills and knowledge in celestial -mechanics clearly exclude the possibility of such an object. As a result of -confusion, the term ”Dark Moon” was later given to the lunar apogee. However, -from the astrological symbolism of the lunar apogee, the expression ”Dark Moon” -seems to be appropriate.
- -The Swiss Ephemeris apogee differs from the ephemeris given by Joëlle de -Gravelaine in her book ”Lilith, der schwarze Mond” (Astrodata 1990). The difference -reaches several arc minutes. The mean apogee (or perigee) moves along the mean -lunar orbit which has an inclination of 5 degrees. Therefore it has to be -projected on the ecliptic. With de Gravelaine's ephemeris, this has been -forgotten and therefore the book contains a false ephemeris. As a result of -this projection, we also provide an ecliptic latitude of the apogee, which will -be of importance if you work with declinations.
- -There may be still another problem. The 'first' focal point does not coincide -with the geocenter but with the barycenter of the earth-moon-system. The -difference is about 4700 km. If one took this into account, it would result in -a monthly oscillation of the Black Moon. If one defines it as the apogee, this -oscillation would be about +/- 40 arc minutes. If one defines it as the second -focus, the effect is much greater: +/- 6 degrees! However, we have neglected -this effect.
- -[added by Alois 7-feb-2005, arising out of a discussion with Juan -Revilla] The concept of 'mean lunar orbit' means that short term. e.g. monthly, -fluctuations must not be taken into account. In the temporal average, the EMB -coincides with the geocenter. Therefore, when mean elements are computed, it is -correct only to consider the geocenter, not the Earth-Moon Barycenter.
- -In addition, computing topocentric positions of mean elements is also -meaningless and should not be done.
- -The 'true' lunar node is usually considered to be the osculating node -element of the momentary lunar orbit. I.e., the axis of the lunar nodes is the -intersection line of the momentary orbital plane of the moon and the plane of -the ecliptic. Or in other words, the nodes are the intersections of the two -great circles representing the momentary apparent orbit of the moon and the -ecliptic.
- -The nodes are considered to be important because they are connected with -the eclipses. They are the meeting points of the sun and the moon. From this -point of view, a more correct definition might be: The axis of the lunar nodes -is the intersection line of the momentary orbital plane of the moon and the -momentary orbital plane of the sun.
- -This makes a difference! Because of the monthly motion of the earth -around the earth-moon barycenter, the sun is not exactly on the ecliptic but -has a latitude, which, however, is always below an arc second. Therefore the -momentary plane of the sun's motion is not identical with the ecliptic. For the -true node, this would result in a difference in longitude of several arc -seconds! However, Swiss Ephemeris -computes the traditional version.
- -The advantage of the 'true' nodes against the mean ones is that when the -moon is in exact conjunction with them, it has indeed a zero latitude. This is -not true with the mean nodes.
- -However, in the strict sense of the word, even the ”true” nodes are true -only twice a month, viz. at the times when the moon crosses the ecliptic. -Positions given for the times in between those two points are just a -hypothesis. They are founded on the idea that celestial orbits can be approximated -by elliptical elements. This works well with the planets, but not with the -moon, because its orbit is strongly perturbed by the sun. Another procedure, -which might be more reasonable, would be to interpolate between the true node -passages. The monthly oscillation of the node would be suppressed, and the -maximum deviation from the conventional ”true” node would be about 20 arc -minutes.
- -Precision of the true node:
- -The true node can be computed from all of our three ephemerides. If you want a precision of the order of at -least one arc second, you have to choose either the JPL or the Swiss Ephemeris.
- -Maximum differences:
- -JPL-derived node – Swiss-Ephemeris-derived node ~ 0.1 arc second
- -JPL-derived node – Moshier-derived node ~ 70 arc seconds
- -(PLACALC was not better either. Its error was often > 1 arc minute.)
- -The position of 'True Lilith' is given in the 'New International -Ephemerides' (NIE, Editions St. Michel) and in Francis Santoni 'Ephemerides de -la lune noire vraie 1910-2010' (Editions St. Michel, 1993). Both Ephemerides -coincide precisely.
- -The relation of this point to the mean apogee is not exactly of the same -kind as the relation between the true node and the mean node. Like the 'true' node, it can be considered -as an osculating orbital element of the lunar motion. But there is an important -difference: The apogee contains the concept of the ellipse, whereas the node -can be defined without thinking of an ellipse. As has been shown above, the -node can be derived from orbital planes or great circles, which is not possible -with the apogee. Now ellipses are good as a description of planetary orbits, -but not of the lunar orbit which is strongly perturbed by the gravity of the -sun. The lunar orbit is far away from being an ellipse!
- -However, the osculating apogee is 'true' twice a month: when it is in -exact conjunction with the moon, the moon is most distant from the earth; and -when it is in exact opposition to the moon, the moon is closest to the -earth. In between those two points, the -value of the osculating apogee is pure imagination. The amplitude of the -oscillation of the osculating apogee around the mean apogee is +/- 25 -degrees, while the true apogee's deviation from the mean one never -exceeds 5 degrees.
- -It has also to be mentioned, that there is a small difference between -the NIE's 'true Lilith' and our osculating apogee, which results from an -inaccuracy in NIE. The error reaches 20 arc minutes. According to Santoni, the -point was calculated using 'les 58 premiers termes correctifs au perigée moyen' -published by Chapront and Chapront-Touzé. And he adds: ”Nous constatons que -même en utilisant ces 58 termes correctifs, l'erreur peut atteindre -0,5d!” (p. -13) We avoid this error, computing the orbital elements from the position and -the speed vectors of the moon. (By the way, there is also an error of +/- 1 arc -minute in NIE's true node. The reason is probably the same.)
- -Precision:
- -The osculating apogee can be computed from any one of the three -ephemerides. If you want a precision of the order of at least one arc second, -you have to choose either the JPL or the Swiss Ephemeris.
- -Maximum differences:
- -JPL-derived apogee – Swiss-Ephemeris-derived apogee ~ 0.9 arc second
- -JPL-derived apogee – Moshier-derived apogee ~ 360 arc seconds = -6 arc minutes!
- -There have been several other attempts to solve the problem of a 'true' -apogee. They are not included in the SWISSEPH package. All of them work with a correction table.
- -They are listed in Santoni's 'Ephemerides de la lune noire vraie' -mentioned above. With all of them, a value is added to the mean apogee -depending on the angular distance of the sun from the mean apogee. There is -something to this idea. The actual apogees that take place once a month differ -from the mean apogee by never more than 5 degrees and seem to move along a -regular curve that is a function of the elongation of the mean apogee.
- -However, this curve does not have exactly the shape of a sine, as is -assumed by all of those correction tables. -And most of them have an amplitude of more than 10 degrees, which is -much too high. The most realistic solution so far was the one proposed by Henry -Gouchon in ”Dictionnaire Astrologique”, Paris 1992, which is based on an -amplitude of 5 degrees.
- -In ”Meridian” 1/95, Dieter Koch has published another table that pays -regard to the fact that the motion does not precisely have the shape of a sine. -(Unfortunately, ”Meridian” confused the labels of the columns of the apogee and -the perigee.)
- -As has been said above, the osculating lunar apogee (so-called -"true Lilith") is a mathematical construct which assumes that the -motion of the moon is a two-body problem. This solution is obviously too -simplistic. Although Kepler ellipses are a good means to describe planetary -orbits, they fail with the orbit of the moon, which is strongly perturbed by -the gravitational pull of the sun. This solar perturbation results in gigantic -monthly oscillations in the ephemeris of the osculating apsides (the amplitude -is 30 degrees). These oscillations have to be considered an artifact of the insufficient model, they -do not really show a motion of the apsides.
- -A more sensible solution seems to be an interpolation between the real -passages of the moon through its apogees and perigees. It turns out that the -motions of the lunar perigee and apogee form curves of different quality and -the two points are usually not in opposition to each other. They are more or -less opposite points only at times when the sun is in conjunction with one of -them or squares them. The amplitude of their oscillation about the mean -position is 5 degrees for the apogee and 25 degrees for the perigee.
- -This solution has been called the "interpolated" -or "realistic" apogee and perigee by Dieter Koch in his publications. -Juan Revilla prefers to call them the "natural" -apogee and perigee. Today, Dieter Koch would prefer the designation -"natural". The designation "interpolated" is a bit misleading, -because it associates something that astrologers used to do everyday in old -days, when they still used to work with printed ephemerides and house tables.
- -Note on implementation (from Swiss Ephemeris Version 1.70 on):
- -Conventional interpolation algorithms do not work well in the case of -the lunar apsides. The supporting points are too far away from each other in -order to provide a good interpolation, the error estimation is greater than 1 -degree for the perigee. Therefore, Dieter chose a different solution. He -derived an "interpolation method" from the analytical lunar theory -which we have in the form of moshier's lunar ephemeris. This -"interpolation method" has not only the advantage that it probably -makes more sense, but also that the curve and its derivation are both -continuous.
- -Literature -(in German):
- -- -Dieter Koch, "Was ist Lilith und welche Ephemeride ist richtig", in: -Meridian 1/95
- -- -Dieter Koch and Bernhard Rindgen, "Lilith und Priapus", -Frankfurt/Main, 2000. (http://www.vdhb.de/Lilith_und_Priapus/lilith_und_priapus.html)
- -- Juan Revilla, "The Astronomical Variants of the Lunar Apogee - -Black Moon", http://www.expreso.co.cr/centaurs/blackmoon/barycentric.html
- -- -
Note to specialists in -planetary nodes and apsides: If important publications or web sites concerning -this topic have been forgotten in this summary, your clue will be appreciated.
- -Methods written in small -characters are not supported by the Swiss Ephemeris software.
- -Differences between the Swiss -Ephemeris and other ephemerides of the osculation nodes and apsides are -probably due to different planetary ephemerides being used for their -calculation. Small differences in the planetary ephemerides lead to much -greater differences in nodes and apsides.
- -- -
Definitions of the nodes
- -The lunar nodes indicate the -intersection axis of the lunar orbital plane with the plane of the ecliptic. At -the lunar nodes, the moon crosses the plane of the ecliptic and its ecliptic -latitude changes sign. There are similar nodes for the planets, but their -definition is more complicated. Planetary nodes can be defined in the following -ways:
- -1) They can be -understood as a direction or as an axis defined by the -intersection line of two orbital planes. E.g., the nodes of Mars are defined by -the intersection line of the orbital plane of Mars with the plane of the -ecliptic (or the orbital plane of the Earth).
- -Note: However, as -Michael Erlewine points out in his elaborate web page on this topic -(http://thenewage.com/resources/articles/interface.html), planetary nodes could -be defined for any couple of planets. E.g. there is also an intersection line -for the two orbital planes of Mars and Saturn. Such non-ecliptic nodes have not -been implemented in the Swiss Ephemeris.
- -Because such lines -are, in principle, infinite, the heliocentric and the geocentric positions of -the planetary nodes will be the same. There are astrologers that use such -heliocentric planetary nodes in geocentric charts.
- -The ascending and -the descending node will, in this case, be in precise opposition.
- -2) There is a second -definition that leads to different geocentric ephemerides. The planetary nodes -can be understood, not as an infinite axis, but as the two points at -which a planetary orbit intersects with the ecliptic plane.
- -For the lunar nodes -and heliocentric planetary nodes, this definition makes no difference from the -definition 1). However, it does make a difference for geocentric -planetary nodes, where, the nodal points on the planets orbit are transformed -to the geocenter. The two points will not be in opposition anymore, or they -will roughly be so with the outer planets. The advantage of these nodes is that -when a planet is in conjunction with its node, then its ecliptic latitude will -be zero. This is not true when a planet is in geocentric conjunction with its -heliocentric node. (And neither is it always true for inner the planets, for -Mercury and Venus.)
- -Note: There is -another possibility, not implemented in the Swiss ephemeris: E.g., instead of -considering the points of the Mars orbit that are located on the ecliptic -plane, one might consider the points of the earth’s orbit that are -located on the orbital plane of Mars. If one takes these points geocentrically, -the ascending and the descending node, will always form an approximate square. -This possibility has not been implemented in the Swiss Ephemeris.
- -3) Third, the planetary -nodes could be defined as the intersection points of the plane defined by their -momentary geocentric position and motion with the plane of the ecliptic. Here -again, the ecliptic latitude would change sign at the moment when the planet -were in conjunction with one of its nodes. This possibility has not been -implemented in the Swiss Ephemeris.
- -- -
Possible definitions for apsides and focal points
- -The lunar apsides - the lunar -apogee and lunar perigee - have already been discussed further above. Similar -points exist for the planets, as well, and they have been considered by -astrologers. Also, as with the lunar apsides, there is a similar disagreement:
- -One may consider either the -planetary apsides, i.e. the two points on a planetary orbit that are closest to the sun and most distant -from the sun, resp. The former point is called the ”perihelion” and the -latter one the ”aphelion”. For a geocentric chart, these points could be -transformed from the heliocenter to the geocenter.
- -However, Bernard Fitzwalter -and Raymond Henry prefer to use the second focal points of the planetary -orbits. And they call them the ”black stars” or the ”black suns of the -planets”. The heliocentric positions of these points are identical to the -heliocentric positions of the aphelia, but geocentric positions are not -identical, because the focal points are much closer to the sun than the -aphelia. Most of them are even inside the Earth orbit.
- -The Swiss Ephemeris supports -both points of view.
- -- -
Special case: the Earth
- -The Earth is a special case. -Instead of the motion of the Earth herself, the heliocentric motion of the -Earth-Moon-Barycenter (EMB) is used to determine the osculating perihelion.
- -There is no node of the earth -orbit itself.
- -There is an axis around which -the earth's orbital plane slowly rotates due to planetary precession. The -position points of this axis are not calculated by the Swiss Ephemeris.
- -- -
Special case: the Sun
- -In addition to the Earth (EMB) -apsides, our software computes so-to-say "apsides" of the solar orbit -around the Earth, i.e. points on the orbit of the Sun where it is closest to -and where it is farthest from the Earth. These points form an opposition and are -used by some astrologers, e.g. by the Dutch astrologer George Bode or the Swiss -astrologer Liduina Schmed. The ”perigee”, located at about 13 Capricorn, is -called the "Black Sun", the other one, in Cancer, is called the -”Diamond”.
- -So, for a complete set of -apsides, one might want to calculate them for the Sun and the Earth and -all other planets.
- -- -
Mean and osculating positions
- -There are serious problems about the ephemerides of planetary nodes and -apsides. There are mean ones and osculating ones. Both are well-defined points -in astronomy, but this does not necessarily mean that these definitions make -sense for astrology. Mean points, on the one hand, are not true, i.e. if a -planet is in precise conjunction with its mean node, this does not mean it be -crossing the ecliptic plane exactly that moment. Osculating points, on the -other hand, are based on the idealization of the planetary motions as two-body -problems, where the gravity of the sun and a single planet is considered and -all other influences neglected. There are no planetary nodes or apsides, at -least today, that really deserve the label ”true”.
- -- -
Mean positions
- -Mean nodes and apsides -can be computed for the Moon, the Earth and the planets Mercury – Neptune. They -are taken from the planetary theory VSOP87. Mean points can not be -calculated for Pluto and the asteroids, because there is no planetary theory -for them.
- -Although the Nasa has -published mean elements for the planets Mercury – Pluto based on the JPL -ephemeris DE200, we do not use them (so far), because their validity is limited -to a 250 year period, because only linear rates are given, and because they are -not based on a planetary theory. (http://ssd.jpl.nasa.gov/elem_planets.html, -”mean orbit solutions from a 250 yr. least squares fit of the DE 200 planetary -ephemeris to a Keplerian orbit where each element is allowed to vary linearly -with time”)
- -The differences between the -DE200 and the VSOP87 mean elements are considerable, though:
- -Node Perihelion
- -Mercury 3” 4”
- -Venus 3” 107”
- -Earth - 35”
- -Mars 74” 4”
- -Jupiter 330” 1850”
- -Saturn 178” 1530”
- -Uranus 806” 6540”
- -Neptune 225” 11600” -(>3 deg!)
- -- -
- -
Osculating nodes and apsides
- -Nodes and apsides can also be -derived from the osculating orbital elements of a body, the parameters that -define an ideal unperturbed elliptic (two-body) orbit for a given time. -Celestial bodies would follow such orbits if perturbations were to cease -instantaneously or if there were only two bodies (the sun and the planet) -involved in the motion from now on and the motion were an ideal ellipse. -This ideal assumption makes it obvious that it would be misleading to call such -nodes or apsides "true". It is more appropriate to call them -"osculating". Osculating nodes and apsides are "true" only -at the precise moments, when the body passes through them, but for the times in -between, they are a mere mathematical construct, nothing to do with the nature -of an orbit.
- -I have tried to solve the -problem by interpolating between actual passages of the planets through -their nodes and apsides. However, this method works only well with Mercury. -With all other planets, the supporting points are too far apart as to make an -accurate interpolation possible.
- -There is another problem about -heliocentric ellipses. E.g. Neptune's orbit has often two perihelia and two -aphelia within one revolution. As a result, there is a wild oscillation of the -osculating or "true" perihelion (and aphelion), which is not due to a -transformation of the orbital ellipse but rather due to the deviation of the -orbit from an elliptic shape. Neptune’s orbit cannot be adequately represented -by a heliocentric ellipse. It makes no sense to use such points in astrology.
- -In actuality, Neptune’s orbit -is not heliocentric at all. The double perihelia and aphelia are an effect of -the motion of the sun about the solar system barycenter. This motion is much -faster than the motion of Neptune, and Neptune cannot react on such fast -displacements of the Sun. As a result, Neptune seems to move around the -barycenter (or a mean sun) rather than around the real sun. In fact, Neptune's -orbit around the barycenter is therefore closer to an ellipse than his orbit -around the sun. The same statement is also true, though less obvious, for -Saturn, Uranus and Pluto, but not for Jupiter and the inner planets.
- -This fundamental problem about -osculating ellipses of planetary orbits does of course not only affect the -apsides but also the nodes.
- -As a solution, it seems -reasonable to compute the osculating elements of slow planets from their -barycentric motions rather than from their heliocentric motions. This procedure -makes sense especially for Neptune, but also for all planets beyond Jupiter. It -comes closer to the mean apsides and nodes for planets that have such points -defined. For Pluto and all transsaturnian asteroids, this solution may be used -as a substitute for "mean" nodes and apsides. Note, however, that -there are considerable differences between barycentric osculating and mean -nodes and apsides for Saturn, Uranus, and Neptune. (A few degrees! But heliocentric -ones are worse.)
- -Anyway, neither the -heliocentric nor the barycentric ellipse is a perfect representation of the -nature of a planetary orbit. So, astrologers, do not expect anything very -reliable here either!
- -The best choice of method will -probably be:
- -For Mercury – Neptune: mean -nodes and apsides.
- -For asteroids that belong to -the inner asteroid belt: osculating nodes/apsides from a heliocentric ellipse.
- -For Pluto and transjovian -asteroids: osculating nodes/apsides from a barycentric ellipse.
- -- -
The modes of the Swiss Ephemeris function -swe_nod_aps()
- -The function swe_nod_aps() can be run in the following modes:
- -1) Mean positions are given -for nodes and apsides of Sun, Moon, Earth, and the planets up to Neptune. -Osculating positions are given with Pluto and all asteroids. This is the -default mode.
- -2) Osculating positions are -returned for nodes and apsides of all planets.
- -3) Same as 2), but for planets -and asteroids beyond Jupiter, a barycentric ellipse is used.
- -4) Same as 1), but for Pluto -and asteroids beyond Jupiter, a barycentric ellipse is used.
- -For the reasons given above, -Dieter Koch would prefer method 4) as making most sense.
- -In all of these modes, the second focal point of the ellipse can be -computed instead of the aphelion.
- -- -
- -
The standard distribution of SWISSEPH includes the main asteroids -Ceres, Pallas, Juno, Vesta, as well as Chiron, and Pholus. To compute them, you -must have the main-asteroid ephemeris -files in your ephemeris directory.
- -The names of these files are of the following form:
- -seas_18.se1 main asteroids -for 600 years from 1800 - 2400
- -The size of such a file is about 200 kb.
- -All other asteroids are available in separate files. The names of -additional asteroid files look like:
- -se00433.se1 the file of asteroid No. 433 (= -Eros)
- -These files cover the period 3000 BC - 3000 AD.
-A short version for the years 1500 – 2100 AD has the file name with an 's'
-imbedded, se00433s.se1.
The numerical integration of the all officiall numbered asteroids is an -ongoing effort. In December 1998, 8000 asteroids were numbered, and their -orbits computed by the devlopers of Swiss Ephemeris. In January 2001, the list -of numbered asteroids has reached 20957, and is growing very fast.
- -Any asteroid can be called either with the JPL, the Swiss, or the -Moshier ephemeris flag, and the results will be slightly different. The reason -is that the solar position (which is needed for geocentric positions) will be -taken from the ephemeris that has been specified.
- -Availability of asteroid files:
- -- all short files
-(over 200000) are available for free download at our ftp server ftp.astro.ch/pub/swisseph.
-The purpose of providing this large number of files for download is that the
-user can pick those few asteroids he/she is interested in.
- for all named -asteroids also a long (6000 years) file -is available in the download area.
- -To generate our asteroid ephemerides, we have modified the numerical -integrator of Steve Moshier, which was capable to rebuild the DE200 JPL -ephemeris.
- -Orbital elements, with a few exceptions, were taken from the asteroid -database computed by E. Bowell, Lowell Observatory, Flagstaff, Arizona -(astorb.dat). After the introduction of the JPL database mpcorb.dat, we still -keep working with the Lowell data because Lowell elements are given with one -more digit, which can be relevant for long-term integrations.
- -For a few close-Sun-approaching asteroids like 1566 Icarus, we use the -elements of JPL’s DASTCOM database. Here, the Bowell elements are not good for -long term integration because they do not account for relativity.
- -Our asteroid ephemerides take into account the gravitational -perturbations of all planets, including the major asteroids Ceres, Pallas, and -Vesta and also the Moon.
- -The mutual perturbations of Ceres, Pallas, and Vesta were included by -iterative integration. The first run was done without mutual perturbations, the -second one with the perturbing forces from the positions computed in the first -run.
- -The precision of our integrator is very high. A test integration of the -orbit of Mars with start date 2000 has shown a difference of only 0.0007 arc -second from DE200 for the year 1600. We also compared our asteroid ephemerides -with data from JPL’s on-line ephemeris system ”Horizons” which provides -asteroid positions from 1600 on. Taking into account that Horizons does not -consider the mutual perturbations of the major asteroids Ceres, Pallas and -Vesta, the difference is never greater than a few 0.1 arcsec.
- -(However, the Swisseph asteroid ephemerides do consider those -perturbations, which makes a difference of 10 arcsec for Ceres and 80 arcsec -for Pallas. This means that our asteroid ephemerides are even better than the -ones that JPL offers on the web.)
- -The accuracy limits are therefore not set by the algorithms of our -program but by the inherent uncertainties in the orbital elements of the -asteroids from which our integrator has to start.
- -Sources of errors are:
- -- Only some of the -minor planets are known to better than an arc second for recent decades. (See -also informations below on Ceres, Chiron, and Pholus.)
- -- Bowells elements do -not consider relativistic effects, which leads to significant errors with -long-term integrations of a few close-Sun-approaching orbits (except 1566, -2212, 3200, 5786, and 16960, for which we use JPL elements that do take into -account relativity).
- -The orbits of some asteroids are extremely sensitive to perturbations by -major planets. E.g. 1862 Apollo becomes chaotic before the year 1870 AD when he -passes Venus within a distance which is only one and a half the distance from -the Moon to the Earth. In this moment, the small uncertainty of the initial -elements provided by the Bowell database grows, so to speak, ”into infinity”, -so that it is impossible to determine the precise orbit prior to that date. Our -integrator is able to detect such happenings and end the ephemeris generation -to prevent our users working with meaningless data.
- -The orbital elements of the four main asteroids Ceres, Pallas, Juno, and -Vesta are known very precisely, because these planets have been discovered -almost 200 years ago and observed very often since. On the other hand, their -orbits are not as well-determined as the ones of the main planets. We estimate -that the precision of the main asteroid ephemerides is better than 1 arc second -for the whole 20th century. The deviations from the Astronomical Almanac -positions can reach 0.5” (AA 1985 – 1997). But the tables in AA are based on -older computations, whereas we used recent orbital elements. (s. AA 1997, page L14)
- -MPC elements have a precision of five digits with mean anomaly, -perihelion, node, and inclination and seven digits with eccentricity and -semi-axis. For the four main asteroids, this implies an uncertainty of a few -arc seconds in 1600 AD and a few arc minutes in 3000 BC.
- -Positions of Chiron can be well computed for the time between 700 -AD and 4650 AD. As a result of close -encounters with Saturn in Sept. 720 AD and in 4606 AD we cannot trace its orbit -beyond this time range. Small uncertainties in today's orbital elements have chaotic -effects before the year 700.
- -Do not rely on earlier Chiron ephemerides supplying a Chiron for Cesar's, -Jesus', or Buddha's birth chart. They are completely meaningless.
- -Pholus is a minor planet with orbital characteristics that are similar -to Chiron's. It was discovered in 1992. Pholus' orbital elements are not yet as -well-established as Chiron's. Our ephemeris is reliable from 1500 AD through -now. Outside the 20th century it will probably have to be corrected by several -arc minutes during the coming years.
- -Dieter Koch has written the application program Ceres which -allows to compute all kinds of lists for asteroid astrology. E.g. you can -generate a list of all your natal asteroids ordered by position in the zodiac. -But the program does much more:
- -- natal positions, synastries/transits, composite charts, progressions, -primary directions etc.
- -- geocentric, heliocentric, topocentric, house horoscopes
- -- lists sorted by position in zodiac, by asteroid name, by declination -etc.
- -The program is on the asteroid short files CD-ROM and the standard Swiss -Ephemeris CD-ROM.
- -- -
The Swiss Ephemeris does not provide ephemerides of comets yet.
- -A database of fixed stars is included with Swiss Ephemeris. It contains -about 800 stars, which can be computed with the swe_fixstar() function. The -precision is about 0.001”.
- -Our data are based on the star catalogue of Steve Moshier. It can be -easily extended if more stars are required.
- -The database was improved by Valentin Abramov, Tartu, Estonia. He -reordered the stars by constellation, added some stars, many names and -alternative spellings of names.
- -In Feb. -2006 (Version 1.70) the fixed stars file was updated with data from the SIMBAD -database (http://simbad.u-strasbg.fr/Simbad).
- -- -
In Jan. -2011 (Version 1.77) a new fixed stars file sefstars.txt was created from the -SIMBAD database.
- -We include some astrological factors in the ephemeris which have no -astronomical basis – they have never been observed physically. As the purpose -of the Swiss Ephemeris is astrology, we decided to drop our scientific view in -this area and to be of service to those astrologers who use these -‘hypothetical’ planets and factors. Of course neither of our scientific -sources, JPL or Steve Moshier, have anything to do with this part of the Swiss -Ephemeris.
- -There have been discussions whether these factors are to be called -'planets' or 'Transneptunian points'. However, their inventors, the German -astrologers Witte and Sieggrün, considered them to be planets. And moreover -they behave like planets in as far as they circle around the sun and obey its -gravity.
- -On the other hand, if one looks at their orbital elements, it is obvious -that these orbits are highly unrealistic. -Some of them are perfect circles – something that does not exist in -physical reality. The inclination of the orbits is zero, which is very -improbable as well. The revised elements published by James Neely in Matrix Journal -VII (1980) show small eccentricities for the four Witte planets, but they are -still smaller than the eccentricity of Venus which has an almost circular -orbit. This is again very improbable.
- -There are even more problems. An ephemeris computed with such elements -describes an unperturbed motion, i.e. it takes into account only the Sun's -gravity, not the gravitational influences of the other planets. This may result -in an error of a degree within the 20th century, and -greater errors for earlier centuries.
- -Also, note that none of the real transneptunian objects that have been -discovered since 1992 can be identified with any of the Uranian planets.
- -SWISSEPH uses James Neely's revised orbital elements, because they agree -better with the original position tables of Witte and Sieggrün.
- -The hypothetical planets can again be called with any of the three -ephemeris flags. The solar position needed for geocentric positions will then -be taken from the ephemeris specified.
- -This hypothetical planet was postulated 1946 by the French astronomer -M.E. Sevin because of otherwise unexplainable gravitational perturbations in -the orbits of Uranus and Neptune.
- -However, this theory has been superseded by other attempts during the -following decades, which proceeded from better observational data. They resulted in bodies and orbits -completely different from what astrologers know as 'Isis-Transpluto'. More -recent studies have shown that the perturbation residuals in the orbits of -Uranus and Neptune are too small to allow postulation of a new planet. They -can, to a great extent, be explained by observational errors or by systematic -errors in sky maps.
- -In telescope observations, no hint could be discovered that this planet -actually existed. Rumors that claim the opposite are wrong. Moreover, all of the transneptunian bodies -that have been discovered since 1992 are very different from Isis-Transpluto.
- -Even if Sevin's computation were correct, it could only provide a rough -position. To rely on arc minutes would be illusory. Neptune was more than a degree away from its theoretical position -predicted by Leverrier and Adams.
- -Moreover, Transpluto's position is computed from a simple Kepler -ellipse, disregarding the perturbations by other planets' gravities. Moreover, Sevin gives no orbital -inclination.
- -Though Sevin gives no inclination for his Transpluto, you will realize -that there is a small ecliptic latitude in positions computed by SWISSEPH. This -mainly results from the fact that its orbital elements are referred to epoch -5.10.1772 whereas the ecliptic changes position with time.
- -The elements used by SWISSEPH are taken from ”Die Sterne” 3/1952, p. 70. -The article does not say which equinox they are referred to. Therefore, we fitted it to the Astron -ephemeris which apparently uses the equinox of 1945 (which, however, is rather -unusual!).
- -This is another attempt to predict Planet X's orbit and position from -perturbations in the orbits of Uranus -and Neptune. It was published in The Astronomical Journal 96(4), October 1988, -p. 1476ff. Its precision is meant to be of the order of +/- 30 degrees. -According to Harrington there is also the possibility that it is actually -located in the opposite constellation, i.e. Taurus instead of Scorpio. The -planet has a mean solar distance of about 100 AU and a period of about 1000 -years.
- -A highly speculative planet derived from the theory of Zecharia Sitchin, -who is an expert in ancient Mesopotamian history and a ”paleoastronomer”. The elements have been supplied by Christian -Woeltge, Hannover. This planet is -interesting because of its bizarre orbit. It moves in clockwise direction and -has a period of 3600 years. Its orbit is extremely eccentric. It has its -perihelion within the asteroid belt, whereas its aphelion lies at about 12 -times the mean distance of Pluto. In -spite of its retrograde motion, it seems to move counterclockwise in -recent centuries. The reason is that it is so slow that it does not even -compensate the precession of the equinoxes.
- -This is a ‘hypothetical’ planet inside the orbit of Mercury (not -identical to the “Uranian” planet Vulkanus). Orbital elements according to L.H. -Weston. Note that the speed of this “planet” does not agree with the Kepler -laws. It is too fast by 10 degrees per year.
- -This is a ‘hypothetical’ second moon of the earth (or a third one, after -the “Black Moon”) of obscure provenance. Many Russian astrologers use it. Its -distance from the earth is more than 20 times the distance of the moon and it -moves about the earth in 7 years. Its orbit is a perfect, unperturbed circle. -Of course, the physical existence of such a body is not possible. The gravities -of Sun, Earth, and Moon would strongly influence its orbit.
- -This is another hypothetical second moon of the earth, postulated by a -Dr. Waldemath in the Monthly Wheather Review 1/1898. Its distance from -the earth is 2.67 times the distance of the moon, its daily motion about 3 -degrees. The orbital elements have been derived from Waldemath’s original data. -There are significant differences from elements used in earlier versions of -Solar Fire, due to different interpretations of the values given by Waldemath. -After a discussion between Graham Dawson and Dieter Koch it has been agreed -that the new solution is more likely to be correct. The new ephemeris does not -agree with Delphine Jay’s ephemeris either, which is obviously inconsistent -with Waldemath’s data.
- -This body has never been confirmed. With its 700-km diameter and an -apparent diameter of 2.5 arc min, this should have been possible very soon -after Waldemath’s publication.
- -- -
These are the hypothetical planets that have lead to the discovery of -Neptune and Pluto or at least have been brought into connection with them. Their enormous deviations from true Neptune -and Pluto may be interesting for astrologers who work with hypothetical bodies. -E.g. Leverrier and Adams are good only around the 1840ies, the discovery epoch -of Neptune. To check this, call the program swetest as follows:
- -$ swetest -p8 -dU -b1.1.1770 -n8 -s7305 -hel --fPTLBR -head
- -(i.e.: compute planet 8 (Neptune) - planet 'U' (Leverrier), from -1.1.1770, 8 times, in 7305-day-steps, heliocentrically. You can do this from -the Internet web page swetest.htm. The -output will be:)
- -Nep-Lev -01.01.1770 -18° 0'52.3811 0°55' 0.0332 -6.610753489
- -Nep-Lev -01.01.1790 -8°42' 9.1113 1°42'55.7192 -4.257690148
- -Nep-Lev -02.01.1810 -3°49'45.2014 1°35'12.0858 -2.488363869
- -Nep-Lev -02.01.1830 -1°38' 2.8076 0°35'57.0580 -2.112570665
- -Nep-Lev -02.01.1850 1°44'23.0943 -0°43'38.5357 -3.340858070
- -Nep-Lev -02.01.1870 9°17'34.4981 -1°39'24.1004 -5.513270186
- -Nep-Lev -02.01.1890 21°20'56.6250 -1°38'43.1479 -7.720578177
- -Nep-Lev -03.01.1910 36°27'56.1314 -0°41'59.4866 -9.265417529
- -- -
(difference in (difference in -(difference in
- -longitude) latitude) -solar distance)
- -- -
One can see that the error is in the range of 2 degrees between 1830 and -1850 and grows very fast beyond that period.
- -- -
- -
Sidereal -astrology has a complicated history, and we (the developers of Swiss Ephemeris) -are actually tropicalists. Any suggestions how we could improve our sidereal -calculations are welcome!
- -- -
For deeper -studies of the problem, read:
- -Raymond -Mercier, ”Studies in the Medieval Conception of Precession”,
- -in 'Archives -Internationales d'Histoire des Sciences', (1976) 26:197-220 (part I), and -(1977) 27:33-71 (part II)
- -- -
Thanks to -Juan Ant. Revilla, San Jose, Costa Rica, who gave us this precious -bibliographic hint.
- -- -
- -
One of the -main differences between the western and the eastern tradition of astrology is -the definition of the zodiac. Western astrology uses the so-called tropical -zodiac in which 0 Aries is defined as the vernal point (the celestial point -where the sun stands at the beginning of spring). The tropical zodiac is a division of the ecliptic into 12 zodiac -signs that are all of equal size, i. e. 30°. Astrologers call these signs -after some constellations that are found along the ecliptic, but they are -actually independent of these constellations. Because the vernal point slowly -moves through the constellations and completes its cycle once in 26000 years, -tropical Aries moves through all constellations along the ecliptic, staying in -each one for roughly 2160 years. Currently, the vernal point, and the beginning -of tropical Aries, is located in sidereal Pisces. In a few hundred years, it will -enter Aquarius, which is the reason why the more impatient ones among us are -already preparing for the “Age of Aquarius”.
- -- -
The -so-called sidereal zodiac also consists of 12 equal-sized zodiac signs, -but it is tied to the fixed stars. These sidereal signs, which are used in -Hindu astrology but also by some western Neo-Babylonian and Neo-Hellenistic -astrologers, only roughly coincide with the sidereal constellations, which are -of variable size.
- -- -
While the -definition of the tropical zodiac is clear and never questioned, sidereal -astrology has quite some problems in defining its zodiac. There are many -different definitions of the sidereal zodiac, and they differ by several -degrees. At a first glance, all of them look arbitrary, and there is no -striking evidence – from a mere astronomical point of view – for anyone of -them. However, a historical study shows at least that all of them stem from -only one sidereal zodiac. On the other hand, this does not mean that it be -simple to give a precise definition of it.
- -- -
Sidereal -planetary positions are usually computed from an equation similar to:
- -sidereal_position -= tropical_position – ayanamsha,
- -where ayanamsha -is the difference between the two zodiacs and changes with time. (Sanskrit ayanâmsha -means ”part of a path”; the Hindi form of the word is ayanamsa with an s -instead of sh.) ”
- -The value -of the ayanamsha of date is computed from the ayanamsha value at -a start date (e.g. 1 Jan 1900) and the speed of the vernal point, the so-called -precession rate in ecliptic longitude.
- -- -
The zero -point of the sidereal zodiac is therefore traditionally defined by the equation
- -sidereal Aries = tropical Aries – -ayanamsha
- -and by a -date for which this equation is true.
- -- -
The Swiss -Ephemeris allows for about twenty different ayanamshas, but the user can -also define his or her own ayanamsha.
- -- -
- -
- -
There have -been several attempts to calculate the zero point of the Babylonian ecliptic -from cuneiform lunar and planetary tablets. Positions were given from some -sidereally fixed reference point. The main problem in fixing the zero point is -the inaccuracy of ancient observations. Around 1900 F.X. Kugler found -that the Babylonian star positions fell into three groups:
- -- -
9) ayanamsha = -3°22´, t0 = -100
- -10) ayanamsha -= -4°46´, t0 = -100 Spica at 29 vi 26
- -11) ayanamsha -= -5°37´, t0 = -100
- -- -
(9 – 11 = -Swiss Ephemeris ayanamsha numbers)
- -- -
In 1958, Peter -Huber reviewed the topic in the light of new material and found:
- -- -
12) ayanamsha -= -4°34´ +/- 20´, t0 = –100 -Spica at 29 vi 14
- -The -standard deviation was 1°08’
- -- -
In 1977 Raymond -Mercier noted that the zero point might have been defined as the ecliptic -point that culminated simultaneously with the star eta Piscium (Al -Pherg). For this possibility, we compute:
- -- -
13) ayanamsha -= -5°04’46”, t0 = –129 Spica at 29 vi 21
- -- -
Around -1950, Cyril Fagan, the founder of the modern western sidereal astrology, -reintroduced the old Babylonian zodiac into astrology, placing the fixed star -Spica near 29°00 Virgo. As a result of ”rigorous statistical investigation” -(astrological!) of solar and lunar ingress charts, Donald Bradley decided -that the sidereal longitude of the vernal point must be computed from Spica at -29 vi 06'05" disregarding its proper motion. Fagan and Bradley -defined their ”synetic vernal point” as:
- -- -
0) ayanamsha -= 24°02’31.36” for 1 Jan. 1950 with Spica at 29 vi 06'05" (without -aberration)
- -(For the -year –100, this ayanamsha places Spica at 29 vi 07’32”.)
- -- -
Fagan and -Bradley said that the difference between P. Huber’s zodiac and theirs was only -1’. But actually (if Mercier’s value for the Huber ayanamsha is correct) -it was 7’.
- -- -
According -to a text by Fagan (found on the internet), Bradley ”once opined in print prior -to "New Tool" that it made more sense to consider Aldebaran and -Antares, at 15 degrees of their respective signs, as prime fiducials than it -did to use Spica at 29 Virgo”. Such statements raise the question if the -sidereal zodiac ought to be tied up to one of those stars. Today, we know that -the fixed stars have a proper motion, wherefore such definitions are not a good -idea, if an absolute coordinate system independent on moving bodies is -intended. But the Babylonians considered them to be fixed.
- -- -
For this -possibility, Swiss Ephemeris gives an Aldebaran ayanamsha:
- -- -
14) ayanamsha -with Aldebaran at 15ta00’00” and Antares at 15sc00’17” around the year –100.
- -- -
The -difference between this ayanamsha and the Fagan/Bradley one is 1’06”.
- -- -
- -
- -
Raymond -Mercier has shown -that all of the ancient Greek and the medieval Arabic astronomical works -located the zero point of the ecliptic somewhere between 10 and 22 arc -minutes east of the star zeta Piscium. This definition goes back to the -great Greek astronomer Hipparchus. How did he choose that point? -Hipparchus said that the beginning of Aries rises when Spica sets. This -statement was meant for a geographical latitude of 36°, the latitude of the -island of Rhodos, which Hipparchus’ descriptions of rises and settings are -referred to.
- -- -
However, -there seems to be more behind it. Mercier points out that according to -Hipparchus’ star catalogue the stars alpha Arietis, beta Arietis, zeta -Piscium, and Spica are located in precise alignment on a great -circle which goes through that zero point near zeta Piscium. Moreover, -this great circle was identical with the horizon once a day at Hipparchus’ -geographical latitude of 36°. In other words, the zero point rose at the same -time when the three mentioned stars in Aries and Pisces rose and at the same -time when Spica set.
- -- -
This would -of course be a nice definition for the zero point, but unfortunately the stars -were not really in such precise alignment. They were only assumed to be -so.
- -- -
Mercier -gives the following ayanamshas for Hipparchus and Ptolemy -(who used the same star catalogue as Hipparchus):
- -- -
16) ayanamsha -= -9°20’ 27 June –128 (jd -1674484) zePsc 29pi33’49” Hipparchos
- -- -
(According -to Mercier’s calculations, the Hipparchan zero point should have been between -12 and 22 arc min east of zePsc, but the Hipparchan ayanamsha, as given -by Mercier, has actually the zero point 26’ east of zePsc. This comes from the -fact that Mercier refers to the Hipparchan position of zeta Piscium, which -was at least rounded to 10’ – if otherwise correct.)
- -- -
If we used -the explicit statement of Hipparchus that Aries rose when Spica set at a -geographical latitude of 36 degrees, the precise ayanamsha would be --8°58’13” for 27 June –128 (jd 1674484) and zePsc would be found at 29pi12’, -which is too far from the place where it ought to be.
- -- -
Mercier -also discusses the old Indian precession models and zodiac point definitions. -He notes that, in the Sûrya Siddânta, the star zeta Piscium (in -Sanskrit Revatî) has almost the same position as in the Greek sidereal -zodiac, i.e. 29°50’ in Pisces. On the other hand, however, Spica (in Sanskrit Citra) -is given the longitude 30° Virgo. This is a contradiction, either Spica or -Revatî must be considered wrong.
- -- -
Moreover, -if the precession model of the Sûrya Siddânta is used to compute an ayanamsha -for the date of Hipparchus, it will turn out to be –9°14’01”, which is very -close to the Hipparchan value. The same calculation can be done with the Ârya -Siddânta, and the ayanamsha for Hipparchos’ date will be –9°14’55”. -For the Siddânta Shiromani the zero point turns out to be Revatî itself. -By the way, this is also the zero point chosen by Copernicus! So, there -is an astonishing agreement between Indian and Western traditions!
- -- -
The same -zero point near the star Revatî is also used by the so-called Ushâshashî -ayanamsha which is still in use. It differs from the Hipparchan one by only -11 arc minutes.
- -- -
4) ayanamsha -= 18°39’39.46 1 Jan. 1900 Ushâshashî
- -zePsc (Revatî) 29pi50’ (today), -29pi45’ (Hipparchus’ epoch)
- -- -
The -Greek-Arabic-Hindu ayanamsha was zero around 560 AD. The tropical and -the sidereal zero points were at exactly the same place. Did astronomers or -astrologers react on that event? They did! Under the Sassanian ruler Khusrau -Anûshirwân, in the year 556, the astronomers of Persia met to correct their -astronomical tables, the so-called Zîj al-Shâh. These tables are no -longer extant, but they were the basis of later Arabic tables, the ones of -al-Khwârizmî and the Toledan tables.
- -- -
One of the -most important cycles in Persian astronomy/astrology was the one of Jupiter, -which started and ended with the conjunctions of Jupiter with the sun. This -cycle happened to end in the year 564, and the conjunction of Jupiter -with the Sun took place only one day after the spring equinox. And the -spring equinox took place precisely 10 arcmin east of zePsc. This may be a -mere coincidence from a present-day astronomical point of view, but for -scientists of those days this was obviously the moment to redefine all -astronomical data.
- -- -
Mercier -also shows that in the precession model used in that epoch and in other models -used later by Arabic Astronomers, precession was considered to be a phenomenon -connected with ”the movement of Jupiter, the calendar marker of the night sky, -in its relation to the Sun, the time keeper of the daily sky”. Such theories -were of course wrong, from the point of view of today’s knowledge, but they -show how important that date was considered to be.
- -- -
After the -Sassanian reform of astronomical tables, we have a new definition of the -Greek-Arabic-Hindu sidereal zodiac (this is not explicitly stated by Mercier, -however):
- -- -
16) ayanamsha -= 0 18 Mar 564, 7:53:23 UT (jd /ET 1927135.8747793) Sassanian
- --zePsc 29pi49'59"
- -- -
The same -zero point then reappears with a precision of 1’ in the Toledan tables, the -Khwârizmian tables, the Sûrya Siddhânta, and the Ushâshashî ayanamsha.
- -- -
(Besides -the synchronicity of the Sun-Jupiter conjunction and the coincidence of the two -zodiacs, it is funny to note that the cosmos helped the inaccuracy of ancient -astronomy by ”rounding” the position of the star zePsc to precisely 10 arc -minutes east of the zero point! All Ptolemean star positions were rounded to 10 -arc minutes.)
- -- -
- -
- -
The explanations above are mainly -derived from the article by Mercier. However, it is possible to derive -ayanamshas from ancient Indian works themselves.
- -- -
The planetary theory of the main -work of ancient Indian astronomy, the Suryasiddhanta, uses the so-called -Kaliyuga era as its zero point, i. e. the 18th February 3102 BC, -0:00 local time at Ujjain, which is at geographic longitude of 75.7684565 east -(Mahakala temple). This era is henceforth called “K0s”. This is also the zero -date for the planetary theory of the ancient Indian astronomer Aryabhata, with -the only difference that he reckons from sunrise of the same date instead of -midnight. We call this Aryabhatan era “K0a”.
- -- -
Now, Aryabhata mentioned that he was -23 years old when exactly 3600 years had passed since the beginning of the -Kaliyuga era. If 3600 years with a year length as defined by the Aryabhata are -counted from K0a, we arrive at the 21st March, 499 AD, 6:56:55.57 -UT. At this point of time the mean Sun is assumed to have returned to the -beginning of the sidereal zodiac, and we can derive an ayanamsha from this -information. There are two possible solutions, though:
- -- -
1. We can find the place of the mean -Sun at that time using modern astronomical algorithms and define this point as -the beginning of the sidereal zodiac.
- -2. As Aryabhata believed that the -zodiac began at the vernal point, we can take the vernal point of this date as -the zero point.
- -- -
The same calculations can be done -based on K0s and the year length of the Suryasiddhanta. The resulting date of -Kali 3600 is the same day but about half an hour later: 7:30:31.57 UT.
- -- -
Algorithms for the mean Sun were -taken from: Simon et alii, “Numerical expressions for precession formulae and -mean elements for the Moon and the planets”, in: Astron. Astrophys. 282,663-683 -(1994).
- -- -
- -
- -
There is -another ayanamsha tradition that assumes the star Spica (in Sanskrit Citra) at -0° Libra. This ayanamsha definition is the most common one in modern Hindu astrology. -It was first proposed by the astronomy historian S. B. Dixit (also written -Dikshit), who in 1896 published his important work History of Indian -Astronomy (= Bharatiya Jyotih -Shastra; bibliographical details further below). Dixit came to the -conclusion that, given the prominence that Vedic religion gave to the cardinal -points of the tropical year, the Indian calendar, which is based on the zodiac, -should be reformed and no longer be calculated relative to the sidereal, but to -the tropical zodiac. However, if such a reform could not be brought about due -to the rigid conservatism of contemporary Vedic culture, then the ayanamsha -should be chosen in such a way that the sidereal zero point would be in -opposition to Spica. In this way, it would be in accordance with Grahalaghava, a work by the 16th century -astronomer Ganeśa Daivajña that -was still used in the 20th century by Indian calendar makers. (op. -cit., Part II, p. 323ff.). This view was taken over by the Indian Calendar Reform Committee on the occasion of the Indian -calendar reform in 1956, when the ayanamsha based on the -star Spica/Citra was declared the Indian standard. This standard is mandatory -not only for astrology but also for astronomical ephemerides and almanacs and -calendars published in India. The ayanamsha based on the star Spica/Citra -became known as “Lahiri ayanamsha”. It was named after the Calcuttan astronomer -and astrologer Nirmala Chandra Lahiri, who was a member of the Reform -Committee.
- -- -
However, as -has been said, it was Dixit who first propagated this solution to the ayanamsha -problem. Besides, the Suryasiddhanta, the most important work of ancient Hindu -astronomy, which was written in the first centuries AD, but reworked several -times, already assumes Spica/Citra at 180° (although this statement has caused -a lot of controversy because it is in contradiction with the positions of other -stars, and in particular with zeta Piscium/Revati at 359°50‘). And last but not -least, the same ayanamsha definition seems to have been used in Babylon and -Greece, as well. While the information given above in the chapters about the -Babylonian and the Hipparchan traditions are based on analyses of old star -catalogues and planetary theories, a study by Nick Kollerstrom of 22 ancient -Greek and 5 Babylonian birth charts has lead to a different conclusion: they -fit better with Spica at 0 Libra (= Lahiri), than with Aldebaran at 15 Taurus -and Spica at 29 Virgo (= Fagan/Bradley).
- -- -
The -standard definition of the Indian ayanamsha (“Lahiri” ayanamsha) was originally -introduced in 1955 by the Indian Calendar -Reform Committee (23°15' 00" on the 21 March 1956, 0:00 Ephemeris -Time). The definition was corrected in Indian -Astronomical Ephemeris 1989, page 556, footnote:
- -"According -to new determination of the location of equinox this initial value has been -revised to and used in computing the mean ayanamsha with effect from -1985'."
- -The mention -of “mean ayanamsha” is misleading though. The value 23°15' 00".658 is true -ayanamsha, i. e. it includes nutation and is relative to the true equinox of -date.
- -- -
1) true -ayanamsha = 23°15' 00".658 21 March 1956, 0:00 TDT Lahiri, Spica roughly at 0 Libra
- -- -
The Lahiri -standard position of Spica is 179°59’04 in the year 2000, and 179°59’08 in -1900. In the year 285, when the star was conjunct the autumnal equinox, its -position was 180°00’16. It was in the year 667 AD that its position was -precisely 180°. The motion of the star is a result partly of its proper motion -and partly of planetary precession, which has the ecliptic slightly change its -orientation. But what method exactly was used to define this ayanamsha? -According to the Indian pundit AK Kaul, an expert in Hindu calendar and -astrology, Lahiri wanted to place the star at 180°, but at the same time arrive -at an ayanamsha that was in agreement with the Grahalaghava, an important work -for traditional Hindu calendar calculation that was written in the 16th -century. (e-mail from Mr. Kaul to Dieter Koch on 1 March 2013)
- -- -
In 1967, 12 -years after the standard definition of the Lahiri ayanamsha had been published -by the Calendar Reform Committee, Lahiri published another ayanamsha in his -Bengali book Panchanga Darpan. There, -the value of “mean ayanamsha” is given as 22°26’45”.50 in 1900, whereas the -official value is 22°27’37”.76. The idea behind this modification was obviously -that he wanted to have the star exactly at 180° for recent years, whereas with -the standard definition the star is “wrong” by almost an arc minute. It -therefore seems that Lahiri did not follow the Indian standard himself but was -of the opinion that Spica had to be at exactly 180° (true chitrapaksha -ayanamsha). At the moment, the Swiss only supports the official standard. -However, it is rather trivial to calculate the positions of a planet and the -star and then subtract the star from the planet.
- -- -
Swiss -Ephemeris versions below 1.78.01, had a slightly different definition of the -Lahiri ayanamsha that had been taken from Robert Hand's astrological software -Nova. It made a difference of only 0.01 arc sec.
- -- -
Many thanks -to Vinay Jha, Narasimha Rao, and Avtar Krishen Kaul for helping us to better -understand the complicated matter.
- -- -
If the -reader finds errors in this documentation or is able to contribute important -information, his or her feedback will be greatly appreciated.
- -- -
Sources:
- -Burgess, -E., The Surya Siddanta. A Text-book of Hindu Astronomy, Delhi, 2000 -(MLBD).
- -Dikshit, S(ankara) B(alkrishna), Bharatiya Jyotish Sastra (History of Indian Astronomy) (Tr. -from Marathi), Govt. of India, 1969, part I & II.
- -Kollerstrom, Nick, „The Star Zodiac of Antiquity“, in: Culture -& Cosmos, Vol. -1, No.2, 1997).
- -Lahiri, N. C., Panchanga Darpan (in Bengali), Calcutta, 1967 (Astro Research -Bureau).
- -Lahiri, -N. C., Tables of the Sun, Calcutta, 1952 (Astro Research Bureau).
- -Saha, M. -N., and Lahiri, N. C., Report of the Calendar Reform Committee, C.S.I.R., New Delhi, 1955.
- -The -Indian astronomical ephemeris for the year 1989, -Delhi (Positional Astronomy Centre, India Meteorological Department)
- -- -
- -
As said -before, there is a very precise definition for the tropical ecliptic. It starts -at one of the two intersection points of the ecliptic and the celestial -equator. Similarly, we have a very precise definition for the house circle -which is said to be an analogy of the zodiac. It starts at one of the two -intersection points of the ecliptic and the local horizon. Unfortunately there -is no such definition for the sidereal zodiac. Or can a fixed star like Spica -be important enough to play the role of an anchor star?
- -- -
One could -try to make the sidereal zero point agree with the Galactic Center. The Swiss -astrologer Bruno Huber has pointed out that the Galactic Center enters a new -tropical sign always around the same time when the vernal point enters the next -sidereal sign. Around the time, when the vernal point will go into Aquarius, -the Galactic Center will change from Sagittarius to Capricorn. Huber also notes -that the ruler of the tropical sign of the Galactic Center is always the same -as the ruler of the sidereal sign of the vernal point (at the moment Jupiter, -will be Saturn in a few hundred years).
- -- -
A -correction of the Fagan ayanamsha by about 2 degrees or a correction of -the Lahiri ayanamsha by 3 degrees would place the Galactic Center at 0 -Sagittarius. Astrologically, this would obviously make some sense. Therefore, -we add an ayanamsha fixed at the Galactic Center:
- -- -
17) -Galactic Center at 0 Sagittarius
- -- -
The other -possibility – in analogy with the tropical ecliptic and the house circle – -would be to start the sidereal ecliptic at the intersection point of the -ecliptic and the galactic plane. At present, this point is located near 0 -Capricorn. However, defining this point as sidereal 0 Aries would mean to break -completely with the tradition, because it is far away from the traditional sidereal -zero points.
- -- -
- -
There are a -few more ayanamshas, whose provenance is not known to us. They were -given to us by Graham Dawson (”Solar Fire”), who took them over from Robert -Hand’s Program ”Nova”:
- -- -
2) De Luce
- -3) Raman
- -5) Krishnamurti
- -- -
David Cochrane adds
- -- -
7) Yukteshvar
- -8) JN Bhasin
- -- -
Graham -Dawson adds the following one:
- -- -
6) Djwhal -Khul
- -- -
He comments it as follows: ”The "Djwhal -Khul" ayanamsha originates from information in an article in the Journal -of Esoteric Psychology, Volume 12, No 2, pp91-95, Fall 1998-1999 publ. Seven -Ray Institute). It is based on an inference that the Age of Aquarius starts in -the year 2117. I decided to use the 1st of July simply to minimise the possible -error given that an exact date is not given.”
- -- -
- -
We have -found that there are basically three definitions, not counting the manifold -variations:
- -1. the Babylonian zodiac with Spica at 29 -Virgo or Aldebaran at 15 Taurus:
- -a) P. Huber, b) Fagan/Bradley c) refined with Aldebaran -at 15 Tau
- -2. the Greek-Arabic-Hindu zodiac with the zero -point between 10 and 20’ east of zeta Piscium:
- -a) Hipparchus, b) Ushâshashî, c) Sassanian
- -3. the Greek-Hindu astrological zodiac with -Spica at 0 Libra
- -a) Lahiri
- -- -
The -differences are:
- -between 1) -and 3) is about 1 degree
- -between 1) -and 2) is about 5 degrees
- -between 2) -and 3) is about 4 degrees
- -- -
It is -obvious that all of them stem from the same origin, but it is difficult to say -which one should be preferred for sidereal astrology.
- -- -
1) is -historically the oldest one, but we are not sure about its precise astronomical -definition. Aldebaran at 15 Tau might be one.
- -- -
3) has the -most striking reference point, the bright star Spica at 0 Libra. But this -definition is so clear and simple that, had it really been intended by the -inventors of the sidereal ecliptic, it would certainly not have been forgotten -or given up by the Greek and Arabic tradition.
- -- -
2) is the -only definition independent on a star – especially, if we take the Sassanian -version. This is an advantage, because all stars have a proper motion and -cannot really define a fixed coordinate system. Also, it is the only ayanamsha -for which there is historical evidence that it was observed and recalibrated at -the time when it was 0.
- -- -
On the -other hand, the point 10’ East of zePsc has no astronomical significance at -all, and the great difference between this zero point and the Babylonian one -raises the question: Did Hipparchus’ definition result from a misunderstanding -of the Babylonian definition, or was it an attempt to improve the Babylonian -zodiac?
- -- -
- -
- -
A second -problem in sidereal astrology – after the definition of the zero point – is the -precession algorithm to be applied. We can think of five possibilities:
- -- -
1) the traditional algorithm (implemented in -Swiss Ephemeris as default mode)
- -- -
In all -software known to us, sidereal planetary positions are computed from an -equation mentioned before:
- -sidereal_position -= tropical_position – ayanamsha,
- -The ayanamhsa -is computed from the ayanamsha(t0) at a starting date (e.g. 1 Jan 1900) -and the speed of the vernal point, the so-called precession rate.
- -- -
This -algorithm is unfortunately too simple. At best, it can be considered as an -approximation. The precession of the equinoxes is not only a matter of -ecliptical longitude, but is a more complex phenomenon. It has two components:
- -- -
a) The soli-lunar -precession: The combined gravitational pull of the Sun and the Moon on -the equatorial bulge of the earth causes the earth to spin like a top. As a -result of this movement, the vernal point moves around the ecliptic with a -speed of about 50”. This cycle lasts about 26000 years.
- -- -
b) The planetary -precession: The earth orbit itself is not fixed. The gravitational -influence from the planets causes it to wobble. As a result, the obliquity of -the ecliptic currently decreases by 47” per century, and this movement has an -influence on the position of the vernal point, as well. (This has nothing to do -with the precessional motion of the earth rotation axis; the equator holds an -almost stable angle against the ecliptic of a fixed date, e.g. 1900, with a -change of only a couple of 0.06” cty-2).
- -- -
Because the -ecliptic is not fixed, it cannot be correct just to subtract an ayanamsha -from the tropical position in order to get a sidereal position. Let us take, -e.g., the Fagan/Bradley ayanamsha, which is defined by:
- -ayanamsha = -24°02’31.36” + d(t)
- -24°02’... -is the value of the ayanamsha on 1 Jan 1950. It is obviously measured on -the ecliptic of 1950.
- -d(t) is the distance of the vernal point -at epoch t from the position of the vernal point on 1 Jan 1950. This -value is also measured on the ecliptic of 1950. But the whole ayanamsha -is subtracted from a planetary position which is referred to the ecliptic of -the epoch t. This does not make sense.
- -- -
As an -effect of this procedure, objects that do not move sidereally, e.g. the -Galactic Center, seem to move. If we compute its precise tropical position for -several dates and then subtract the Fagan/Bradley ayanamsha for the same -dates in order to get its sidereal position, these positions will all be -slightly different:
- -- -
Date Longitude -Latitude
- -01.01.-5000 2 sag 07'57.7237 -4°41'34.7123 (without aberration)
- -01.01.-4000 2 sag 07'32.9817 -4°49' 4.8880
- -01.01.-3000 2 sag 07'14.2044 -4°56'47.7013
- -01.01.-2000 2 sag 07' 0.4590 -5° 4'39.5863
- -01.01.-1000 2 sag 06'50.7229 -5°12'36.9917
- -01.01.0 2 sag 06'44.2492 -5°20'36.4081
- -01.01.1000 2 sag 06'40.7813 -5°28'34.3906
- -01.01.2000 2 sag 06'40.5661 -5°36'27.5619
- -01.01.3000 2 sag 06'44.1743 -5°44'12.6886
- -01.01.4000 2 sag 06'52.1927 -5°51'46.6231
- -01.01.5000 2 sag 07' 4.8942 -5°59' 6.3665
- -- -
The effect -can be much greater for bodies with greater ecliptical latitude.
- -Exactly the -same kind of thing happens to sidereal planetary positions, if one calculates -them in the traditional way. It is only because planets move that we are not -aware of it.
- -- -
The traditional method of computing sidereal positions is -geometrically not sound and can never achieve the same degree of accuracy as -tropical astrology is used to.
- -- -
2) fixed-star-bound ecliptic (not -implemented in Swiss Ephemeris)
- -- -
One could -use a stellar object as an anchor for the sidereal zodiac, and make sure that a -particular stellar object is always at a certain position on the ecliptic of -date. E.g. one might want to have Spica always at 0 Libra or the Galactic -Center always at 0 Sagittarius. There is nothing against this method from a -geometrical point of view. But it has to be noted, that this system is not -really fixed either, because it is still based on the moving ecliptic, and -moreover the fixed stars have a small proper motion, as well.
- -- -
3) projection onto the ecliptic of t0 -(implemented in Swiss Ephemeris as an option)
- -- -
Another -possibility would be to project the planets onto the reference ecliptic of the ayanamsha -– for Fagan/Bradley, e.g., this would be the ecliptic of 1950 – by a correct coordinate -transformation and then subtract 24.042°, the initial value of the ayanamsha. -
- -- -
If we -follow this method, the position of the galactic center will always be the same -(2 sag 06'40.4915 -5°36' 4.0652 (without aberration))
- -- -
This method -is geometrically sounder than the traditional one, but still it has a problem. -For, if we want everything referred to the ecliptic of a fixed date t0, we will -have to choose that date very carefully. Its ecliptic ought to be of special -importance. The ecliptic of 1950 or the one of 1900 are obviously meaningless -and not suitable as a reference plane. And how about that 18 March 564, on -which the tropical and the sidereal zero point coincided? Although this may be -considered as a kind of cosmic anniversary (the Sassanians did so), the -ecliptic plane of that time does not have an ”eternal” value. It is different -from the ecliptic plane of the previous anniversary around the year 26000 BC, -and it is also different from the ecliptic plane of the next cosmic anniversary -around the year 26000 AD.
- -- -
This -algorithm is supported by the Swiss Ephemeris, too. However, it must not be -used with the Fagan/Bradley definition or with other definitions that were -calibrated with the traditional method of ayanamsha subtraction. It can -be used for computations of the following kind:
- -a) Astronomers may want to calculate positions -referred to a standard equinox like J2000, B1950, or B1900, or to any other -equinox.
- -b) Astrologers may be interested in the -calculation of precession-corrected transits. See explanations in the -next chapter.
- -c) The algorithm can be applied to the Sassanian -ayanamsha or to any user-defined sidereal mode, if the ecliptic of its -reference date is considered to be astrologically significant.
- -d) The algorithm makes the problems of the -traditional method visible. It shows the dimensions of the inherent inaccuracy -of the traditional method.
- -- -
For the planets -and for centuries close to t0, the difference from the traditional procedure -will be only a few arc seconds in longitude. Note that the Sun will have an -ecliptical latitude of several arc minutes after a few centuries.
- -- -
For the -lunar nodes, the procedure is as follows:
- -Because the -lunar nodes have to do with eclipses, they are actually points on the ecliptic -of date, i.e. on the tropical zodiac. Therefore, we first compute the nodes as -points on the ecliptic of date and then project them onto the sidereal zodiac. -This procedure is very close to the traditional method of computing sidereal -positions (a matter of arc seconds). However, the nodes will have a latitude of -a couple of arc minutes.
- -- -
For the -axes and houses, we compute the points where the horizon or the house lines -intersect with the sidereal plane of the zodiac, not with the ecliptic -of date. Here, there are greater deviations from the traditional procedure. If t -is 2000 years from t0 the difference between the ascendant positions -might well be 1/2 degree.
- -- -
4) The long-term mean Earth-Sun plane (not -implemented in Swiss Ephemeris)
- -- -
To avoid -the problem of choice of a reference ecliptic, we might watch out for a kind of -”average ecliptic”. As a matter of fact, there are some possibilities in this -direction. The mechanism of the planetary precession mentioned above works in a -similar way as the mechanism of the luni-solar precession. The movement of the -earth orbit can be compared to a spinning top, with the earth mass equally -distributed around the whole orbit. The other planets, especially Venus and -Jupiter, cause it to move around an average position. But unfortunately, this -”long-term mean Earth-Sun plane” is not really stable, either, and therefore -not suitable as a fixed reference frame.
- -- -
The period -of this cycle is about 75000 years. The angle between the long-term mean plane -and the ecliptic of date is at the moment about 1°33’, but it changes -considerably. (This cycle must not be confused with the period between two -maxima of the ecliptic obliquity, which is about 40000 years and often -mentioned in the context of planetary precession. This is the time it takes the -vernal point to return to the node of the ecliptic (its rotation point), and -therefore the oscillation period of the ecliptic obliquity.)
- -- -
5) The solar system rotation plane -(implemented in Swiss Ephemeris as an option)
- -- -
The solar -system as a whole has a rotation axis, too, and its equator is quite close to -the ecliptic, with an inclination of 1°34’44” against the ecliptic of the year -2000. This plane is extremely stable and probably the only convincing candidate -for a fixed zodiac plane.
- -- -
This method -avoids the problem of method 3). No particular ecliptic has to be chosen as a -reference plane. The only remaining problem is the choice of the zero point.
- -- -
This -algorithm must not be applied to any of the predefined sidereal modes, except -the Sassanian one. You can use this algorithm, if you want to research on a -better-founded sidereal astrology, experiment with your own sidereal mode, and -calibrate it as you like.
- -- -
- -
- -
Method no. -3, the transformation to the ecliptic of t0, opens two more possibilities:
- -You can -compute positions referred to any equinox, 2000, 1950, 1900, or whatever you -want. This is sometimes useful when Swiss Ephemeris data ought to be compared -with astronomical data, which are often referred to a standard equinox.
- -There are -predefined sidereal modes for these standard equinoxes:
- -18) J2000
- -19) J1900
- -20) B1950
- -- -
Moreover, -it is possible to compute precession-corrected transits or synastries -with very high precision. An astrological transit is defined as the passage of -a planet over the position in your birth chart. Usually, astrologers assume -that tropical positions on the ecliptic of the transit time has to be compared -with the positions on the tropical ecliptic of the birth date. But it has been -argued by some people that a transit would have to be referred to the ecliptic -of the birth date. With the new Swiss Ephemeris algorithm (method no. 3) it is -possible to compute the positions of the transit planets referred to the -ecliptic of the birth date, i.e. the so-called precession-corrected -transits. This is more precise than just correcting for the precession in -longitude (see details in the programmer's documentation swephprg.doc, -ch. 8.1).
- -- -
The Swiss ephemeris provides the calculation of apparent or true -planetary positions. Traditional astrology works with apparent positions. -”Apparent” means that the position where we see the planet is used, not -the one where it actually is. Because the light's speed is finite, a planet is -never seen exactly where it is. (see above, 2.1.3 ”The details of coordinate -transformation”, light-time and aberration) Astronomers therefore make a -difference between apparent and true positions. However, this -effect is below 1 arc minute.
- -Most astrological ephemerides provide apparent positions. However, -this may be wrong. The use of apparent positions presupposes that astrological -effects can be derived from one of the four fundamental forces of physics, -which is impossible. Also, many astrologers think that astrological ”effects” -are a synchronistic phenomenon (the ones familiar with physics may refer to the -Bell theorem). For such reasons, it might be more convincing to work with true -positions.
- -Moreover, the Swiss Ephemeris supports so-called astrometric -positions, which are used by astronomers when they measure positions of -celestial bodies with respect to fixed stars. These calculations are of no use -for astrology, though.
- -More precisely speaking, common ephemerides tell us the position where -we would see a planet if we stood in the center of the earth and could see the -sky. But it has often been argued that a planet’s position ought to be referred -to the geographic position of the observer (or the birth place). This can make -a difference of several arc seconds with the planets and even more than a -degree with the moon! Such a position referred to the birth place is called -the topocentric planetary position. The observation of transits over the -moon might help to find out whether or not this method works better.
- -For very precise topocentric calculations, the Swiss Ephemeris not only -requires the geographic position, but also its altitude above sea. An altitude -of 3000 m (e.g. Mexico City) may make a difference of more than 1 arc second -with the moon. With other bodies, this effect is of the amount of a 0.01”. The -altitudes are referred to the approximate earth ellipsoid. Local irregularities -of the geoid have been neglected.
- -Our topocentric lunar positions differ from the NASA positions (s. the Horizons -Online Ephemeris System http://ssd.jpl.nasa.gov) by 0.2 - 0.3 arc sec. This -corresponds to a geographic displacement by a few 100 m and is about the best -accuracy possible. In the documentation of the Horizons System, -it is written that: "The Earth is assumed to be a rigid body. ... These -Earth-model approximations result in topocentric station location errors, with -respect to the reference ellipsoid, of less than 500 meters."
- -The Swiss ephemeris also allows the computation of apparent or true topocentric -positions.
- -With the lunar nodes and apogees, Swiss Ephemeris does not make a -difference between topocentric and geocentric positions. There are manyfold -ways to define these points topocentrically. The simplest one is to understand -them as axes rather than points somewhere in space. In this case, the -geocentric and the topocentric positions are identical, because an axis is an -infinite line that always points to the same direction, not depending on the -observer's position.
- -Moreover, the Swiss Ephemeris supports the calculation of heliocentric -and barycentric planetary positions. Heliocentric positions are -positions as seen from the center of the sun rather than from the center of the -earth. Barycentric ones are positions as seen from the center of the solar -system, which is always close to but not identical to the center of the sun.
- -From Swiss Ephemeris version 1.76 on, heliacal -events have been included. The heliacal rising and setting of planets and stars -was very important for ancient Babylonian and Greek astronomy and -astrology. Also, first and last -visibility of the Moon can be calculated, which are important for many -calendars, e.g. the Islamic, Babylonian and ancient Jewish calendars.
- -The heliacal events that can be determined are:
- -· -Inferior -planets
- -·Heliacal -rising (morning first)
- -·Heliacal -setting (evening last)
- -·Evening -first
- -·Morning last
- -· -Superior -planets and stars
- -·Heliacal -rising
- -·Heliacal setting
- -- -
· -Moon
- -·Evening -first
- -·Morning -last
- -- -
The -acronychal risings and settings (also called cosmical settings) of superior -planets are a different matter. They will be added in a future version of the -Swiss Ephemeris.
- -- -
The principles behind the calculation are based -on the visibility criterion of Schaefer [1993, 2000], which includes -dependencies on aspects of:
- -·
-Position
-celestial objects
-like the position and magnitude of the Sun, Moon and the studied celestial object,
-
·
-Location
-and optical properties observer
-like his/her location (longitude, latitude, height), age, acuity and possible
-magnification of optical instruments (like binoculars)
·
-Meteorological
-circumstances
-mainly expressed in the astronomical extinction coefficient, which is
-determined by temperature, air pressure, humidity, visibility range (air
-quality).
·
-Contrast
-between studied object and sky background
-The observer’s eye can on detect a certain amount of contract and this contract
-threshold is the main body of the calculations
In the following sections above aspects will be -discussed briefly and an idea will be given what functions are available to -calculate the heliacal events. Lastly the future developments will be -discussed.
- -The theory behind this visibility criterion is -explained by Schaefer [1993, 2000] and the implemented by Reijs [2003] and Koch -[2009]. The general ideas behind this theory are explained in the following -subsections.
- -To determine the visibility of a celestial -object it is important to know where the studied celestial object is and what -other light sources are in the sky. Thus beside determining the position of the -studied object and its magnitude, it also involves calculating the position of -the Sun (the main source of light) and the Moon. This is common functions -performed by Swiss Ephemeris.
- -The location of the observer determines the -topocentric coordinates (incl. influence of refraction) of the celestial object -and his/her height (and altitude of studied object) will have influence on the -amount of airmass that is in the path of celestial object’s light.
- -The observer’s eyes will determine the -resolution and the contrast differences he/she can perceive (depending on age -and acuity), furthermore the observer might used optical instruments (like -binocular or telescope).
- -The meteorological circumstances are very -important for determining the visibility of the celestial object. These -circumstances influence the transparency of the airmass (due to -Rayleigh&aerosol scattering and ozone&water absorption) between the -celestial object and the observer’s eye. This result in the astronomical -extinction coefficient (AEC: ktot). As this is a complex -environment, it is sometimes ‘easier’ to use a certain AEC, instead of -calculating it from the meteorological circumstances.
- -The parameters are stored in the datm (Pressure -[mbar], Temperature [C], Relative humidity [%], AEC [-]) array.
- -All the above aspects influence the perceived -brightnesses of the studied celestial object and its background sky. The -contrast threshold between the studied object and the background will determine -if the observer can detect the studied object.
- -Two functions are seen as the spill of -calculating the heliacal events:
- -Based on all the aspects mentioned earlier, the -contrast threshold is determine which decides if the studied object is visible -by the observer or not.
- -In general this procedure works in such a way -that it finds (through iterations) the day that conjunction/opposition between -Sun and studied object happens and then it determines, close to Sun’s rise or -set (depending on the heliacal event), when the studied object is visible (by -using the swe_vis_limit_magn function).
- -This function is limited to geographic -latitudes between 60S and 60N. Beyond that the heliacal phenomena of the -planets become erratic. We found cases -of strange planetary behavior even at 55N.
- -An example:
- -At 0E, 55N, with an extinction coefficient 0.2, -Mars had a heliacal rising on 25 Nov. 1957. But during the following weeks and -months Mars did not constantly increase its height above the horizon before -sunrise. In contrary, it disappeared again, i.e. it did a “morning last” on 18 -Feb. 1958. Three months later, on 14 May 1958, it did a second morning first -(heliacal rising). The heliacal setting or evening last took place on 14 June -1959.
- -Currently, this special case is not handled by -swe_heliacal_ut(). The function cannot detect “morning lasts” of Mars and -following “second heliacal risings”. The function only provides the heliacal -rising of 25 Nov. 1957 and the next -ordinary heliacal rising in its ordinary synodic cycle which took place on 11 -June 1960.
- -However, we may find a solution for such -problems in future releases of the Swiss Ephemeris and even extend the -geographic range of swe_heliacal_ut() to beyond +/- 60.
- -For the Moon, swe_heliacal_ut() calculates the -evening first and the morning last. For each event, the function returns the -optimum visibility and a time of visibility start and visibility end. Note, -that on the day of its morning last or evening first, the moon is often visible -for almost the whole day. It even happens that the crescent first becomes -visible in the morning after its rising, then disappears, and again reappears -during culmination, because the observation conditions are better as the moon -stands high above the horizon. The function swe_heliacal_ut() does not handle -this in detail. Even if the moon is visible after sunrise, the function assumes -that the end time of observation is at sunrise. The evening fist is handled in -the same way.
- -With Venus, we have a similar situation. Venus -is often accessible to naked eye observation during day, and sometimes even -during inferior conjunction, but usually only at a high altitude above the -horizon. This means that it may be visible in the morning at its heliacal -rising, then disappear and reappear during culmination. (Whoever does not believe me, please read -the article by H.B. Curtis listed under “References”.) The function swe_heliacal_ut() does not -handle this case. If binoculars or a telescope is used, Venus may be even -observable during most of the day on which it first appears in the east.
- -The section of the Swiss Ephemeris software is -still under development. The acronychal events of superior planets and stars -will be added. And comparing other visibility criterions will be included; like -Schoch’s criterion [1928], Hoffman’s overview [2005] and -Caldwall&Laney criterion [2005].
- -- Caldwell, J.A.R., Laney, C.D., First -visibility of the lunar crescent, http://www.saao.ac.za/public-info/sun-moon-stars/moon-index/lunar-crescent-visibility/first-visibility-of-lunar-crescent/, 2005, viewed March, 30th, -2009
- -- H.B. Curtis, Venus Visible at inferior -conjunction, in : Popular Astronomy vol. 18 (1936), p. 44; -online at http://articles.adsabs.harvard.edu/cgi-bin/nph-iarticle_query?1936PA.....44...18C&data_type=PDF_HIGH&whole_paper=YES&type=PRINTER&filetype=.pdf
- -- Hoffman, R.E., Rational design of -lunar-visibility criteria, The observatory, Vol. 125, June 2005, No. -1186, pp 156-168.
- -- Reijs, V.M.M., Extinction angle and heliacal events, -http://www.iol.ie/~geniet/eng/extinction.htm, 2003, viewed March, 30th, -2009
- -- Schaefer, B., Astronomy and the limit of -vision, Vistas in astronomy, 36:311, 1993
- -- Schaefer, B., New methods and techniques for -historical astronomy and archaeoastronomy, Archaeoastronomy, Vol. XV, -2000, page 121-136
- -- Schoch, K., Astronomical and calendrical -tables in Langdon. S., Fotheringham, K.J., The Venus tables of Amninzaduga: -A solution of Babylonian chronology by means of Venus observations of the first -dynasty, Oxford, 1928.
- -- -
The Swiss Ephemeris also includes functions for many calculations -concerning solar and lunar eclipses. You can:
- -- search for eclipses or occultations, globally or for a given -geographical position
- -- compute global or local circumstances of eclipses or occultations
- -- compute the geographical position where an eclipse is central
- -Moreover, you can compute for all planets and asteroids:
- -- risings and settings (also for stars)
- -- midheaven and lower heaven transits (also for stars)
- -- height of a body above the horizon (refracted and true, also for -stars)
- -- phase angle
- -- phase (illumined fraction of disc)
- -- elongation (angular distance between a planet and the sun)
- -- apparent diameter of a planetary disc
- -- apparent magnitude.
- -The Swiss Ephemeris package -also includes a function that computes the Ascendant, the MC, the houses, the -Vertex, and the Equatorial Ascendant (sometimes called "East Point").
- -The following house methods -have been implemented so far:
- -This system is named after the Italian monk -Placidus de Titis (1590-1668). The cusps are defined by divisions of -semidiurnal and seminocturnal arcs. The 11th -cusp is the point on the ecliptic that has completed 2/3 of its semidiurnal -arc, the 12th cusp the point that has completed 1/3 of it. -The 2nd cusp has completed 2/3 of its seminocturnal arc, and the 3rd cusp 1/3.
- -This system is called after -the German astrologer Walter Koch (1895-1970). Actually it was invented by -Fiedrich Zanzinger and Heinz Specht, but it was made known by Walter Koch. In -German-speaking countries, it is also called the -"Geburtsorthäusersystem" (GOHS), i.e. the "Birth place house -system". Walter Koch thought that this system was more related to the -birth place than other systems, because all house cusps are computed with the "polar -height of the birth place", which has the same value as the geographic -latitude.
- -This argumentation shows -actually a poor understanding of celestial geometry. With the Koch system, the -house cusps are actually defined by horizon lines at different times. To -calculate the cusps 11 and 12, one can take the time it took the MC degree to -move from the horizon to the culmination, divide this time into three and see -what ecliptic degree was on the horizon at the thirds. There is no reason why -this procedure should be more related to the birth place than other house -methods.
- -Named after the Johannes -Müller (called "Regiomontanus", because he stemmed from Königsberg) -(1436-1476).
- -The equator is divided into 12 -equal parts and great circles are drawn through these divisions and the north -and south points on the horizon. The intersection points of these circles with -the ecliptic are the house cusps.
- -Named after Giovanni di Campani -(1233-1296).
- -The vertical great circle from -east to west is divided into 12 equal parts and great circles are drawn through -these divisions and the north and south points on the horizon. The intersection -points of these circles with the ecliptic are the house cusps.
- -The zodiac is divided into 12 -houses of 30 degrees each starting from the Ascendant.
- -Equal houses with the -Ascendant positioned in the middle of the first house.
- -Also called the "Meridian -house system". The equator is partitioned into 12 equal parts starting -from the ARMC. Then the ecliptic points are computed that have these divisions -as their right ascension. Note: The ascendant is different from the 1st -house cusp.
- -The equator is divided into 12 -equal parts starting from the ARMC. The resulting 12 points on the equator are -transformed into ecliptic coordinates. Note: The Ascendant is different from -the 1st cusp, and the MC is different from the 10th cusp. -
- -The house cusps are defined by -division of the horizon into 12 directions. The first house cusp is not -identical with the Ascendant but is located precisely in the east.
- -This system was introduced in -1961 by Wendel Polich and A.P. Nelson Page. Its construction is rather -abstract: The tangens of the polar height of the 11th house is the -tangens of the geo. latitude divided by 3. (2/3 of it are taken for the 12th -house cusp.) The philosophical reasons for this algorithm are obscure. Nor is this -house system more “topocentric” (i.e. birth-place-related) than any other house -system. (c.f. the misunderstanding with the “birth place system”.) The -“topocentric” house cusps are close to Placidus house cusps except for high -geographical latitudes. It also works for latitudes beyond the polar circles, -wherefore some consider it to be an improvement of the Placidus system. -However, the striking philosophical idea behind Placidus, i.e. the division of -diurnal and nocturnal arcs of points of the zodiac, is completely abandoned.
- -A method of house division -which first appears with the Hellenistic astrologer Rhetorius (500 A.D.) but is -named after Alcabitius, an Arabic astrologer, who lived in the 10th century -A.D. This is the system used in the few remaining examples of ancient Greek -horoscopes.
- -The MC and ASC are -respectively the 10th- and 1st- house cusps. The remaining cusps are determined -by the trisection of the semidiurnal and seminocturnal arcs of the ascendant, -measured on the celestial equator. The houses are formed by great circles that -pass through these trisection points and the celestial north and south poles.
- -This is the “house” system -used by the Gauquelins and their epigones and critics in statistical -investigations in Astrology. Basically, it is identical with the Placidus house -system, i.e. diurnal and nocturnal arcs of ecliptic points or planets are -subdivided. There are a couple of differences, though.
- -- -Up to 36 “sectors” (or house cusps) are used instead of 12 houses.
- -- -The sectors are counted in clockwise direction.
- -- -There are so-called plus (+) and minus (–) zones. The plus zones are the -sectors that turned out to be significant in statistical investigations, e.g. -many top sportsmen turned out to have their Mars in a plus zone. The plus -sectors are the sectors 36 – 3, 9 – 12, 19 – 21, 28 – 30.
- -- -More sophisticated algorithms are used to calculate the exact house -position of a planet (see chapters 6.4 and 6.5 on house positions and Gauquelin -sector positions of planets).
- -- -
This house system was first published in 1994/1995 by three different -authors independently of each other:
- -- by Bogdan -Krusinski (Poland)
- -- by Milan Pisa -(Czech Republic) under the name “Amphora house system”.
- -- by Georg Goelzer (Switzerland) under the name “Ich-Kreis-Häusersystem” -(“I-Circle house system”)..
- -Krusinski -defines the house system as “… based on the great circle passing through -ascendant and zenith. This circle is divided into 12 equal parts (1st cusp is -ascendant, 10th cusp is zenith), then the resulting points are projected onto -the ecliptic through meridian circles. The house cusps in space are -half-circles perpendicular to the equator and running from the north to the south -celestial pole through the resulting cusp points on the house circle. The -points where they cross the ecliptic mark the ecliptic house cusps.” -(Krusinski, e-mail to Dieter Koch)
- -It -may seem hard to believe that three persons could have discovered the same -house system at almost the same time. But apparently this is what happened. -Some more details are given here, in order to refute wrong accusations from the -Czech side against Krusinski of having “stolen” the house system.
- -Out of the documents that Milan Pisa sent to -Dieter Koch, the following are to be mentioned: Private correspondence from -1994 and 1995 on the house system between Pisa and German astrologers Böer and -Schubert-Weller, two type-written (apparently unpublished) treatises in German -on the house system dated from 1994. A printed booklet of 16 pages in Czech -from 1997 on the theory of the house system (“Algoritmy noveho systemu -astrologickych domu”). House tables computed by Michael Cifka for the -geographical latitude of Prague, copyrighted from 1996. The house system was -included in the Czech astrology software Astrolog v. 3.2 (APAS) in 1998. Pisa’s -first publication on the house system happened in spring 1997 in “Konstelace“ -No. 22, the periodical of the Czech Astrological Society.
- -- -
Bogdan Krusinski first published the house -system at an astrological congress in Poland, the “"XIV -Szkola Astrologii Humanistycznej" held by Dr Leszek Weres, which took -place between 15.08.1995 and 28.08.1995 in -Pogorzelica at cost of the Baltic Sea.” Since -then Krusinski has distributed printed house tables for the Polish geographical -latitudes 49-55° and floppy disks with house tables for latitudes 0-90°. In -1996, he offered his program code to Astrodienst for implementation of this -house system into Astrodienst’s then astronomical software Placalc. (At that -time, however, Astrodienst was not interested in it.) In May 1997, Krusinski -put the data on the web at http://www.ci.uw.edu.pl/~bogdan/astrol.htm (now at -http://www.astrologia.pl/main/domy.html) In February 2006 he sent -Swiss-Ephemeris-compatible program code in C for this house system to -Astrodienst. This code was included into Swiss Ephemeris Version 1.70 and -released on 8 March 2006.
- -- -
Georg Goelzer describes the same house system -in his book “Der Ich-Kosmos”, which appeared in July 1995 at Dornach, -Switzerland (Goetheanum). The book has a second volume with house tables -according to the house method under discussion. The house tables were created -by Ulrich Leyde. Goelzer also uses a house calculation programme which has the -time stamp “9 April 1993” and produces the same house cusps.
- -- -
By March 2006, when the house system was -included in the Swiss Ephemeris under the name -of “Krusinski houses”, neither Krusinski nor Astrodienst knew about the -works of Pisa and Goelzer. Goelzer heard of his co-discoverers only in 2012 and -then contacted Astrodienst.
- -- -
Conclusion: It seems that the house system was -first “discovered” and published by -Goelzer, but that Pisa and Krusinski also “discovered” it independently. -We do not consider this a great miracle because the number of possible house -constructions is quite limited.
- - - -The Vertex is the point -of the ecliptic that is located precisely in western direction. The Antivertex -is the opposition point and indicates the precise east in the horoscope. It is -identical to the first house cusp in the horizon house system.
- -There is a lot of confusion -about this, because there is also another point which is called the "East -Point" but is usually not located in the east. In celestial -geometry, the expression "East Point" means the point on the horizon -which is in precise eastern direction. The equator goes through this point as -well, at a right ascension which is equal to ARMC + 90 degrees. On the other -hand, what some astrologers call the "East Point" is the point on the -ecliptic whose right ascension is equal to ARMC + 90 (i.e. the right ascension -of the horizontal East Point). This point can deviate from eastern direction by -23.45 degrees, the amount of the ecliptic obliquity. For this reason, the -term "East Point" is not very -well-chosen for this ecliptic point, and some astrologers (M. Munkasey) prefer -to call it the Equatorial Ascendant. This, because it is identical to -the Ascendant at a geographical latitude 0.
- -The Equatorial Ascendant is -identical to the first house cusp of the axial rotation system.
- -Note: If a projection of the -horizontal East Point on the ecliptic is wanted, it might seem more reasonable -to use a projection rectangular to the ecliptic, not rectangular to the equator -as is done by the users of the "East Point". The planets, as well, -are not projected on the ecliptic in a right angle to the ecliptic.
- -The Swiss Ephemeris supports -three more points connected with the house and angle calculation. They are part -of Michael Munkasey's system of the 8 Personal Sensitive Points (PSP). -The PSP include the Ascendant, the MC, the Vertex, the Equatorial -Ascendant, the Aries Point, the Lunar Node, -and the "Co-Ascendant" and the "Polar Ascendant".
- -The term -"Co-Ascendant" seems to have been invented twice by two different -people, and it can mean two different things. The one "Co-Ascendant" -was invented by Walter Koch (?). To calculate it, one has to take the ARIC as -an ARMC and compute the corresponding Ascendant for the birth place. The -"Co-Ascendant" is then the opposition to this point.
- -The second -"Co-Ascendant" stems from Michael Munkasey. It is the Ascendant -computed for the natal ARMC and a latitude which has the value 90° - -birth_latitude.
- -The "Polar -Ascendant" finally was introduced by Michael Munkasey. It is the -opposition point of Walter Koch's version of the "Co-Ascendant". -However, the "Polar Ascendant" is not the same as an Ascendant -computed for the birth time and one of the geographic poles of the earth. At -the geographic poles, the Ascendant is always 0 Aries or 0 Libra. This is not -the case for Munkasey's "Polar Ascendant".
- -- -
Beyond the polar circle, we proceed as follows:
- -1) We make sure that -the ascendant is always in the eastern hemisphere.
- -2) Placidus and Koch house -cusps sometimes can, sometimes cannot be computed beyond the polar circles. -Even the MC doesn't exist always, if one defines it in the Placidus manner. Our -function therefore automatically switches to Porphyry houses (each quadrant is -divided into three equal parts) and returns a warning.
- -3) Beyond the polar -circles, the MC is sometimes below the horizon. The geometrical definition of -the Campanus and Regiomontanus systems requires in such cases -that the MC and the IC are swapped. The whole house system is then oriented in -clockwise direction.
- -There are similar problems with the Vertex and the horizon -house system for birth places in the tropics. The Vertex is defined -as the point on the ecliptic that is located in precise western direction. The -ecliptic east point is the opposition point and is called the Antivertex. -Our program code makes sure that the Vertex (and the cusps 11, 12, 1, 2, 3 of the -horizon house system) is always located in the western hemisphere. Note that -for birthplaces on the equator the Vertex is always 0 Aries or 0 Libra.
- -Of course, there are no problems in the calculation of the Equatorial -Ascendant for any place on earth.
- -a) PLACALC
- -Placalc is the predecessor of Swiss Ephemeris; it is a calculation -module created by Astrodienst in 1988 and distributed as C source code. Beyond -the polar circles, Placalc‘s house calculation did switch to Porphyry houses -for all unequal house systems. Swiss Ephemeris still does so with the Placidus -and Koch method, which are not defined in such cases. However, the computation -of the MC and Ascendant was replaced by a different model in some cases: Swiss -Ephemeris gives priority to the Ascendant, choosing it always as the -eastern rising point of the ecliptic and accepting an MC below the horizon, -whereas Placalc gave priority to the MC. The MC was always chosen as the -intersection of the meridian with the ecliptic above the horizon. To -keep the quadrants in the correct order, i.e. have an Ascendant in the left -side of the chart, the Ascendant was switched by 180 degrees if necessary.
- -In the discussions between Alois Treindl and Dieter Koch during the -development of the Swiss Ephemeris it was recognized that this model is more -unnatural than the new model implemented in Swiss Ephemeris.
- -Placalc also made no difference between Placidus/Koch on one hand and -Regiomontanus/Campanus on the other as Swiss Ephemeris does. In Swiss -Ephemeris, the geometrical definition of Regiomontanus/Campanus is strictly -followed, even for the price of getting the houses in ”wrong” order. (see -above, chapter 4.1.)
- -b) ASTROLOG program as written by Walter Pullen
- -While the freeware program Astrolog contains the planetary routines of -Placalc, it uses its own house calculation module by Walter Pullen. Various -releases of Astrolog contain different approaches to this problem.
- -c) ASTROLOG on our website
- -ASTROLOG is also used on Astrodienst’s website for displaying free -charts. This version of Astrolog used on our website however is different from -the Astrolog program as distributed on the Internet. Our webserver version of -Astrolog contains calls to Swiss Ephemeris for planetary positions. For -Ascendant, MC and houses it still uses Walter Pullen's code. This will change -in due time because we intend to replace ASTROLOG on the website with our own -charting software.
- -d) other astrology programs
- -Because most astrology programs still use the Placalc module, they -follow the Placalc method for houses inside the polar circles. They give -priority to keep the MC above the horizon and switch the Ascendant by 180 -degrees if necessary to keep the quadrants in order.
- -The Swiss Ephemeris DLL also provides a function to compute the house -position of a given body, i.e. in which house it is. This function can be used -either to determine the house number of a planet or to compute its position in -a house horoscope. (A house horoscope is a chart in which all -houses are stretched or shortened to a size of 30 degrees. For unequal house -systems, the zodiac is distorted so that one sign of the zodiac does not -measure 30 house degrees)
- -Note that the actual house position of a planet is not always the one -that it seems to be in an ordinary chart drawing. Because the planets are not -always exactly located on the ecliptic but have a latitude, they can seemingly -be located in the first house, but are actually visible above the horizon. In -such a case, our program function will place the body in the 12th (or 11 th or -10 th) house, whatever celestial geometry requires. However, it is possible to -get a house position in the ”traditional” way, if one sets the ecliptic -latitude to zero.
- -Although it is not possible to compute Placidus house cusps -beyond the polar circle, this function will also provide Placidus house -positions for polar regions. The situation is as follows:
- -The Placidus method works with the semidiurnal and seminocturnal arcs of -the planets. Because in higher geographic latitudes some celestial bodies (the -ones within the circumpolar circle) never rise or set, such arcs do not exist. -To avoid this problem it has been proposed in such cases to start the diurnal -motion of a circumpolar body at its ”midnight” culmination and its nocturnal -motion at its midday culmination. This procedure seems to have been proposed by -Otto Ludwig in 1930. It allows to define a planet's house position even if it -is within the circumpolar region, and even if you are born in the northernmost -settlement of Greenland. However, this does not mean that it be possible to -compute ecliptical house cusps for such locations. If one tried that, it would -turn out that e.g. an 11 th house cusp did not exist, but there were two 12th -house cusps.
- -Note however, that circumpolar bodies may jump from the 7th house -directly into the 12th one or from the 1st one directly into the 6th one.
- -The Koch method, on the other hand, cannot be helped even with -this method. For some bodies it may work even beyond the polar circle, but for -some it may fail even for latitudes beyond 60 degrees. With fixed stars, it may -even fail in central Europe or USA. (Dieter Koch regrets the connection of his -name with such a badly defined house system)
- -Note that Koch planets do strange jumps when the cross the meridian. -This is not a computation error but an effect of the awkward definition of this -house system. A planet can be east of the meridian but be located in the
- -9th house, or west of the meridian and in the 10th house. It is possible -to avoid this problem or to make Koch house positions agree better with the -Huber ”hand calculation” method, if one sets the ecliptic latitude of the -planets to zero. But this is not more correct from a geometrical point of view.
- -The calculation of the -Gauquelin sector position of a planet is based on the same idea as the Placidus -house system, i.e. diurnal and nocturnal arcs of ecliptic points or planets are -subdivided.
- -Three different algorithms -have been used by Gauquelin and others to determine the sector position of a -planet.
- -1. -We can take the ecliptic point of the planet (ecliptical latitude -ignored) and calculate the fraction of its diurnal or nocturnal arc it has -completed
- -2. -We can take the true planetary position (taking into account ecliptical -latitude) for the same calculation.
- -3. -We can use the exact times for rise and set of the planet to determine -the ratio between the time the planet has already spent above (or below) the -horizon and its diurnal (or nocturnal) arc. Times of rise and set are defined -by the appearance or disappearance of the center of the planet’s disks.
- -All three methods are -supported by the Swiss Ephemeris.
- -Methods 1 and 2 also work for -polar regions. The Placidus algorithm is used, and the Otto Ludwig method -applied with circumpolar bodies. I.e. if a planet does not have a rise and set, -the “midnight” and “midday” culminations are used to define its semidiurnal and -seminocturnal arcs.
- -With method 3, we don’t try to -do similar. Because planets do not culminate exactly in the north or south, a -planet can actually rise on the western part of the horizon in high geographic -latitudes. Therefore, it does not seem appropriate to use meridian transits as -culmination times. On the other hand, true culmination times are not always -available. E.g. close to the geographic poles, the sun culminates only twice a -year.
- -The computation of planets uses the so called Ephemeris Time (ET) -which is a completely regular time measure. Computations of sidereal time and -houses, on the other hand, depend on the rotation of the earth, which is not -regular at all. The time used for such purposes is called Universal Time (UT) -or Terrestrial Dynamic Time (TDT). It is an irregular time measure, and -is roughly identical to the time indicated by our clocks (if time zones are -neglected). The difference between ET and UT is called DT (”Delta T”), and -is defined as DT = ET – UT.
- -The earth's rotation decreases slowly, currently at the rate of about -0.5 – 1 second per year. Even worse, this decrease is irregular itself. It -cannot precisely predicted but only derived from star observations. The values -of DT achieved like this must be tabulated. However, this -table, which is published yearly by the Astronomical Almanac, starts only at -1620, about the time when the telescope was invented. For more remote -centuries, DT must be estimated from old eclipse records. The -uncertainty is in the range of hours for the year 3000 B.C. For future times, DT is estimated from -the current and the general changing rate, depending on whether a short-term or -a long-term extrapolation is intended.
- -NOTE:The DT algorithms have been -improved with the Swiss Ephemeris release 1.64 (Stephenson 1997), with release -1.72 (Morrison/Stephenson 2004) and 1.77 (Espenak & Meeus). These changes -result in significant changes of the ephemeris for remote historical dates, if -Universal Time is used.
- -The Swiss Ephemeris computes DT as follows.
- -1633 - today + a -couple of years:
- -The tabulated values of DT, in hundredths of a second, -were taken from the Astronomical Almanac page K8 and K9 and are yearly updated. -
- -The DT function adjusts for a value of secular tidal -acceleration ndot = -25.826 arcsec per century squared, the value contained in -JPL's lunar ephemeris LE405/6. ELP2000 (and DE200) used the value -23.8946.
- -To change ndot, one can either redefine SE_TIDAL_DEFAULT in swephexp.h -or use the routine swe_set_tid_acc() before calling the Swiss Ephemeris.
- -Bessel's interpolation formula was implemented to obtain fourth order -interpolated values at intermediate times.
- --before 1633:
- -For dates before 1600, the polynomials published by Espenak and Meeus -(2006) are used, with linear interpolation. They are based on an assumed value -of ndot = -26. The program adjusts for ndot = -25.826. These formulae include -the long-term formula by Morrison/Stephenson (2004, p. 332), which is used for -epochs before -500.
- -future:
- -For the time after the last tabulated value, we use the formula of -Stephenson (1997; p. 507), with a modification that avoids a jump at the end of -the tabulated period. A linear term is added that makes a slow transition from -the table to the formula over a period of 100 years. (Need not be updated, when -table will be enlarged.)
- -Differences between -the old and new algorithms (before and after release 1.77):
- -year -difference in seconds (new - old)
- --3000 3
- --2000 - 2
- --1100 - 1
- --1001 -29
- --900 --45
- --800 --57
- --700 - -696 (is a maximum!)
- --500 --14
- -until -200 3 -> diff > -25
- -until 100 3 -> diff > -15
- -until 500 3 -> diff > -3
- -until 1600 4 -> diff > -16
- -until 1630 1 -> diff > -30
- -until 1700 0.1 -|diff|
- -until 1900 0.01
- -until 2100 0.001
- -- -
The differences for –1000 to + 1630 are explained as -follows:
- -Espenak & Meeus ignore Morrison & Stephenson's -values for -700 and -600, whereas the former Swiss Ephemeris versions used -them. For -500 to +1600 Espenak & Meeus use polynomials whereas the former -Swiss Ephemeris versions used a linear interpolation between Morrison / -Stephenson's tabulated values.
- -- -
Differences between -the old and new algorithms (before and after release 1.72):
- -year -difference in seconds (new - old)
- --3000 -4127
- --2000 - -2130
- --1000 - -760
- -0 -20
- -1000 -30
- -1600 10
- -1619 0.5
- -1620 0
- -- -
Differences between -the old and new algorithms (before and after release 1.64):
- -year -difference in seconds (new - old)
- --3000 2900
- -0 1200
- -1600 29
- -1619 60
- -1620 -0.6
- -1700 -0.4
- -1800 -0.1
- -1900 -0.02
- -1940 -0.001
- -1950 0
- -2000 0
- -2020 2
- -2100 23
- -3000 -400
- -In 1620, where the DT table of the Astronomical -Almanac starts, there was a jump of a whole minute in the old algorithms. The -new algorithms has no jumps anymore.
- -The smaller differences for the period 1620-1955, where we still use the -same data as before, is due to a correction in the tidal acceleration of the -moon, which now has the same value as is also used by JPL for their DT calculations.
- -References:
- -- -
- Borkowski, K. M., "ELP2000-85 and the Dynamical Time - Universal -Time relation," Astronomy and -Astrophysics 205, L8-L10 (1988)
- -- Chapront-Touze, Michelle, and Jean Chapront, Lunar Tables and Programs from 4000 B.C. to A.D. 8000, Willmann-Bell -1991
- -- Espenak, Fred, and Jean Meeus, “Five-millennium Catalog of Lunar -Eclipses –1900 to +3000”, 2009, p. 18ff., http://eclipse.gsfc.nasa.gov/5MCSE/TP2009-214174.pdf.
- -- Explanatory Supplement of the -Astronomical Almanach, University Science Books, 1992, Mill Valley, CA, p. -265ff.
- -- Morrison, L. V. and F. R. Stephenson, Sun and Planetary System, vol 96,73 eds. W. Fricke, G. Teleki, Reidel, -Dordrecht (1982)
- -- Morrison, L. V., and F.R. Stephenson, “Historical -Values of the Earth’s Clock Error DT -and the Calculation of Eclipses”, JHA xxxv (2004), pp.327-336
- -- Stephenson, F. R., and L. V. Morrison, -"Long-term changes in the rotation of the Earth: 700 BC to AD 1980", Philosophical Transactions of the Royal Society of London, -Series A 313, 47-70 (1984)
- -- Stephenson, F. R., and M. A. Houlden, Atlas of Historical Eclipse Maps, Cambridge U. Press (1986)
- -- Stephenson, F.R. & Morrison, L.V., "Long-Term Fluctuations in -the Earth's Rotation: 700 BC to AD 1990", in: Philosophical Transactions of the Royal Society of London, Ser. A, -351 (1995), 165-202.
- -- Stephenson, F. Richard, Historical -Eclipses and Earth's Rotation, Cambridge U. Press (1997)
- -- For a comprehensive collection of -publications and formulae, see R.H. van Gent at -http://www.phys.uu.nl/~vgent/astro/deltatime.htm.
- -- -
Swiss Ephemeris is written in portable C and the same code is used for -creation of the 32-bit Windows DLL and the link library. All data files are -fully portable between different hardware architectures.
- -To build the DLLs, we use Microsoft Visual C++ version 5.0 (for 32-bit).
- -The DLL has been successfully used in the following programming -environments:
- -Visual C++ 5.0 (sample -code included in the distribution)
- -Visual Basic 5.0 (sample code -and VB declaration file included)
- -Delphi 2 and Delphi 3 (32-bit, declaration file included)
- -As the number of users grows, -our knowledge base about the interface details between programming environments -and the DLL grows. All such information is added to the distributed Swiss -Ephemeris and registered users are informed via an email mailing list.
- -Earlier version up to version 1.61 supported 16-bit Windows programming. -Since then, 16-bit support has been dropped.
- -We give a short overview of the most important functions contained in -the Swiss Ephemeris DLL. The detailed description of the programming interface -is contained in the document swephprg.doc which is -distributed together with the file you are reading.
- -/* planets, moon, asteroids, lunar -nodes, apogees, fictitious bodies */
- -swe_calc();
- -- -
/* fixed stars */
- -swe_fixstar();
- -/* delta t from Julian day number
- -* Ephemeris time (ET) = Universal time (UT) + swe_deltat(UT)*/
- -swe_deltat();
- -- -
/* Julian day number from year, month, -day, hour, */
- -swe_date_conversion ();
- -/* Julian day number from year, month, -day, hour */
- -swe_julday();
- -- -
/* year, month, day, hour from Julian -day number */
- -swe_revjul ();
- -- -
/* UTC to Julian day number */
- -swe_utc_to_jd ();
- -- -
/* Julian day number TT to UTC */
- -swe_jdet_to_utc ();
- -- -
/* Julian day number UT1 to UTC */
- -swe_jdut1_to_utc ();
- -- -
/* utc to time zone or time zone to -utc*/
- -swe_utc_time_zone ();
- -- -
/* get tidal acceleration used in -swe_deltat() */
- -swe_get_tid_acc();
- -- -
/* set tidal acceleration to be used in -swe_deltat() */
- -swe_set_tid_acc();
- -/* set directory path of ephemeris files -*/
- -swe_set_ephe_path();
- -- -
/* set name of JPL ephemeris file */
- -swe_set_jpl_file();
- -- -
/* close Swiss Ephemeris */
- -swe_close();
- -/* sidereal time */
- -swe_sidtime();
- -/* house cusps, ascendant, MC, armc, -vertex */
- -swe_houses();
- -/* coordinate transformation, from -ecliptic to equator or vice-versa. */
- -swe_cotrans();
- -/* coordinate transformation of position -and speed,
- -* from ecliptic to equator or vice-versa*/
- -swe_cotrans_sp();
- -/* get the name of a planet */
- -swe_get_planet_name();
- -/* normalization of any degree number to -the range 0 ... 360 */
- -swe_degnorm();
- -PLACALC, the predecessor of SWISSEPH, 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.
- -/* -normalize argument into interval [0..DEG360]
- -* former function name: csnorm() */
- -swe_csnorm();
- -- -
/* -distance in centisecs p1 - p2 normalized to [0..360[
- -* former function name: difcsn() */
- -swe_difcsn -();
- -- -
/* -distance in degrees * former function -name: difdegn() */
- -swe_difdegn -();
- -- -
/* -distance in centisecs p1 - p2 normalized to [-180..180[
- -* former function name: difcs2n() */
- -swe_difcs2n();
- -- -
/* -distance in degrees
- -* former function name: difdeg2n() */
- -swe_difdeg2n();
- -- -
/* round -second, but at 29.5959 always down
- -* former function name: roundsec() */
- -swe_csroundsec();
- -- -
/* -double to long with rounding, no overflow check
- -* former function name: d2l() */
- -swe_d2l();
- -- -
/* -Monday = 0, ... Sunday = 6
- -* former function name: day_of_week() */
- -swe_day_of_week();
- -- -
/* -centiseconds -> time string
- -* former function name: TimeString() */
- -swe_cs2timestr();
- -- -
/* -centiseconds -> longitude or latitude string
- -* former function name: LonLatString() */
- -swe_cs2lonlatstr();
- -- -
/* centiseconds --> degrees string
- -* former function name: DegreeString() */
- -swe_cs2degstr();
- -- -
Placalc is a planetary calculation module which was made available by -Astrodienst since 1988 to other programmers under a source code license. Placalc -is less well designed, less complete and not as precise as the Swiss Ephemeris -module. However, many developers of astrological software have used it over -many years and like it. Astrodienst has used it internally since 1989 for a -large set of application programs.
- -To simplify the introduction of Swiss Ephemeris in 1997 in Astrodienst's -internal operation, we wrote an interface module which translates all calls to -Placalc functions into Swiss Ephemeris functions, and translates the results -back into the format expected in the Placalc Application Interface (API).
- -This interface (swepcalc.c and swepcalc.h) is part of the source code distribution of Swiss Ephemeris; it is not -contained in the DLL. All new software should be written directly for the -SwissEph API, but porting old Placalc software is convenient and very simple -with the Placalc API.
- -The calculation of the apparent position of a planet involves a -relativistic effect, which is the curvature of space by the gravity field of -the Sun. This can also be described by a semi-classical algorithm, where the -photon travelling from the planet to the observer is deflected in the Newtonian -gravity field of the Sun, where the photon has a non-zero mass arising from its -energy. To get the correct relativistic result, a correction factor 2.0 must be -included in the calculation.
- -A problem arises when a planet disappears behind the solar disk, as seen -from the Earth. Over the whole 6000 year time span of the Swiss Ephemeris, it -happens often.
- -|
- Planet - |
-
- number of passes behind the Sun - |
-
|
- Mercury - |
-
- 1723 - |
-
|
- Venus - |
-
- 456 - |
-
|
- Mars - |
-
- 412 - |
-
|
- Jupiter - |
-
- 793 - |
-
|
- Saturn - |
-
- 428 - |
-
|
- Uranus - |
-
- 1376 - |
-
|
- Neptune - |
-
- 543 - |
-
|
- Pluto - |
-
- 57 - |
-
- -
A typical occultation of a planet by the Solar disk, which has a diameter -of approx. _ degree, has a duration of about 12 hours. For the outer planets it -is mostly the speed of the Earth's movement which determines this duration.
- -Strictly speaking, there is no apparent position of a planet when -it is eclipsed by the Sun. No photon from the planet reaches the observer's eye -on Earth. Should one drop gravitational deflection, but keep aberration and -light-time correction, or should one switch completely from apparent positions -to true positions for occulted planets? In both cases, one would come up with -an ephemeris which contains discontinuities, when at the moment of occultation -at the Solar limb suddenly an effect is switched off.
- -Discontinuities in the ephemeris need to be avoided for several reasons. -On the level of physics, there cannot be a discontinuity. The planet cannot -jump from one position to another. On the level of mathematics, a non-steady -function is a nightmare for computing any derived phenomena from this function, -e.g. the time and duration of an astrological transit over a natal body, -or an aspect of the planet.
- -Nobody seems to have handled this problem before in astronomical -literature. To solve this problem, we have used the following approach: We -replace the Sun, which is totally opaque for electromagnetic waves and not -transparent for the photons coming from a planet behind it, by a transparent -gravity field. This gravity field has the same strength and spatial -distribution as the gravity field of the Sun. For photons from occulted -planets, we compute their path and deflection in this gravity field, and from -this calculation we get reasonable apparent positions also for occulted -planets.
- -The calculation has been carried out with a semi-classical Newtonian -model, which can be expected to give the correct relativistic result when it is -multiplied with a correction factor 2. The mass of the Sun is mostly -concentrated near its center; the outer regions of the Solar sphere have a low -mass density. We used the a mass density distribution from the Solar standard model, -assuming it to have spherical symmetry (our Sun mass distribution m® is from -Michael Stix, The Sun, p. 47). The path of photons through this gravity field -was computed by numerical integration. The application of this model in the -actual ephemeris could then be greatly simplified by deriving an effective -Solar mass which a photon ”sees” when it passes close by or ”through” the Sun. -This effective mass depends only from the closest distance to the Solar center -which a photon reaches when it travels from the occulted planet to the -observer. The dependence of the effective mass from the occulted planet's -distance is so small that it can be neglected for our target precision of 0.001 -arc seconds.
- -For a remote planet just at the edge of the Solar disk the gravity -deflection is about 1.8”, always pointing away from the center of the Sun. This -means that the planet is already slightly behind the Solar disk (with a -diameter of 1800”) when it appears to be at the limb, because the light bends -around the Sun. When the planet now passes on a central path behind the Solar -disk, the virtual gravity deflection we compute increases to 2.57 times the -deflection at the limb, and this maximum is reached at _ of the Solar radius. -Closer to the Solar center, the deflection drops and reaches zero for photons -passing centrally through the Sun's gravity field.
- -We have discussed our approach with Dr. Myles Standish from JPL and here -is his comment (private email to Alois Treindl, 12-Sep-1997):
- -.. it -seems that your approach is
- -entirely -reasonable and can be easily justified as long
- -as you -choose a reasonable model for the density of
- -the -sun. The solution may become more -difficult if an
- -ellipsoidal -sun is considered, but certainly that -is
- -an -additional refinement which can not be crucial.
- -- -
- -
# -====================================
- -# At -the same time a brief introduction into asteroids
- -# -====================================================
- -#
- -# As -of the year 2010, there is no longer any CDROM. All
- -# -parts of Swiss Ephemeris can be downloaded in the download area.
- -#
- -# -Literature:
- -# -Lutz D. Schmadel, Dictionary of Minor Planet Names,
- -# Springer, Berlin, Heidelberg, New York
- -# -Charles T. Kowal, Asteroids. Their Nature and Utilization,
- -# Whiley & Sons, 1996, Chichester, -England
- -#
- -#
- -# -What is an asteroid?
- -# ---------------------
- -#
- -# -Asteroids are small planets. Because there are too many
- -# of -them and because most of them are quite small,
- -# -astronomers did not like to call them "planets", but
- -# -invented names like "asteroid" (Greek "star-like",
- -# -because through telescopes they did not appear as planetary
- -# -discs but as star like points) or "planetoid" (Greek
- -# -"something like a planet"). However they are also often
- -# -called minor planets.
- -# The -minor planets can roughly be divided into two groups.
- -# -There are the inner asteroids, the majority of which
- -# -circles in the space between Mars and Jupiter, and
- -# -there are the outer asteroids, which have their realm
- -# -beyond Neptune. The first group consists of rather
- -# -dense, earth-like material, whereas the Transneptunians
- -# -mainly consist of water ice and frozen gases. Many comets
- -# are -descendants of the "asteroids" (or should one say
- -# -"comets"?) belt beyond Neptune. The first Transneptunian
- -# -objects (except Pluto) were discovered only after 1992
- -# and -none of them has been given a name as yet.
- -#
- -#
- -# The -largest asteroids
- -# ----------------------
- -# -Most asteroids are actually only debris of collisions
- -# of -small planets that formed in the beginning of the
- -# -solar system. Only the largest ones are still more
- -# or -less complete and round planets.
- -- -
1 Ceres # 913 km goddess of -corn and harvest
- -2 Pallas # 523 km goddess of -wisdom, war and liberal arts
- -4 Vesta # 501 km goddess of -the hearth fire
- -10 Hygiea # 429 km goddess of -health
- -511 Davida -# 324 km after an astronomer -David P. Todd
- -704 Interamnia -# 338 km "between -rivers", ancient name of
- -# its discovery place Teramo
- -65 Cybele # 308 km Phrygian -Goddess, = Rhea, wife of Kronos-Saturn
- -52 Europa # 292 km beautiful -mortal woman, mother of Minos by Zeus
- -87 Sylvia # 282 km
- -451 Patientia -# 280 km patience
- -31 Euphrosyne # 270 km one of the -three Graces, benevolence
- -15 Eunomia # 260 km one of the -Hours, order and law
- -324 Bamberga -# 252 km after a city in Bavaria
- -3 Juno # 248 km wife of -Zeus
- -16 Psyche # 248 km -"soul", name of a nymph
- -- -
- -
# -Asteroid families
- -# ------------------
- -# -Most asteroids live in families. There are several kinds
- -# of -families.
- -# - -There are families that are separated from each other
- -# by orbital resonances with Jupiter or other -major planets.
- -# - -Other families, the so-called Hirayama families, are the
- -# relics of asteroids that broke apart long -ago when they
- -# collided with other asteroids.
- -# - -Third, there are the Trojan asteroids that are caught
- -# in regions 60 degrees ahead or behind a -major planet
- -# (Jupiter or Mars) by the combined -gravitational forces
- -# of this planet and the Sun.
- -- -
# -Near Earth groups:
- -# -------------------
- -#
- -# -Aten family: they cross Earth; mean distance from Sun is less than Earth
- -- -
2062 -Aten # an Egyptian Sun god
- -2100 -Ra-Shalom # Ra is an Egyptian Sun -god, Shalom is Hebrew "peace"
- -# was discovered during Camp -David mid-east peace conference
- -- -
# -Apollo family: they cross Earth; mean distance is greater than Earth
- -- -
1862 -Apollo # Greek Sun god
- -1566 -Icarus # wanted to fly to the sky, -fell into the ocean
- -# Icarus crosses Mercury, -Venus, Earth, and Mars
- -# and has his perihelion -very close to the Sun
- -3200 -Phaethon # wanted to drive the solar -chariot, crashed in flames
- -# Phaethon crosses Mercury, Venus, Earth, and Mars
- -# and has his perihelion -very close to the Sun
- -- -
# -Amor family: they cross Mars, approach Earth
- -- -
1221 -Amor # Roman love god
- -433 Eros -# Greek love god
- -- -
# Mars -Trojans:
- -# --------------
- -- -
5261 -Eureka a mars Trojan
- -- -
# -Main belt families:
- -# --------------------
- -- -
# -Hungarias: asteroid group at 1.95 AU
- -- -
434 Hungaria -# after Hungary
- -- -
# -Floras: Hirayama family at 2.2 AU
- -- -
8 Flora # goddess of flowers
- -- -
# -Phocaeas: asteroid group at 2.36 AU
- -- -
25 Phocaea # maritime town in Ionia
- -- -
# -Koronis family: Hirayama family at 2.88 AU
- -- -
158 Koronis -# mother of Asklepios by Apollo
- -- -
# Eos -family: Hirayama family at 3.02 AU
- -- -
221 Eos -# goddess of dawn
- -- -
# Themis -family: Hirayama family at 3.13 AU
- -- -
24 Themis # goddess of justice
- -- -
# -Hildas: asteroid belt at 4.0 AU, in 3:2 resonance with Jupiter
- -# ---------------------------------------------------------------
- -# The -Hildas have fairly eccentric orbits and, at their
- -# -aphelion, are very close to the orbit of Jupiter. However,
- -# at -those times, Jupiter is ALWAYS somewhere else. As
- -# -Jupiter approaches, the Hilda asteroids move towards
- -# -their perihelion points.
- -- -
153 Hilda -# female first name, means "heroine"
- -- -
# a -single asteroid at 4.26 AU, in 4:3 resonance with Jupiter
- -279 Thule -# mythical center of Magic in the uttermost north
- -- -
# -Jupiter Trojans:
- -# -----------------
- -# -Only the Trojans behind Jupiter are actually named after Trojan heroes,
- -# whereas -the "Trojans" ahead of Jupiter are named after Greek heroes that
- -# -participated in the Trojan war. However there have been made some mistakes,
- -# -i.e. there are some Trojan "spies" in the Greek army and some Greek -"spies"
- -# in -the Trojan army.
- -- -
# Greeks -ahead of Jupiter:
- -624 Hector -# Trojan "spy" in the Greek army, by far the greatest
- -# Trojan hero and the -greatest Trojan asteroid
- -588 Achilles -# slayer of Hector
- -1143 -Odysseus
- -- -
# -Trojans behind Jupiter:
- -1172 -Äneas
- -3317 -Paris
- -884 Priamus
- -- -
# -Jupiter-crossing asteroids:
- -# ----------------------------
- -- -
3552 -Don Quixote # perihelion near Mars, -aphelion beyond Jupiter;
- -# you know Don Quixote, -don't you?
- -944 Hidalgo -# perihelion near Mars, aphelion near Saturn;
- -# after a Mexican national -hero
- -5335 -Damocles # perihelion near Mars, -aphelion near Uranus;
- -# the man sitting below a -sword suspended by a thread
- -- -
# -Centaurs:
- -# ----------
- -- -
2060 -Chiron # perihelion near Saturn, -aphelion near Uranus
- -# educator of heros, -specialist in healing and war arts
- -5145 -Pholus # perihelion near Saturn, -aphelion near Neptune
- -# seer of the gods, keeper -of the wine of the Centaurs
- -7066 -Nessus # perihelion near Saturn, aphelion in Pluto's mean distance
- -# ferryman, killed by -Hercules, kills Hercules
- -- -
# -Plutinos:
- -# ----------
- -# -These are objects with periods similar to Pluto, i.e. objects
- -# -that resonate with the Neptune period in a 3:2 ratio.
- -# -There are no Plutinos included in Swiss Ephemeris so far, but
- -# -PLUTO himself is considered to be a Plutino type asteroid!
- -- -
# -Cubewanos:
- -# -----------
- -# -These are non-Plutiono objects with periods greater than Pluto.
- -# The -word "Cubewano" is derived from the preliminary designation
- -# of -the first-discovered Cubewano: 1992 QB1
- -- -
20001 -1992 QB1 # will be given the name of -a creation deity
- -# (fictitious catalogue number -20001!)
- -- -
# -other Transplutonians:
- -- -
20001 -1996 TL66 # mean solar distance 85 AU, -period 780 years
- -- -
# -Asteroids that challenge hypothetical planets astrology
- -# --------------------------------------------------------
- -- -
42 Isis # not identical with "Isis-Transpluto"
- -# Egyptian lunar goddess
- -763 Cupido -# different from Witte's Cupido
- -# Roman god of sexual desire
- -4341 -Poseidon # not identical with -Witte's Poseidon
- -# Greek name of Neptune
- -4464 -Vulcano # compare Witte's Vulkanus
- -# and intramercurian hypothetical Vulcanus
- -# Roman fire god
- -5731 -Zeus # different from Witte's -Zeus
- -# Greek name of Jupiter
- -1862 -Apollo # different from Witte's -Apollon
- -# Greek god of the Sun
- -398 Admete -# compare Witte's Admetos
- -# "the untamed -one", daughter of Eurystheus
- -- -
# -Asteroids that challenge Dark Moon astrology
- -# ---------------------------------------------
- -- -
1181 -Lilith # not identical with Dark -Moon 'Lilith'
- -# first evil wife of Adam
- -3753 -Cruithne # often called the -"second moon" of earth;
- -# actually not a moon, but -an asteroid that
- -# orbits around the sun in a -certain resonance
- -# with the earth.
- -# After the first Celtic -group to come to the British Isles.
- -- -
# -Also try the two points 60 degrees in front of and behind the
- -# -Moon, the so called Lagrange points, where the combined
- -# -gravitational forces of the earth and the moon might imprison
- -# -rocks and stones. There have been some photographic hints
- -# -that there are clouds of such material around these points.
- -# -They are called the Kordylewski clouds.
- -- -
- -
# -other asteroids
- -# ----------------
- -- -
5 Astraea # a goddess of justice
- -6 Hebe # goddess of youth
- -7 Iris # rainbow goddess, messenger of the gods
- -8 Flora # goddess of flowers and gardens
- -9 Metis # goddess of prudence
- -10 Hygiea # goddess of health
- -14 Irene # goddess of peace
- -16 Psyche # "soul", a nymph
- -19 Fortuna # goddess of fortune
- -- -
# -Some frequent names:
- -# ---------------------
- -# -There are thousands of female first names in the asteroids list.
- -# -Very interesting for relationship charts!
- -- -
78 Diana
- -170 Maria
- -234 Barbara
- -375 Ursula -
- -412 Elisabetha
- -542 Susanna
- -- -
# -Wisdom asteroids:
- -# ------------------
- -- -
134 Sophrosyne -# equanimity, healthy mind and impartiality
- -197 Arete -# virtue
- -227 Philosophia
- -251 Sophia -# wisdom (Greek)
- -259 Aletheia -# truth
- -275 Sapientia -# wisdom (Latin)
- -- -
# Love -asteroids:
- -# ----------------
- -- -
344 Desiderata
- -433 Eros
- -499 Venusia
- -763 Cupido
- -1221 -Amor
- -1387 -Kama # Indian god of sexual -desire
- -1388 -Aphrodite # Greek love Goddess
- -1389 -Onnie # what is this, after 1387 -and 1388 ?
- -1390 -Abastumani # and this?
- -- -
# The -Nine Muses
- -# ---------------
- -- -
18 Melpomene Muse of tragedy
- -22 Kalliope Muse of heroic poetry
- -23 Thalia - Muse of comedy
- -27 Euterpe Muse of music and lyric poetry
- -30 Urania Muse of astronomy and astrology
- -33 Polyhymnia Muse of singing and rhetoric
- -62 Erato Muse of song and dance
- -81 Terpsichore Muse of choral dance and song
- -84 Klio Muse of history
- -- -
# -Money and big busyness asteroids
- -# ---------------------------------
- -- -
19 Fortuna # goddess of fortune
- -904 Rockefellia
- -1338 -Duponta
- -3652 -Soros
- -- -
# -Beatles asteroids:
- -# -------------------
- -- -
4147 -Lennon
- -4148 -McCartney
- -4149 -Harrison
- -4150 Starr
- -- -
# Composer -Asteroids:
- -# --------------------
- -- -
2055 -Dvorak
- -1814 -Bach
- -1815 -Beethoven
- -1034 -Mozartia
- -3941 -Haydn
- -And -there are many more...
- -- -
# -Astrodienst asteroids:
- -# -----------------------
- -- -
# -programmers group:
- -3045 -Alois
- -2396 -Kochi
- -2968 -Iliya # Alois' dog
- -- -
# -artists group:
- -412 Elisabetha
- -- -
# -production family:
- -612 Veronika
- -1376 -Michelle
- -1343 -Nicole
- -1716 -Peter
- -- -
# -children group
- -105 -Artemis
- -1181 -Lilith
- -- -
# -special interest group
- -564 -Dudu
- -349 -Dembowska
- -484 -Pittsburghia
- -- -
# By -the year 1997, the statistics of asteroid names looked as follows:
- -- -
# Men -(mostly family names) 2551
- -# -Astronomers 1147
- -# -Women (mostly first names) 684
- -# -Mythological terms 542
- -# -Cities, harbours buildings 497
- -# -Scientists (no astronomers) 493
- -# -Relatives of asteroid discoverers 277
- -# -Writers 249
- -# -Countries, provinces, islands 246
- -# -Amateur astronomers 209
- -# -Historical, political figures 176
- -# -Composers, musicians, dancers 157
- -# -Figures from literature, operas 145
- -# -Rivers, seas, mountains 135
- -# -Institutes, observatories 116
- -# -Painters, sculptors 101
- -# Plants, trees, animals 63
- -