Ephemerides 2.7 Service Pack 1.2

- fixed a bug with the seasons;
- added the greatest defect of illumination for all solar system bodies;
- updated EN-FR-NL-IT languages for the new feature.

Ephemerides 2.8



changes:
- removed the OpenGl marker due to its incompatibility with the splitted views;
now the marker does use a tailored version of the Jogad's technique already developed for the "distance_calc" plugin;
- fixed the Equation of Time within the proper range.

added:
- day of the week;
- day of the year;

Ephemerides 2.9

FIXES:
- fix a bug with the Mercury/Venus conj/opp. months string;
- fix a bug with the markers' behaviour between Ephemerides and "distance_calc" plugins;
- fix a bug with the italian language;
- fix a no-sense link between modules;

CHANGES:
- code rationals, improved performances;
- restored signs for the declinations of the Sun and Earth accordingly with the VSOP87 theory (Celestia's default);
- average abs. magnitude and slope parameter for asteroids and KBO is now sampled upon the complete MPCORB database;
- set the airmass at the ground to its default value of 38.000 (thirtyeight, next is the "infinite and beyond");
- restored the Constellations for all objects;
- moved the "Ecliptic:" item from Sol to Earth;
- button 1 returns to home even when out of the solar system; other buttons will deactivate the markers, if any;

ADD;
- new button/display for objects phenomena. This avoids to drop down length texts on screen;
- general accumulated precession from J2000.0; year before J2000 gets negative numbers (Laskar, 1986);
- perihelion/aphelion and time/distance for the Earth and main Solar System planets. For this latters is assumed
unperturbed elliptical orbits. Accuracy is decreasing from days to year for Mars to Neptune.
- time of the stations; station1 (start retrograde motion), station2 (resume direct motion) for planets Mercury to Saturn;
- degrees' sexagesimal/decimal format option;
- quadrants for planet visibility's azimuth, verbose mode (i.e: "[WNW]"; or "[SE]");
- daily insolation at a given point on the Earth;
- solar activity and polar field status for Sol;
- position angle of the bright limb for all Solar System objects;
- solar and lunar eclipses event catcher;
- update EN-FR-NL-IT languages for the new features;

NOTE:
The real time daily insolation account for the average insolation per latitude measured against the mean longitude (to say, at noon); it shows the change of the solar irradiation accordingly with the orbital path of the Earth (seasons), where the high latitudes receives more irradiation as long as the relevant emispheres are oriented. Because there is no insolation at night, its value drops abruply to zero ("n.a.") once the terminator line is crossed. The variations of the insolation for sunrise/sunset angles are not calculated since it is a mean daily value.

The number of the solar activity against time and its polar field status are the theoretical, yearly accurate, one; there is no way to know by mean of equations the exact moment of the appareance of the first sunspot carrying the new cycle, nor is predictable the precise date of the Sun's polar field inversion unless measured through ground-based and orbital instruments. This latter phenomenon can persist several months in a "hybrid" state before to be definitely accomplished in one verse or in the other.

Ephemerides 2.9 Service Pack 1

This fix a with the eclipses.

i take it it was one of those " How the bleep did i miss that oops / bug "

Ephemerides 2.9 Service Pack 1.1

- Fix the wrong LUA module for constellations mistakenly packed yet with 1875 epoch;
The reduction to equinox J2000.0 has been performed with Perl. Below is the part of used code concerning astrometrics:



- NL language with the constellations in dutch names (Marco Klunder's request)



@John:
yes, a hard brain, a brain dead can hit the wall

Careful now...
You're using MY name in vain... Hee, hee...

Thanks, Brain-Dead Bob

hi hi,

you guys are GREAT!

Fridger

Ephemerides 3.0

CHANGES:
-- IAU 1980 theory of nutation -> IAU 2000A_R06 and resolutions P03. Table from IERS convention 2010 <ftp.tai.bipm.org>. TDB time;
- Earth rotation angle;
- Sidereal time and Equation of Time;

_________________
Never at rest.

Ephemerides 3.1

FIXES:
- Fix a bug in decimal degrees mode;

CHANGES:
- Conformed planets/moons Central Meridian (C.M.) between VSOP87 theory and NAIF SPICE (IAU tables <ftp.imcce.fr>);
- assested the ephemerides for Pluto's system;

ADD:
- option to set or not the SPICE kernel; this flips the declinations of the Earth and of the Sol which returns inverted in Celestia with respect to VSOP87 theory;
- System I, II, III for Jupiter's Central Meridian; all the remains gas-giants does use System III (table above);
- Central Meridian for several moons/minormoons;
- longitude of the Sol and of the Earth for all Solar System objects;
- update EN-FR-NL-IT languages for the new features;

_________________
Never at rest.

Errata Corrige:
option to set or not the SPICE kernel; this flips the declinations of the Earth and of the Sol which returns inverted in Celestia with respect to VSOP87 theory;

read:
option to set or not the SPICE kernel; this flips the declinations of the Earth and of the Sol for retrograde planets which returns inverted in Celestia with respect to VSOP87 theory;

_________________
Never at rest.

Ephemerides 3.1 Service Pack 1.0

SPICE makes me crazy... Below there is the zip file containing the "ephemLib.lua" file. It fix a wong code sequence for the longitudes...

BUT...

Venus VSOP87 checked against JPL HORIZONS ephemerides (geocentric mode).

Now with SPICE kernel:

meanwhile the values matches, the longitudinal grid doesn't match
--------------------------------------------------------------------------
Uranus VSOP87 checked against JPL HORIZONS ephemerides (geocentric mode).

Now with SPICE kernel:

meanwhile the values matches, the whole grid doesn't match
----------------------------------------------------------------------------
Pluto VSOP87 checked against JPL HORIZONS ephemerides (geocentric mode).

It does't match with HORIZONS but match with the grid
Now with SPICE kernel:

it match with HORIZONS but doesn't match with the whole grid.

I do not have clues here; because whether the longitudes could be subtracted from 360 degrees in VSOP87 mode, meanwhile the values could match, the Celestia's grid will not match. For not tell about declinations.

_________________
Never at rest.

the spice VS vsop
is different , but not that different

now spice orbits and body rotation ARE not the same as the default celestia ( vsop87 )

things are relative ( mostly but not always) to the ecliptic
EclipticJ2000
both use this for the orbit but spice normally uses SSB and not the sun center ( there are exceptions)
but the ROTATIONAL references are to the EclipticJ2000( of the parent) in SPICE but are EquatorJ2000 ( of the parent) in vsop87

for a planet the difference is rather small but NOT for a moon .Moons get turned on their side
fortunately this is not as bad as having ones head smashed by a gold brick wrapped in a twist of lemon .....

but might take a bit of time to sink in .
sit back for a few and hopefully that light bulb will go "bing"
( hopefully with no "vuba vuba vuba "bing " " , but with this weather one never knows if it will "rain for ten thousand days and drown then right out" )
[ that vinyl LP was playing earlier today , B.Cosby ]

notice there are a bunch of should and maybes and "exceptions"

planets and moons normally are relative to the barycenter of the parent ( but do not have to be )
the major bodies ( except for MARS ) also have the orbits to the geographical center of the parent body
( for mars the bary and center are only 30 cm different YES 30 centimeters!!! so the center is used

small bodies though are to the SUN center only for the orbits
there rotational ?????? that is up in the air

_________________
"I don't pitch Linux to my friends, I let Microsoft do that for me."
Using OpenSUSE 42.1 & Scientific Linux 6.7

Well... Then I wonder what is the goal of using SPICE within the Celestia framework if the framework itself is not fitted to use SPICE. To say: if SPICE are true, the Celestia's "reference marks" are false onto SPICE kernel. Grids and vectors themselves must accomplish different rotational matrix with respect to VSOP87. If on Uranus the declination of Sun is toward the north pole in both VSOP87 and SPICE (aside the longitude), the planetographic grid cannot show the south direction. Because there is no way to tell SPICE to change its behaviour being "packed" in another fashion, using SPICE in this manner is questionable because one can't discern how the real things follows the 3D simulation. At the state of the art, SPICE makes fictional some Celestia parts more than noise generated nebulae makes scientific others; e.a. their positions and dimensions.

_________________
Never at rest.

ADVERTISEMENT...

Because the next version of the Ephemerides will show the R.A. for the equinox of the date along with the usual "unprecessed" J2000.0 equinox returned by the "celutil.lua" file of both lua_plugins/lua_edu_tools, the adding of the so-called "equinox solution" (the "equation of the origins" + the "equation of the equinoxes", the accumulated precession in right ascension) to this latter will be referred to the new adopted value of 84381.406 arcseconds for the obliquity of the ecliptic at J2000.0. By the way, while this is also the value adopted by Celestia's internal precession (not related with the "celutil.lua" outputs, whose vectors' matrix doesn't account for), the "celutil.lua" file sets as obliquity costant the "old" value of 84381.448 arcseconds; that is not the value on which the adopted IAU "equinox solution" is based upon. It should be best to change it accordingly (whether already not done); in doing so do replace within "celutil.lua" the string:

with:

J2000Obliquity = math.rad(84381.406 / 3600.0)

Because "celutil.lua" is not part exclusively of the Ephemerides, all LUA plugins based upon such library will be conformed as much as possible with the new IAU resolutions, at least for the J2000.0 equinox equatorial/celestial coordinates only.

EDIT LATER:
in red corrected the typo about the value of the obliquity of the ecliptic pointed out by Marco Klunder. The Ephemeride plugin is NOT affected by the typo. I apologize for the inconvenience.

_________________
Never at rest.