solarpositioning
solarpositioning copied to clipboard
klausbrunner
Wrong times
I'm getting wrong sunrise/set information for: Resolute Bay 74.6973, -94.8297 , November 1st, 2016 Returning Null, Null. However there is a sunrise and sunset on this day.. and even 2nd, 3rd, 4rd, and 5th.. All of those return null.
DateTime dt = new DateTime(2016, 11, 1, 1, 0);
SPA.calculateSunriseTransitSet(dt.toGregorianCalendar(), 74.6973, // latitude
-94.8297, // longitude 68); // delta T
Unless I'm doing something wrong, it seems the error in the higher latitude is very big. If I enter a lower latitude I get results that look more accurate when comparing with other sources.
Looks like you're doing everything right and there's a bug. Original spa.c gives sunrise/sunset. Likely a loss of precision somewhere, as the sun rises only about 1° above the horizon at solar noon in that location on 1 November 2016.
I think this algorithm is geared towards tracking the sun for energy purposes, like concentrating the sun's power. It was created for the department of energy. When it barely rises, it would make sense that it doesn't even count. It looks like the algorithms based on Jean Meeus's book are working better.
I'm surprised that you managed to get rise/set from the original. I tried an online calculator that says it's using the original algorithm and it also didn't provide a sun/set.. although I tried it for the 5th, a day that the sun doesn't fully rise.
SPA is effectively a condensed version of Meeus's AA, and it's worth keeping in mind what NOAA writes about this, emphasis mine: "The sunrise and sunset results are theoretically accurate to within a minute for locations between +/- 72° latitude, and within 10 minutes outside of those latitudes. However, due to variations in atmospheric composition, temperature, pressure and conditions, observed values may vary from calculations." (https://www.esrl.noaa.gov/gmd/grad/solcalc/calcdetails.html)
That said, I'd like this library to be very close to the reference implementation, so I still consider this a (minor) bug.
I stumbled across this library when looking for a way of computing sunrise and sunset times for the casual observer at their current location. Unfortunately, while it seems a great deal of effort went into attention to detail (DeltaT, etc.), the results from the SPA algorithm leave a lot to be desired when compared to NOAA's results for anything above ~60° latitude. Perhaps it's unreasonable to expect accuracy at such extreme latitudes from an implementation that uses native floating point math.
We found the same when trying the library out at the edge of Norway static public GregorianCalendar[] getSunTimes(GregorianCalendar calNow, Position pos) { GregorianCalendar[] res = SPA.calculateSunriseTransitSet(calNow, pos.getLatitude(), pos.getLongitude(), 68); return res; }
calNow = new GregorianCalendar(new SimpleTimeZone(2 * 60 * 60 * 1000, "CEST")); calNow.set(2019, Calendar.JANUARY, 30, 12, 01, 53); pos = new Position(68.6489, 18.9551, 100, (byte) 1, (byte) 1); res = getSunTimes(calNow, pos); System.out.println("sunrise " + formatSunTime(res[0]) + ", " + formatDate(df, res[0])); System.out.println("sunhigh " + formatSunTime(res[1]) + ", " + formatDate(df, res[1])); System.out.println("sunset " + formatSunTime(res[2]) + ", " + formatDate(df, res[2]));
This is very wrong sunrise 05:16, 2019-01-30T05:16:38+0100 sunhigh 11:57, 2019-01-30T11:57:24+0100 sunset 18:41, 2019-01-30T18:41:03+0100
About 4 hours off on both side (And it worse closer to the 15th) and the same happens for many days close to the switch from no sunrise to having sun again.
It has the sunhigh right at 11:57
NOAA says sunhigh:11:57 sunrise: 09:20 sunset:14:35
Issue identified and fixed in master. I'll publish a release soon, meanwhile there's a fresh snapshot at https://oss.sonatype.org/content/repositories/snapshots/net/e175/klaus/solarpositioning/