New utility by Jeff Conrad: Sun/Moon calculator

[QT Luong]

A new utility by Jeff Conrad has been posted:
Sun/Moon Calculator (http://largeformatphotography.info/sunmooncalc/).
Here the description by Jeff:

I have updated the Sun calculator so that it now gives rise and set
times and positions for the Moon as well as the Sun.

With the default settings, the calculator (/sunmooncalc/)
will provide the basic information that photographers usually need:
<ol>
<li> A table of Sun and Moon rise and set times and azimuths
<li> A table of Sun and Moon positions throughout the day
</ol>

I've also added a few other features:
<ol>
<li> The ability to specify nonzero altitudes for rise and set--handy
if the visible horizon isn't level. For example, Mt. Whitney has an
altitude of approximately 10 degrees from most spots near Movie Rd;
typically, the Moon hits Mt. Whitney about an hour before and 10
degrees to the south of "official" moonset.

<li> The ability to search for dates on which Sun or Moon rise or set
meet certain criteria, such as rising or setting within a certain
azimuth range, or the Moon rising or setting with a certain phase, or
within a certain time of Sun rise or set. These can be combined with
nonzero rise and set altitudes; for example, you could find the dates
on which the Moon sets near Mt. Whitney with alpenglow on the
peak. You also easily could show that Dennis diCicco determined the
correct date (1 November 1941) for Moonrise, Hernandez, New Mexico.
</ol>
At first glance, the Rise/Set Options may seem a bit complicated,
especially when reading the Help section, but they actually are fairly
simple to use after a few tries.



Other Changes

The location database has been expanded so that it now covers 380+
locations, including most national parks in the United States and
Canada.

The handling of daylight saving time/summer time is more robust,
although the start and end times still are tied to U.S. rules (in the
southern hemisphere, these times are simply reversed). I've added most
of the common fractional-hour time zones.

Performance

Performance is fine when calculating rise/set times over the course of
a few weeks, but the program is slow when doing searches extending
over several years--such is the consequence of implementing
astronomical calculations in a script. A year's worth of rise/set
times takes just over 7 seconds on my 1.4 GHz Pentium 4. A 10-year
search of dates takes just under 60 seconds, and prompts a "slow
script" warning from Internet Explorer and Firefox unless the default
warning triggers have been changed. Nonetheless, it's faster (as well
as much easier) than grabbing the data from the USNO site and
rearranging and analyzing it.





Please feel free to leave any questions and comments here.

[Giacomo GIRINO]

great, great, great! So many times I've just been guessing at what time the moon would rise and in what direction etc. etc.
I always went on guessing based only on my experience but that works for the places I know well only and not too precisely either. I many times thought I should have worked out something like this calculator but I was just too lazy to.
Thanks Mr Conrad!

Lino (45°8'N, 8°31'E)

[John_4185]

great, great, great! So many times I've just been guessing at what time the moon would rise and in what direction etc. etc.

Pity. There are published tables.

[Doug Dolde]

"Pity. There are published tables." WTF is that supposed to mean? You must be a Pommie with a stick up his behind.

I think this is the best sun/moon calculator I have seen. Thanks.

[Paddy Quinn]

Jeesh - you sound like some kind of Aussie - keep the convict talk to yourself. As far as I know jj is all Yank?

BTW - there are other excellent online calculators of this sort online

[Ralph Barker]

Excellent addition to the site, QT, and nice job, Jeff.

Now, if we could just get one of these to interact with topo maps, and overlay the shadows in 3-D, we'd be all set. (lol)

[Jeff Conrad]

Don't laugh too hard, Ralph. In most cases, I wouldn't know what to do
with a Moon azimuth without a computerized topo map (though I wish they'd
give altitudes as well). I think the 3-D features of most such maps have a
way to go, but they still sometimes are helpful.

Several astronomy programs will simulate the passage of a celestial body
across the horizon, and allow this to overlay a photograph. The rub is
that you need a photograph of every view from every location that you want
to model. I use a program that generates a table of Sun and Moon positions
vs. landscape features; it's a bit short of VR, but the next step would not
be out of the question for someone good at graphics. Were there sufficient
demand, we might already be there.

[John_4185]

Now, if we could just get one of these to interact with topo maps, and overlay the shadows in 3-D, we'd be all set. (lol)

earth.google.com/ (http://earth.google.com/)
It interacts with GPS.

[chris_4622]

I've used this for sunrise information: http://www.hourworld.com/

chris

[Jeff Conrad]

If you need only information for the Sun, Wide Screen Software (http://www.wide-screen.com)'s SunPATH ($99)
looks as if it's very nicely done. It's available for the Mac, and using a
Mac emulator, for Wintel machines. John Cook posted

this link (http://store.yahoo.com/cinemasupplies/sunsoffowwin.html) that has SunPATH on sale for $87 during September.

There are several native programs available for Wintel machines, such as
Fossil Creek's Heavenly
Opportunity (http://weba.viawest.net/users/fcs/ho/) ($25) or Digital Light &
Color (http://www.dl-c.com)'s Ephemeris. Neither has all the features of the Sun/Moon
Calculator that I wrote, but they're much faster, and Heavenly Opportunity
has a much larger location database. Ephemeris is free, so the
cost/benefit ratio is hard to beat. Heavenly Opportunity allows searches
similar to those of my Sun/Moon Calculator, so it may be worthwhile for
those who do many searches in attempt to find the perfect photo op.
Neither program allows nonzero rise/set altitudes.

[Spencer Cliss]

Another tool I believe not yet mentioned is Sun Clock. It's free and has worked well for me.

http://www.mapmaker.com/sunclock.htm

[Giacomo GIRINO]

Ralph Barker wrote:
>... if we could just get one of these to interact with topo maps ...

what I've done is use an image of a map as background for an Excel graph then from the data from Conrad's calculator, overlay lines in the right direction (e.g. direction of sunset). It can be automated with excels functions:
- with the sun/moon calculator create a table with resulting data spanning a priod of interest (first thought: 1 year!!)
- import the table in excel
- create a function that searces the table for a date you type and retrieves relevant data
- work through the necessary sines, cosines and tangents an have excel plot lines in the wanted directions over the map

not 3D but I hope it will help me choose the right spot where to get moon reflections on the Po river.

Lino 45°8'N, 8°31'E

[Jeffrey Sipress]

Thanks, but on-line calculators are good only before you leave the house. When you need it most, you're on the road, or in the middle of a beautiful nowhere. What good is a laptop with a browser then? A stand alone app is what's really needed.

[QT Luong]

Jeffrey, maybe I am wrong, but I think that Jeff wouldn't mind if you copied the four files that make up the Sun/Moon calculator to your laptop for personal use. If you do so the calculator will run as a stand-alone.

[Jeff Conrad]

Jeffrey, maybe I am wrong, but I think that Jeff wouldn't mind if you
copied the four files that make up the Sun/Moon calculator to your laptop
for personal use.


Not a problem. If you have a Wintel machine, though, you also might want
to consider the other two programs that I mentioned--they'll run a lot
faster. Since Ephemeris is free, why not? And Heavenly Opportunity might
be worth it just for the database.

I don't mean to suggest that other similar programs aren't good. However,
like my calculator, Ephemeris and Heavenly Opportunity were written by
photographers primarily for photographers, so they provide azimuths as well
as rise and set times. Many other almanac programs don't do this.

If you have a Mac, I don't know what to recommend, although that certainly
doesn't mean that nothing is available--it's just that finding it hasn't
been my top priority.

[Leland]

Great calculator. I've been looking for an app like this for calculating the lunar times. You mentioned that you don't mind if we copied the 4 files to our laptops, where can I get those 4 files?

If not the files can I get the formulas used? I could easily write a program using VB to have a stand alone executable but I don't want to have to figure out the formulas used in the calculations.

Thanks,
Leland

[QT Luong]

lfphoto.info/sunmooncalc/index.html

lfphoto.info/sunmooncalc/SunMoonCalc.js

lfphoto.info/sunmooncalc/SunMoonCalcHelp.htm

lfphoto.info/sunmooncalc/SunMoonCalcOptions.htm

[Gordon McKinney]

Really nice.... I've added a link to your site from my Photographic Cheat Sheet....

http://www.night-ray.com/photo-cheat.php

[sunposition]

SunPosition at http://www.sunposition.net is a really handy online application for photograpers.
See this post:

http://www.largeformatphotography.info/forum/showthread.php?t=18736

[sunposition]

Just to let you know:

SunPosition has now just over 48,400 preset locations for members.

http://sunposition.net

[chris_4622]

I use HourWorld. They have a demo model you can try.

[Steve Kefford]

I use Ephemeris by J Sachs. It runs on a PDA, so I can take it out in the field with me. Cost £0.00.

Steve

[Graeme Hird]

I use SunMoonCalc. It also costs nothing and encourages our forum members to share their excellent work.

Graeme

[Ted Harris]

Good work Jeff. If you just want a quick and dirty look that also gives you times for civil twilight, etc. then take a look at:

http://aa.usno.navy.mil/data/docs/RS_OneDay.html


You will get a page like this when you plug in the location by by name:

U.S. Naval Observatory
Astronomical Applications Department


Sun and Moon Data for One Day

The following information is provided for Orford, Grafton County, New Hampshire (longitude W72.1, latitude N43.9):

Friday
5 January 2007 Eastern Standard Time

SUN
Begin civil twilight 6:50 a.m.
Sunrise 7:23 a.m.
Sun transit 11:54 a.m.
Sunset 4:25 p.m.
End civil twilight 4:58 p.m.

MOON
Moonrise 5:28 p.m. on preceding day
Moon transit 1:23 a.m.
Moonset 9:05 a.m.
Moonrise 6:39 p.m.
Moonset 9:30 a.m. on following day


Phase of the Moon on 5 January: waning gibbous with 95&#37; of the Moon's visible disk illuminated.

Full Moon on 3 January 2007 at 8:58 a.m. Eastern Standard Time.

[vinny]

[QUOTE=Jeff Conrad;125196]If you need only information for the Sun, Wide Screen Software (http://www.wide-screen.com)'s SunPATH ($99)
looks as if it's very nicely done. It's available for the Mac, and using a
Mac emulator, for Wintel machines. John Cook posted

this link (http://store.yahoo.com/cinemasupplies/sunsoffowwin.html) that has SunPATH on sale for $87 during September.

SunPath is a very useful program that's easy to use. It gives you all the info you need on one page along with shadow factors if you need that sort of thing. You can figure out how long an objects shadow will be at any given time. The suunto tandem inclinometer and sunpath make for easy foolproof calculations.

vinny

[Eric James]

This is an awesome tool - thank you very much Jeff Conrad.

To those of you who haven't discovered this LF.INFO utility, it's worth checking out. Enter your destination, your trip dates, and print - laminate in a Ziplock bag and you're good to go.

http://www.largeformatphotography.info/sunmooncalc/

[QT Luong]

Jeff Conrad has upgraded the Sun/Moon Calculator (http://www.largeformatphotography.info/sunmooncalc/) to version 3.5. Here is a description of changes:

1. It is now possible to specify a range of rise/set altitudes. This is
much easier than manually adjusting the azimuth range and time
difference to simulate an altitude range when the objective is to find
the days when the Sun or Moon pass through a "window" of azimuth and
altitude.

2. There is an option to search the location database for locations
matching a pattern. In some cases, this is faster than selecting a
location from the list; for example, cycling through all locations in
California. There is an option in user preferences to allow Perl-style
regular expressions in search patterns.

I'm still trying to decide if the search option should be enabled by
default; the user can enable or disable it via the preferences form.

3. There is now some support for browsers that provide tabbed viewing.
For the most part, the user can specify whether new windows open in new
windows or in tabs; behavior is also dependent on browser settings.

4. The user interface has been slightly revised in response to a couple of
user comments. I've added borders around the input areas to make it
more obvious what they do; I've also changed the background to light
gray (the same color as the Sun columns in the output of the current
version) so that the input areas are more obvious. There is an option
to have inactive areas of the main form "grayed out"; this makes more
obvious which of two mutually exclusive options has been selected.

The "graying out" also works better with the gray background. The gray
isn't very dark, but I think I can make the "graying out" work with a
white background if this is a problem

5. I've (finally) updated DST rules for several countries; the ones most
important to the LF users probably are Canada and Australia.

6. Form validation has been revised to avoid problems that result from the
focus() bug in Firefox. In previous releases, entering the wrong value
could result in an endless loop. Because of the change, error handling
with Firefox is slightly different from that with Internet Explorer.

Client sniffing is always a guess; many browsers spoof some of the
navigator properties, so it's possible that some other browser will be
misidentified as Firefox. The validation still works, but it's not
quite as nice as with IE.


I've tested with IE 7, Firefox 2, and Opera 9.21. I've also tested briefly
with the Safari Beta for Windows, but it's still too buggy for a thorough
evaluation.

[OldBikerPete]

Great calculator.
However, I think you need to correct azimuth calculations for the southern hemisphere. Sunrise and sunset positions for Melbourne, Australia calculate to 120° and 240° which puts the sun south of Melbourne. I expect this should be 60° and 300° respectively.

[Jeff Conrad]

Are you talking about today? If so, the rise and set azimuths for Melbourne are as they should be--you folks are in the middle of summer. The situation in the southern hemisphere is the reverse of what it is in sunny (er, rainy) San Francisco; the Sun still appears to move from east to west, but its azimuth decreases during the day, transiting to the north, and further decreasing until it sets. In the summer, rise and set are south of east and west, consistent with a longer day; in the winter, rise and set are north of east and west, with values essentially as you suggest. This is what happens, isn't it?

Other calculators, including the U.S. Naval Observatory Data Services (http://aa.usno.navy.mil/data/) Sun and Moon positions page (http://aa.usno.navy.mil/data/docs/AltAz.php) give essentially the same values as the LF calculator.

[Ole Tjugen]

Eh - since 0 degrees is due north, and the sun at local noon in the southern hemisphere is due north, the azimuth should decrease from dawn to noon, then jump from 0 to 360, and decrease again.

60 and 300 degrees is consistent with high southern latitude winter, in the summer the arc is more than 180 degrees.

So the calculator is essentially correct.

The only problem I've found is north of the polar circle - if there is no sunrise or sunset, it doesn't display the azimuths. Maybe it could default to 00:00 to 24:00 in those cases?

[Jeff Conrad]

That's certainly an interesting idea, but it may prove a bit messy to give a reasonable implementation. In the default case, i.e., within the polar circles on days on which the Sun or Moon doesn't rise or set, it might be fairly straightforward. But in more special cases, e.g., at moderate latitudes on a day on which the Moon doesn't rise or set (there's one of each every month), results could be a bit confusing, especially if the user has specified something like 1-minute intervals for +/- 10 minutes on either side of the phenomenon that did not occur. Sun "rise" or "set" also may not occur at moderate latitudes if a nonzero altitude has been specified for rise or set; the greater the altitude, the further outside the polar circles this can happen.

At the very least, the suggestion to manually select 0:00 and 24:00 for the display of Sun and Moon positions when rise or set do not occur should probably be added to the Help page. You obviously figured out the solution, but it may not be obvious to everyone.

I recently found a couple of real bugs, though they won't affect most users:

The latitude of Shanghai is wrong (it should be 31:14 rather than 39:14).
Handling of an observer at a height greater than the surrounding terrain isn't always correct. If a nonzero Observer's Height and a nonzero rise/set altitude are both specified, the altitude is still adjusted for the observer's height--this should not happen. Furthermore, atmospheric refraction isn't included until the apparent altitude reaches zero. If an observer is substantially above the surrounding terrain, the Sun or Moon is visible at apparent altitudes less than zero, and the effect of refraction should be included. In most cases, this isn't an issue, but an observer watching the sunrise from Pikes Peak in Colorado can see the Sun at an apparent altitude of about -1.8 degrees.

These problems will be fixed in a future version. In the meantime, there are simple workarounds for two of the issues:

If the location is Shanghai, select it, then click Copy Place, select Custom Location, and edit the latitude.
For an elevated observer, either ensure that a nonzero rise/set altitude is not also specified, or if a nonzero rise is required, set Observer's Height to zero. Again, this is a pretty unusual situation.

[OldBikerPete]

Are you talking about today? If so, the rise and set azimuths for Melbourne are as they should be--you folks are in the middle of summer. The situation in the southern hemisphere is the reverse of what it is in sunny (er, rainy) San Francisco; the Sun still appears to move from east to west, but its azimuth decreases during the day, transiting to the north, and further decreasing until it sets. In the summer, rise and set are south of east and west, consistent with a longer day; in the winter, rise and set are north of east and west, with values essentially as you suggest. This is what happens, isn't it?

Other calculators, including the U.S. Naval Observatory Data Services (http://aa.usno.navy.mil/data/) Sun and Moon positions page (http://aa.usno.navy.mil/data/docs/AltAz.php) give essentially the same values as the LF calculator.

Stop spouting and think for a minute. Melbourne is at 34° South latitude. There is NO time of the year at which the sun rises or sets south of East or West.

[Ole Tjugen]

Think for a minute:

I'm at the opposite situation, far north.

At midwinter, the sun rises (barely) in the south-southeast, and sets (almost immediately) in the south-southwest.

At the equinoxes, it rises in the east and sets 12 hous later in the west.

In the summer it rises in the north-northeast, and sets 22 hours later in the north-northwest. A little farther north than here it doesn't set at all, but circles around through due north.

So in summer in the northern hemisphere it rises and sets north of due east/west.

In the southern hemisphere it's just the same (only opposite) - in the summer it rises and sets south of due east/west.

The calculator is correct.

[Jeff Conrad]

To an observer in space, the apparent motions of the Sun and Moon are quite simple. Governed primarily by Earth's rotation, the paths of the Sun and Moon are quite simple: parallels determined by the Sun's or Moon's declination (angle with the plane of the celestial and Earth's equator). To an observer at a particular point on Earth, the apparent paths are a bit more complicated.

The attached file illustrates what's happening. The figures are for the northern hemisphere; the situation in the south is just the reverse, as Ole described (imagine everything mirrored about the vertical line through the zenith). The purple axis through P is the north-south axis of the celestial sphere, as well as the axis of Earth's rotation. The paths of the Sun and Moon are circles, as shown in yellow.

To an earthbound observer, whose horizon is the plane NESW, the paths appear anything but circular, which is why an azimuth/altitude table seems so complex.

The figures indicate the general characteristics of the Sun's path, for any geographic latitude. Ar and As are the azimuths of rise and set. The descriptions that follow are for the northern hemisphere.


Summer solstice: The Sun rises and sets north of east and west, and reaches its greatest maximum altitude at due south.
Spring/Fall equinoxes: The sun rises and sets due east and west; day length is approximately 12 hours, for all latitudes.
Winter solstice: The Sun rises and sets south of east and west, and reaches its least maximum altitude at due south.

[Khosrownia]

Great program, Jeff - thank you.

Farzad