view release on metacpan or  search on metacpan

doc/astronomical-notes.pod  view on Meta::CPAN

  .   8h54mn11s      9h04mn03s        9mn51s  133°32'52"    136°00'47"      2°27'54"
  .  15h05mn22s     14h55mn30s       -9mn51s  226°20'31"    223°52'36"     -2°27'54"
  .  20h54mn11s     21h04mn03s        9mn51s  313°32'52"    316°00'47"      2°27'54"

=head4 Kepler's Second Law

Second, the rotational speed of Sun itself on the ecliptical plane is not a constant.
It obeys Kepler's second law, with a rotational speed more or less inversely 
proportional to the Earth-Sun distance.

Q: You cannot apply Kepler's second law to a geocentric model!

A: No. Kepler's second law applies to a barycentric model as D above. It applies
I<approximately> to an heliocentric model as C. But once we have computed
Earth's angular speed on its orbit around the Sun in model C, the computation of the
Sun's coordinates and speed in the geocentric model is very simple. Especially,
the Sun's angular speed in a geocentric model is equal to the Earth's speed in
an heliocentric model.

Here are the Sun's positions for 2017, as given by Stellarium. The software
gives the equatorial coordinates and I translate them  into ecliptic coordinates.

  date       right ascension         declination  ecliptic longitude
  4 January  18h59mn1s 284°45'15"    -22°44'43"   -76°24'58" or -76,4162°
  5 January  19h3mn24s 285°51'       -22°38'18"   -75°23'58" or -75,3996°
  3 July      6h48mn   102°           22°58'35"   101°2'7"   or 101,0355°
  4 July      6h52mn8s 103°02'        22°53'39"   101°59'26" or 101,9907°

This translates as a speed of 1.0166 degree per day in January at perigee (when
in a geocentric model, that is perihelion in an heliocentric model) and a speed
of 0.9552 degree per day in July at apogee (or aphelion). Values are respectively
0.0423°/h and 0.0398°/h.

=head4 Equation of Time

The Earth's spin velocity is constant, that is 360.9856 degrees per day
but the Sun's orbital speed around the Earth is not. The combination of
both speeds is variable and it is I<not> 360 degrees per day. The crossing
of the meridian by the Sun is not exactly every 86400 seconds.
There is a difference between the Solar I<Mean> Time, where noon occurs
every 86400 seconds, no more, no less, and the Solar I<Real> Time, in which
noon is defined by the time when the Sun crosses the meridian. The difference
between the Solar Mean Time and the Solar Real Time is called I<equation
of time>.

Here are the extreme values for the equation of time in 2017, computed
by a script using L<DateTime::Event::Sunrise> and refined with Stellarium.

  Date          DT::E::S    Stellarium
  2017-11-02    11:43:33    11:43:37   -16mn23s  earliest noon value,
  2017-02-10    12:14:12    12:14:14   +14mn14s  latest noon value
  2017-09-11    11:56:33    11:56:34    -3mn26s
  2017-09-12    11:56:11    11:56:13    -3mn47s  biggest decrease: 21 or 22 seconds
  2017-12-17    11:56:11    11:56:14    -3mn46s
  2017-12-18    11:56:41    11:56:44    -3mn16s  biggest increase: 30 seconds

And here is the curve for the equation of time.

=for html
<p>
<img src='equ-time.png' alt='Curve of the equation of time during one year' />
</p>

=head4 The Analemma

The irregularity of the Sun's trajectory can be visualised by using the Local Mean Time
as a reference and pinpointing the positions of the Sun at noon in LMT.
The various Sun positions day after day build an 8-shaped curve, called I<analemma>.

=head4 Mean Sun, Virtual Homocinetic Sun

In the following, it is useful to imagine a virtual Sun which would use an constant
angular speed (either in equatorial coordinates or ecliptic coordinates, depending on
which is more convenient).

The concept of I<Mean Sun> is a virtual Sun like this, calibrated so it crosses
the meridian at 12:00 (Local Mean Time) each day, and which minimizes the difference
between the real local noon and the mean local noon. 

I will also consider several "virtual homocinetic suns" or VHS (no relation with
magnetic tapes). These virtal suns are synchronised with the real Sun at some 
convenient point and then move with a constant angular speed.

=head1 Computing Sunrise and Sunset

Computing sunrise and sunset consists in taking in account both the variation of
day's length and the equation of time to pinpoint when the Sun reaches the
altitude that corresponds to sunrise or sunset.

In the schema below, the variation of day's length results in a bobbing up and
down of the sinusoidal curve (and less obviously, a vertical stretch or compression 
of this curve). The equation of time results in a leftward or rightward shift
of the curve.

=for html
<p>
<img src='pseudo-analemma.gif' alt="Evolution of the Sun's trajectory during a year" />
</p>

Q: Wahoo! Impressive!

A: You should not be impressed. I took some liberties with the reality. First, 
I figured the Sun's trajectory as a sinusoidal curve, because it is easy to compute,
but I did not check whether it was the real curve. And I would bet that it is
only approximately close to the real curve. Second, the equation of time is very much
increased. Instead of a true solar noon varying from 11:43 to 12:15 (in mean solar time),
here the variation is multiplied by 4 and the solar noon varies from 11:00, or even less,
to 13:00. But without this stretching, you would not have seen anything.

Q: And this figure eight, is this the analemma?

A: No. The analemma gives the position of the Sun as azimuth and height at 
I<mean> solar noon. In the curve above, the abscisse is the mean time of
I<true> solar noon and the ordinate is the height of the Sun at this instant.
In other words, the analemma is based on a regular temporal event, the mean solar
noon, and plots the correlation between two variable spatial phenomena, the 
azimuth and the height of the Sun. On the other hand, the curve above is based on
a precise spatial event, the azimuth 180°, and plots the correlation between a 
variable spatial phenomenon, the height of the Sun and a variable temporal event,
the true solar noon.

doc/astronomical-notes.pod  view on Meta::CPAN

night or midnight sun, use the basic algorithm.

=item *

If the date is near a transition between day+night and polar
night, use the basic algorithm.

=item *

If you live in a polar location AND the date is near a transition between
day+night and midnight Sun AND you are interested in the
visibility of the Sun's disk above the horizon, then you may use the
precise algorithm.

Note that if you live a bit southward of the arctic circle (say, Reykjavik),
you should use the precise algorithm around the 21st of June, even if midnight
sun does not happen there. Same thing aoround the 21st of December if you live
a bit northward of the antarctic circle.

=back

Q: And can we know why the use of the precise algorithm is so narrow?

A: Let us go back to the animated picture of the solar course curve that
moves along the pseudo-analemma. But instead of using a location
at Greenwich, we use a polar location still at longitude zero, but at
76 degrees and 59 minutes from the equator.

=for html
<p>
<img src='ps-an-pol.gif' alt="Evolution of the Sun's trajectory during a year (arctic variant)" />
</p>


As you can see, around 21st April and 21st August, the solar course
is tangent or nearly so with the line of horizon.
With these conditions, a variation of 6' of the solar altitude
can produce a much bigger variation of the points where the
solar course crosses the horizon.
For example, on 20th April 2017, at sunset time, we need 8 mn 18 s
to achieve this variation of 6'.

Q: Where does this 6' value come from?

A; This is the value I calculated in the chapter 
L<Principle of the Iterative Computation>.

On the other hand, if you live in a temperate location far from the
arctic circles, the slope of the solar course when crossing
the horizon is always a bit steep.
For example, at Greenwich, the shallowest slope occurs at each solstice
and is about 6 or 7 degrees of altitude per hour. So a variation of 6' shifts the sunrise and sunset times by
only 50 seconds or less.

The diagram below shows the effect of a 6' vertical translation on the solar course in
two cases: 20th April at 76° 59' N and 21st December at Greenwich.
Warning: it is not to scale.

=for html
<p>
<img src='sunset-slope.png' alt="Sun course, comparison between Greenwich on 21/12 and latitude 76 on 20/04" />
</p>

Q: And what happens to people living in polar locations when
the date is far from any transition?

A: If the period is day+night, the explanations above about the steep enough slope
of the curve still apply. If the period is the polar night or the
midnight Sun, then the course of the Sun never crosses the horizon and
any variation of altitude, within limits, cannot create an intersection
with the horizon.

Q: For the transition with the polar night, the solar course is tangent
to the equator, like it is at the transition with the midnight Sun period.
So, why do you still advise to use the basic algorithm in this case?

A: The basic algorithm and the precise algorithm both try to estimate
the ecliptic longitude and the altitude of the virtual noon sun at
the time of sunset. But while the precise algorithm uses the real
orbital speed which varies from 0.9552°/d to 1.0166°/d, the basic
algorithm uses a constant speed of 0.9856°/d, with an error of
±0.0310°/d. For the transition between day+night and midnight Sun,
this error runs for more than 11 hours, which might result in an error
of 0.015° on the Sun's ecliptic longitude. But for the transition
between day+night and polar night, the error runs for one hour or
less, yielding an error on the ecliptic longitude of 0.0013° only. So
even if a small error on the sun altitude gives a big error on the
sunset time, at the transition with the polar night, you will have a
I<tiny> error, not a I<small> one.

Q: And what about the computation of twilights? We can encounter a situation
where the solar course is tangent to the horizon, if I may use this word for a
line situated 24 degrees below the horizontal plane. And we have a ≈12 hour
gap as for the midnight Sun transition, not a 1-hour gap as for the polar night
transition.

A: Why do you compute twilight times? Because you want a low enough light
level and good enough conditions to observe celestial bodies.
Do you think there is a big difference between a night when the Sun is
at its lowest at 17°57' below the horizon and a night when it is at its
lowest at 18°3' below? In some circumstances, you'd better begin your observations
when the Sun is at, say, -15° than to wait for the -18° twilight if you know
that the Moon will rise at the same time or if a weather report gives a warning
about an incoming overcast layer.

=head2 C<alt> Parameter (Altitude) and C<upper_limb> Parameter

Parameter C<alt>, in decimal degrees, allows you to specify the altitude
of the sun corresponding to the event you are looking for: sun rise, sun
set or a twilight of some degree.

First, the various twilight values: they are arbitrary values. Nothing
to add.

For sunrise and sunset, the usual value is -0.833°, that is, -50'.
It comes from two values:

=over 4

=item * -0.583° or -35' for the refraction,