¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io

Re: XEphem 4.2.0 has been released

 

¿ªÔÆÌåÓý

Hi Brandon and Elwood,

I'd like to join in on the chorus of people thanking you for keeping this software package alive. I had recently reformatted my computer, and after seeing this release notification, I re-installed my original 3.7.7 purchased version (that includes HST GSC) and then I downloaded and compiled 4.2.0 on my Debian 12 system and updated my executable. It works flawlessly!

Thank you so much!

Rick from Toronto Canada


Re: XEphem 4.2.0 has been released

 

Thank you Brandon and Elwood! I compiled and installed this new version of xephem the same day was released. From 1996 I have been doing this with every version. The new 4.2.0 release comes to energize our spirit and confidence in the solidity and dedication that Xephem represents. I compiled it on my debian 12 and macOS Ventura.

Greeting from New York City.

Emilio

On Feb 16, 2024, at 8:52 AM, Joe Hartley <jh@...> wrote:

On Tue, 13 Feb 2024 12:45:40 -0500
"Brandon Rhodes" <brandon@...> wrote:

I have just released XEphem 4.2.0.
Thanks for keeping this venerable software alive! It was one of the
first software packatges I compiled for X Windows back in 1991 or so
on a Sun SPARC workstation and it's been on my Unix and Linux home
systems ever since.

--
======================================================================
Joe Hartley - UNIX/network Consultant - jh@...
Without deviation from the norm, "progress" is not possible. - FZappa





Re: XEphem 4.2.0 has been released

 

On Tue, 13 Feb 2024 12:45:40 -0500
"Brandon Rhodes" <brandon@...> wrote:

I have just released XEphem 4.2.0.
Thanks for keeping this venerable software alive! It was one of the
first software packatges I compiled for X Windows back in 1991 or so
on a Sun SPARC workstation and it's been on my Unix and Linux home
systems ever since.

--
======================================================================
Joe Hartley - UNIX/network Consultant - jh@...
Without deviation from the norm, "progress" is not possible. - FZappa


Re: XEphem 4.2.0 has been released

 

Thank you Brandon and Elwood!, this new release brings a new life for all of us!
I will install on my FreeBSD 14.0 Box right away!

Greetings from M¨¦rida, Yucat¨¢n, M¨¦xico, The Maya Land!

Eric.

On Tuesday, February 13, 2024 at 11:46:20 AM CST, Brandon Rhodes <brandon@...> wrote:


I have just released XEphem 4.2.0.

The change log:

  • Elwood himself has contributed a new option that lets you switch XEphem from giving your telescope J2000 coordinates to giving it equinox-of-date coordinates.
  • Sky View: the mouse wheel now zooms the view in and out.
  • Sky View: DSS image download has been fixed by upgrading to HTTPS, and the window should no longer awkwardly resize once the image arrives.
  • Data ? Download: added the URL of the Celestrak ¡°visual.txt¡± file.
  • Data ? Download: replaced ¡°¡± with modern HTTPS.
  • Data ? Field Stars: Fran?ois Meyer added support for the ucac5 catalog.
  • The precession formula has been updated to the one from the 2000 Astronomical Almanac.
  • A couple of compilation problems on modern Mac machines have been fixed.
  • XEphem now uses more modern SSL setup routines if the code detects it¡¯s being compiled against OpenSSL ¡Ý1.1.
  • Closing the INDI window with your window manager¡¯s ¡°Close¡± button no longer crashes XEphem.
  • All references to ¡°¡± have been changed to their new hostname ¡°¡±.
  • A few other small fixes.

I apologize for allowing so much time to pass since the previous release! Over 2022 there were several email threads that were gradually working on the problem of how to compile XEphem successfully on macOS. Unfortunately, I decided to wait to see if they would reach a perfect answer for all versions of macOS, and wound up waiting far too long ¡ª they all petered out without my understanding which versions of macOS needed what. From now on I will instead focus on making more frequent XEphem releases, and as macOS folks report on their various troubles, we can hopefully iterate towards a Makefile that works for everyone.

Now that we have a fresh release to work from, I¡¯ll plan to go back through the open issues and pull requests and make comments and updates where it¡¯s warranted. Enjoy!


Re: XEphem 4.2.0 has been released

 

Thank you very much for the new release, Brandon!

And many congratulations on the new version. :)

--
With best regards, Alexander


Re: XEphem 4.2.0 has been released

 

Thanks so much, Brandon.

Bernie
NASA/IRTF

On 2/13/24 08:47, Elwood Downey wrote:
Many thanks to Brandon for his excellent stewardship and to everyone for their valuable contributions. Long live XEphem!

Elwood

On Tue, Feb 13, 2024 at 10:46?AM Brandon Rhodes <brandon@...> wrote:

I have just released XEphem 4.2.0.



The change log:

* Elwood himself has contributed a new option that lets you
switch XEphem from giving your telescope J2000 coordinates to
giving it equinox-of-date coordinates.
* Sky View: the mouse wheel now zooms the view in and out.
* Sky View: DSS image download has been fixed by upgrading to
HTTPS, and the window should no longer awkwardly resize once
the image arrives.
* Data ? Download: added the URL of the Celestrak ¡°visual.txt¡± file.
* Data ? Download: replaced ¡°ftp.lowell.edu
<>¡± with modern HTTPS.
* Data ? Field Stars: Fran?ois Meyer added support for the ucac5
catalog.
* The precession formula has been updated to the one from the
2000 Astronomical Almanac.
* A couple of compilation problems on modern Mac machines have
been fixed.
* XEphem now uses more modern SSL setup routines if the code
detects it¡¯s being compiled against OpenSSL ¡Ý1.1.
* Closing the INDI window with your window manager¡¯s ¡°Close¡±
button no longer crashes XEphem.
* All references to ¡°celestrak.com <>¡± have
been changed to their new hostname ¡°celestrak.org
<&²µ³Ù;¡±.
* A few other small fixes.

I apologize for allowing so much time to pass since the previous
release! Over 2022 there were several email threads that were
gradually working on the problem of how to compile XEphem
successfully on macOS. Unfortunately, I decided to wait to see if
they would reach a perfect answer for all versions of macOS, and
wound up waiting far too long ¡ª they all petered out without my
understanding which versions of macOS needed what. From now on I
will instead focus on making more frequent XEphem releases, and as
macOS folks report on their various troubles, we can hopefully
iterate towards a |Makefile| that works for everyone.

Now that we have a fresh release to work from, I¡¯ll plan to go
back through the open issues and pull requests and make comments
and updates where it¡¯s warranted. Enjoy!


Re: XEphem 4.2.0 has been released

 

Thanks Brandon,

It's nice to see official releases again for this great software.
Your efforts are appreciated!

Don

On Tue Feb 13 12:45:40 2024 brandon@... (Brandon Rhodes) wrote:

I have just released XEphem 4.2.0.



Re: XEphem 4.2.0 has been released

 

Many thanks to Brandon for his excellent stewardship and to everyone for their valuable contributions. Long live XEphem!

Elwood

On Tue, Feb 13, 2024 at 10:46?AM Brandon Rhodes <brandon@...> wrote:

I have just released XEphem 4.2.0.

The change log:

  • Elwood himself has contributed a new option that lets you switch XEphem from giving your telescope J2000 coordinates to giving it equinox-of-date coordinates.
  • Sky View: the mouse wheel now zooms the view in and out.
  • Sky View: DSS image download has been fixed by upgrading to HTTPS, and the window should no longer awkwardly resize once the image arrives.
  • Data ? Download: added the URL of the Celestrak ¡°visual.txt¡± file.
  • Data ? Download: replaced ¡°¡± with modern HTTPS.
  • Data ? Field Stars: Fran?ois Meyer added support for the ucac5 catalog.
  • The precession formula has been updated to the one from the 2000 Astronomical Almanac.
  • A couple of compilation problems on modern Mac machines have been fixed.
  • XEphem now uses more modern SSL setup routines if the code detects it¡¯s being compiled against OpenSSL ¡Ý1.1.
  • Closing the INDI window with your window manager¡¯s ¡°Close¡± button no longer crashes XEphem.
  • All references to ¡°¡± have been changed to their new hostname ¡°¡±.
  • A few other small fixes.

I apologize for allowing so much time to pass since the previous release! Over 2022 there were several email threads that were gradually working on the problem of how to compile XEphem successfully on macOS. Unfortunately, I decided to wait to see if they would reach a perfect answer for all versions of macOS, and wound up waiting far too long ¡ª they all petered out without my understanding which versions of macOS needed what. From now on I will instead focus on making more frequent XEphem releases, and as macOS folks report on their various troubles, we can hopefully iterate towards a Makefile that works for everyone.

Now that we have a fresh release to work from, I¡¯ll plan to go back through the open issues and pull requests and make comments and updates where it¡¯s warranted. Enjoy!


XEphem 4.2.0 has been released

 

I have just released XEphem 4.2.0.

The change log:

  • Elwood himself has contributed a new option that lets you switch XEphem from giving your telescope J2000 coordinates to giving it equinox-of-date coordinates.
  • Sky View: the mouse wheel now zooms the view in and out.
  • Sky View: DSS image download has been fixed by upgrading to HTTPS, and the window should no longer awkwardly resize once the image arrives.
  • Data ? Download: added the URL of the Celestrak ¡°visual.txt¡± file.
  • Data ? Download: replaced ¡°¡± with modern HTTPS.
  • Data ? Field Stars: Fran?ois Meyer added support for the ucac5 catalog.
  • The precession formula has been updated to the one from the 2000 Astronomical Almanac.
  • A couple of compilation problems on modern Mac machines have been fixed.
  • XEphem now uses more modern SSL setup routines if the code detects it¡¯s being compiled against OpenSSL ¡Ý1.1.
  • Closing the INDI window with your window manager¡¯s ¡°Close¡± button no longer crashes XEphem.
  • All references to ¡°¡± have been changed to their new hostname ¡°¡±.
  • A few other small fixes.

I apologize for allowing so much time to pass since the previous release! Over 2022 there were several email threads that were gradually working on the problem of how to compile XEphem successfully on macOS. Unfortunately, I decided to wait to see if they would reach a perfect answer for all versions of macOS, and wound up waiting far too long ¡ª they all petered out without my understanding which versions of macOS needed what. From now on I will instead focus on making more frequent XEphem releases, and as macOS folks report on their various troubles, we can hopefully iterate towards a Makefile that works for everyone.

Now that we have a fresh release to work from, I¡¯ll plan to go back through the open issues and pull requests and make comments and updates where it¡¯s warranted. Enjoy!


Re: Estimating Mars orbital period from simulated ground-based observations?

 

Dear Elio,

Thank you again for your advice!

Yours,
Maxime

Le 17/03/2023 ¨¤ 09:38, Elio Fabri a ¨¦crit?:

I agree with you. I have not xephem installed and cannot verify, but apparently EcLong is what I named geocentric ecliptic longitude.
Of course EcLong is more strictly related with observations made from Earth, whereas HeLong is more simple geometrically and kinematically but not directly observable.

> Using only one ¡°revolution¡± (and not ten as you advice), I already get
> a fair estimate of 699 days!
My example of ten revolutions was just to make clear what I meant by average.
I think you were lucky. I made no computation but expect that at other oppositions you could find differences of several days.
Of course, much also depends on how much time you can spend with your students on the subject.
Greetings
--
Maxime GOMMEAUX, ma?tre de conf¨¦rences
- Affiliation:
Universit¨¦ de Reims Champagne-Ardenne, UFR Sciences,
D¨¦partement des sciences de la Terre
Laboratoire GEGENAA, EA 3795
- Adresse de visite ou postale:
CREA, 2 esplanade Roland Garros, Bureau NE-401
F-51100 Reims (GPS: 49.2385¡ãN; 4.0628¡ãE)

R¨¦ception: Lu-Ve 08:30-12:15 et 13:30-17:30 (sauf Ve: 13:30-17:00)
- T¨¦l: +33 3 26 77 36 83
-


Re: Estimating Mars orbital period from simulated ground-based observations?

 

On 3/16/23 10:07 AM, Maxime GOMMEAUX wrote:
I think the positions that I am searching for are defined by HeLong(Earth)=HeLong(Mars) [the value for the Earth being displayed in the Sun line in Xephem Data table] or EcLong(Mars)=Eclong(Sun)+/-180.
I agree with you. I have not xephem installed and cannot verify, but apparently EcLong is what I named geocentric ecliptic longitude.
Of course EcLong is more strictly related with observations made from Earth, whereas HeLong is more simple geometrically and kinematically but not directly observable.

Using only one ¡°revolution¡± (and not ten as you advice), I already get
a fair estimate of 699 days!
My example of ten revolutions was just to make clear what I meant by average.
I think you were lucky. I made no computation but expect that at other oppositions you could find differences of several days.
Of course, much also depends on how much time you can spend with your students on the subject.

Greetings
--
Elio Fabri


Re: Estimating Mars orbital period from simulated ground-based observations?

 

Dear Elio,

Thank you for putting me on the right track!

I can't see on XEphem the exact "geocentric longitude" that you mention but in Data Table, I can display the heliocentric latitude/longitude (HeLat/HeLong) as well as the ecliptic latitude/longitude (EcLat/EcLong).

I think the positions that I am searching for are defined by HeLong(Earth)=HeLong(Mars) [the value for the Earth being displayed in the Sun line in Xephem Data table] or EcLong(Mars)=Eclong(Sun)+/-180.

Searching further, I also noticed the marker for the anti-solar point in Sky view, to which I had never paid attention before¡­ It seems to me that I could define the opposition as the time the anti-solar point and Mars are closest. Am I correct?

Using only one ¡°revolution¡± (and not ten as you advice), I already get a fair estimate of 699 days!

I will search further to try and find a way to use only ¡°ground-based observations¡±, if possible (because the anti-solar point is calculated rather than visible ¡°in real life¡±, as are the HeLong or EcLong).

Thank you again!
Maxime

Le 15/03/2023 15:30, Elio Fabri a ¨¦crit?:
On 3/15/23 11:27 AM, Maxime GOMMEAUX wrote:
I would like to have my Bachelor students estimate the orbital period of Mars using only data from XEphem-simulated ground-based observations. I mean, from Sky view, from the Data table... and of course not from the Solar system view.
I have not being using xephem for several years, but yours is mainly
an astronomy question. So, I hope I'm able to give you some advice.
The data you should look for are geocentric ecliptic longitudes of Sun
and Mars. The opposition is when those longitudes differ by 180¡ã.
A Mars synodic year is the time interval between two consecutive
oppositions - it is about two terrestrial years.
Since Mars' orbit has a notable eccentricity, you must expect those
intervals are not constant, but fluctuate from one opposition to
another. So in order to get a reliable mean synodic year an average
must be taken over a series of oppositions.
In other words, you take the interval between one opposition and - say
- the tenth following it. Dividing 10 into that interval you get a
mean synodic year over 10 periods.
Once a mean synodic year is obtained, it's a simple matter to get
Mars' sidereal year. The formula is:
1/Tsid(M) = 1/Tsid(E) - 1/Tsyn(M)
where
Tsid(M) = Mars' sidereal period
Tsid(E) = Earth's sidereal period
Tsyn(M) = Mars' synodic period.
I hope this helps. Greetings
--
--
Maxime GOMMEAUX, ma?tre de conf¨¦rences
- Affiliation:
Universit¨¦ de Reims Champagne-Ardenne, UFR Sciences,
D¨¦partement des sciences de la Terre
Laboratoire GEGENAA, EA 3795
- Adresse de visite ou postale:
CREA, 2 esplanade Roland Garros
F-51100 Reims (GPS: N 49.2385; E 4.0628)
- T¨¦l: +33 3 26 77 36 83
-


Re: Estimating Mars orbital period from simulated ground-based observations?

 

On 3/15/23 11:27 AM, Maxime GOMMEAUX wrote:
I would like to have my Bachelor students estimate the orbital period
of Mars using only data from XEphem-simulated ground-based observations. I mean, from Sky view, from the Data table... and of course not from the Solar system view.
I have not being using xephem for several years, but yours is mainly an astronomy question. So, I hope I'm able to give you some advice.
The data you should look for are geocentric ecliptic longitudes of Sun and Mars. The opposition is when those longitudes differ by 180¡ã.
A Mars synodic year is the time interval between two consecutive oppositions - it is about two terrestrial years.

Since Mars' orbit has a notable eccentricity, you must expect those intervals are not constant, but fluctuate from one opposition to another. So in order to get a reliable mean synodic year an average must be taken over a series of oppositions.
In other words, you take the interval between one opposition and - say - the tenth following it. Dividing 10 into that interval you get a mean synodic year over 10 periods.

Once a mean synodic year is obtained, it's a simple matter to get Mars' sidereal year. The formula is:
1/Tsid(M) = 1/Tsid(E) - 1/Tsyn(M)
where
Tsid(M) = Mars' sidereal period
Tsid(E) = Earth's sidereal period
Tsyn(M) = Mars' synodic period.

I hope this helps. Greetings
--
--
Elio Fabri


Estimating Mars orbital period from simulated ground-based observations?

 

Dear friends of XEphem,

I would like to have my Bachelor students estimate the orbital period of Mars using only data from XEphem-simulated ground-based observations. I mean, from Sky view, from the Data table... and of course not from the Solar system view. I feel there should be a way to do this by estimating the interval between two dates at which the Sun, Earth and Mars are aligned but I am not sure how to define this configuration from XEphem data. Could I simply select one "fixed star" of the ecliptic plane and wait for Mars to come again to this position as seen from Earth?

A rough estimate would be sufficient but a precise method is welcome if simple enough for me and my non-specialist students! If it's easier with any other planet, let me know...? Any help would be highly appreciated!

Yours,
Maxime


Sun, rising and setting times

 

Hello,
I have few questions about the settings to compare ephemeris generated by XEphem and almanac data.
Times are calculated for upper limb or sun center crossing the horizon?
Atmosphere pressure: 0 or 1013 hPa? Does it change refraction?
Menu Preferencies > Equatorial > Topocentric or Geocentric?
Other settings to consider?
Best regards
Stefano


Re: Moon phases,solver

 

Thanks to all have contributed to help me visualize why the moon elongation from the sun is only rarely approaching 0 or 180 degrees.
stefano


Re: Moon phases,solver

 

On 2/10/23 9:11 PM, Wayne Green wrote:
The ecliptic is the "mean invariant plane" of the solar system.
I will not go beyond your first line.
First, the ecliptic is not a plane.
Neither it is Earth's orbit, as some believe.
The ecliptic is a great circle on the celestial sphere.
From a geocentric point of view, it is the projection on the celestial sphere of Sun's orbit around the Earth.
We also speak of the ecliptic plane, which is trivially the plane containing the ecliptic circle.

It's better to use "invariable" than "invariant". The former means "something which does not change in time"; the latter is an ancient term and in modern physics and astronomy has a different meaning, when applicable.
The invariable plane of the solar system is perpendicular to its total angular momentum, which is dominated by Jupiter's motion, mainly because ot its mass.
Actually the angle between the ecliptic plane and the invariable plane is almost 1.6¡ã.

To be sure, the ecliptic plane is not exactly stationary: Earth's motion is perturbed by the other planets. So it is necessary, when speaking of the ecliptic, to state the reference epoch (date).
But the ecliptic motion is very slow: about 47 arcseconds per century if I remember right.
--
Elio Fabri


Re: Moon phases,solver

 

It is true that, on new moon, the projection of the Sun-Earth-Moon angle is zero, but I think that the elongation is defined as the actual angle, not the projected angle.

The elongation will be zero only if the Moon? is on the ecliptic, and then there is a total Solar eclipse.

-Tomas Gomex


El vie, 10 feb 2023, 18:03, s.bortolussi@... via <s.bortolussi=[email protected]> escribi¨®:
that's my guess too, I am looking for a (simplified) model to visualize that.
But I am stuck to this: there are three bodies,sun,earth and moon; two of them on the ecliptic plane; in case of a new moon the angle separation sun-observer-target of the projection of the moon on the ecliptic plane should be 0 in my thinking; but it is not. At what point I am wrong? Spherical trigonometry?
sorry for a not so clear description ...


Re: Moon phases,solver

 

The ecliptic is the "mean invariant plane" of the solar system.
The solar system consists of the Sun, Jupiter and other debris!
So the Earth can be slightly above/below the mean plane (timescales
on the order of weeks/months to decent order).

Rather than spherical trig, use vectors. JPL Horizons offers up some
data but bear in mind the polynomials are not that accurate that far
back in time. You may have to play with a few of the observing
parameters. There are calendrical things to consider as well, like the
pesky 15 day leap between Julian date and Gregorian date not to
mention those leap years etc. Not to mention the 8 minutes or so of
light travel time. You will have to break that long a time period
up into segments. The problem with trig, on a computer, is the
Needle Angle problem. ?


So, if you take the Sun (not barycenter) vector to Earth and
cross that with Sun->Moon and look for the minimum point, then
you get a pretty decent estimate of the phase angle. The value
will not be zero, but close.

Here is full moon, on the order of 1.5 day resolution. Ephererides
every 1 day, so the resolution is pretty off. This is from the observer
table, vectors are avaliable as well if you want to try the maths.

?Date__(UT)__HR:MN, , , R.A.__(a-app), DEC_(a-app), ? ? ?Illu%, ? ? S-T-O, ?T-O-M, MN_Illu%,
?1322-Jun-30 07:00, ,m, ? 19 39 42.73, -20 13 31.5, ? 99.50468, ? ?8.0770, 0.0000, ?99.5047,
...
?1322-Jul-14 07:00, , , ? 07 23 24.24, +19 31 24.5, ? ?0.67674, ?170.5572, 0.0000, ? 0.6767,
?1322-Jul-15 07:00, , , ? 08 14 07.82, +16 15 10.1, ? ?0.14569, ?175.6283, 0.0000, ? 0.1457,

Column meaning: ?(Interesting tidbits here -- like for the Calendar.)
JPL is pretty cool for these things.

From the JPL Ephererides page...
?
TIME

? Times PRIOR to 1962 are UT1, a mean-solar time closely related to the
prior but now-deprecated GMT. Times AFTER 1962 are in UTC, the current
civil or "wall-clock" time-scale. UTC is kept within 0.9 seconds of UT1
using integer leap-seconds for 1972 and later years.

? Conversion from the internal Barycentric Dynamical Time (TDB) of solar
system dynamics to the non-uniform civil UT time-scale requested for output
has not been determined for UTC times after the next July or January 1st.
Therefore, the last known leap-second is used as a constant over future
intervals.

? Time tags refer to the UT time-scale conversion from TDB on Earth
regardless of observer location within the solar system, although clock
rates may differ due to the local gravity field and no analog to "UT"
may be defined for that location.

? Any 'b' symbol in the 1st-column denotes a B.C. date. First-column blank
(" ") denotes an A.D. date.
?
CALENDAR SYSTEM

? Mixed calendar mode was active such that calendar dates after AD 1582-Oct-15
(if any) are in the modern Gregorian system. Dates prior to 1582-Oct-5 (if any)
are in the Julian calendar system, which is automatically extended for dates
prior to its adoption on 45-Jan-1 BC.? The Julian calendar is useful for
matching historical dates. The Gregorian calendar more accurately corresponds
to the Earth's orbital motion and seasons. A "Gregorian-only" calendar mode is
available if such physical events are the primary interest.

? NOTE: "n.a." in output means quantity "not available" at the print-time.
?
SOLAR PRESENCE (OBSERVING SITE)
? Time tag is followed by a blank, then a solar-presence symbol:

? ? ? ?'*' ?Daylight (refracted solar upper-limb on or above apparent horizon)
? ? ? ?'C' ?Civil twilight/dawn
? ? ? ?'N' ?Nautical twilight/dawn
? ? ? ?'A' ?Astronomical twilight/dawn
? ? ? ?' ' ?Night OR geocentric ephemeris

LUNAR PRESENCE (OBSERVING SITE)
? The solar-presence symbol is immediately followed by a lunar-presence symbol:

? ? ? ?'m' ?Refracted upper-limb of Moon on or above apparent horizon
? ? ? ?' ' ?Refracted upper-limb of Moon below apparent horizon OR geocentric
? ? ? ? ? ? ephemeris
?
?'R.A.__(a-app), DEC_(a-app),' =
? Airless apparent right ascension and declination of the target center
with respect to an instantaneous reference frame defined by the Earth equator
of-date (z-axis) and meridian containing the Earth equinox of-date (x-axis,
EOP-corrected IAU76/80). Compensated for down-leg light-time delay,
gravitational deflection of light, stellar aberration, precession & nutation.
Note: equinox (RA origin) is offset -53 mas from the of-date frame defined
by the IAU06/00a P & N system.

? Units: RA ?in hours-minutes-seconds of time, ? HH MM SS.ff{ffff}
? ? ? ? ?DEC in degrees-minutes-seconds of arc, sDD MN SC.f{ffff}
?
?'Illu%,' =
? ?Fraction of the target objects' assumed circular disk illuminated by Sun
(phase), as seen by the observer.? Units: PERCENT
?
?'S-T-O,' =
? ?The Sun-Target-Observer angle; the interior vertex angle at target center
formed by a vector from the target to the apparent center of the Sun (at
reflection time on the target) and the apparent vector from target to the
observer at print-time. Slightly different from true PHASE ANGLE (requestable
separately) at the few arcsecond level in that it includes stellar aberration
on the down-leg from target to observer.? Units: DEGREES
?
?'T-O-M, MN_Illu%,' =
? ?Target-Observer-Moon LUNAR ELONGATION angle and illuminated percentage.
The apparent lunar elongation angle between target body center and Moon
center, seen from the observing site, along with fraction of the lunar disk
illuminated by the Sun. A negative lunar elongation angle indicates the target
center is behind the Moon.? Units: DEGREES & PERCENT

Computations by ...

? ? Solar System Dynamics Group, Horizons On-Line Ephemeris System
? ? 4800 Oak Grove Drive, Jet Propulsion Laboratory
? ? Pasadena, CA ?91109 ? USA

? ? General site:
? ? Mailing list:
? ? System news :
? ? User Guide ?:
? ? Connect ? ? : browser ? ? ? ?
? ? ? ? ? ? ? ? ? API ? ? ? ? ? ?
? ? ? ? ? ? ? ? ? command-line ? telnet 6775
? ? ? ? ? ? ? ? ? e-mail/batch ?
? ? ? ? ? ? ? ? ? scripts ? ? ? ?
? ? Author ? ? ?: Jon.D.Giorgini@...

**

On Fri, Feb 10, 2023 at 10:46 AM ab1jx <alan01346@...> wrote:
My astronomy professor did quite well with a rubber ball and a flashlight, but try Wikipedia.? I wrote a program showing how it works once.

On Fri, Feb 10, 2023, 12:03 PM s.bortolussi@... via <s.bortolussi=[email protected]> wrote:
that's my guess too, I am looking for a (simplified) model to visualize that.
But I am stuck to this: there are three bodies,sun,earth and moon; two of them on the ecliptic plane; in case of a new moon the angle separation sun-observer-target of the projection of the moon on the ecliptic plane should be 0 in my thinking; but it is not. At what point I am wrong? Spherical trigonometry?
sorry for a not so clear description ...



--


-- W


Re: Moon phases,solver

 

My astronomy professor did quite well with a rubber ball and a flashlight, but try Wikipedia.? I wrote a program showing how it works once.


On Fri, Feb 10, 2023, 12:03 PM s.bortolussi@... via <s.bortolussi=[email protected]> wrote:
that's my guess too, I am looking for a (simplified) model to visualize that.
But I am stuck to this: there are three bodies,sun,earth and moon; two of them on the ecliptic plane; in case of a new moon the angle separation sun-observer-target of the projection of the moon on the ecliptic plane should be 0 in my thinking; but it is not. At what point I am wrong? Spherical trigonometry?
sorry for a not so clear description ...