pingswept / pysolar Goto Github PK

What is wrong with this functions? See my example:

>>> from pysolar.solar import *
>>> import datetime
>>> my_data = datetime.datetime.now()
>>> print my_data
2017-04-20 19:21:09.478130
>>> get_altitude_fast(47.4616,26.3015,datetime.datetime.now())
-20.114173501280593
>>> get_altitude_fast(47.4616,26.3015,my_data)
-20.352695547467164
>>> get_altitude(47.4616,26.3015,my_data)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/site-packages/pysolar/solar.py", line 58, in get_altitude
    jd = time.get_julian_solar_day(when)
  File "/usr/lib/python2.7/site-packages/pysolar/time.py", line 742, in get_julian_solar_day
    +
AttributeError: 'datetime.datetime' object has no attribute 'timestamp' 

Was playing with this library today and found an inconsistency. If you call get_altitude_fast with no timezone, it assumes UTC. If you call get_altitude with no timezone, it assumes something else and produces a different result by 80 degrees.

If I were the decider I would require timezone-awareness on all datetimes so there's nothing to assume, but that's me. If tzinfo is not set, just raise and be done. That would be a breaking change though, so you might anger some folks :)

from pysolar.solar import get_altitude, get_altitude_fast
from datetime import datetime

# first be a good citizen and make a timezone aware datetime
d = datetime(2000, 1, 1, tzinfo=pytz.utc)
y = get_altitude(33, 44, d)
print(y) # -50.85138816460989

y = get_altitude_fast(33, 44, d)
print(y) # -50.94686162937928


# now be vague and try it with no timezone - big discrepancy!
# to me not specifying the timezone is a sin already but still...
d = datetime(2000, 1, 1)
y = get_altitude(33, 44, d)
print(y) # 31.734391266371397

y = get_altitude_fast(33, 44, d)
print(y) # -50.94686162937928

... get_radiation_direct() returns a value in watts per square meter ...

What is the period of time that represents the result of this function? An entire day? I mean, I get a value 909 like in the example, so I can interpret:

the average insolation for that lat/long point is 909 W/m2 in the 5th day of the year 2018

Is that correct?

And what about the 0.8 version? Should it return 0s at night?

I am asking because of this comment: As of version 0.7, the function is not smart enough to return zeros at night

I cannot get the azimuth function to work. Maybe I am doing something wrong but I spend a lot of time trying to get this correct. The altitude angle is calculated but wrong. What am I doing wrong, or is thi a bug? Please help...

Fredrik

C:\Python27\python.exe -u C:\Program Files (x86)\JetBrains\PyCharm 3.4.1\helpers\pydev\pydevconsole.py 13590 13591
PyDev console: starting.import sys; print('Python %s on %s' % (sys.version, sys.platform))
Python 2.7.8 (default, Jun 30 2014, 16:03:49) [MSC v.1500 32 bit (Intel)] on win32
sys.path.extend(['M:\PythonScripts\dataprocessing_Python'])

from pysolar import solar
import datetime

solar.get_altitude_fast(57.7,12.0,datetime.datetime.now())
34.339120191173976

solar.get_azimuth_fast(57.7,12.0,datetime.datetime.now())

Traceback (most recent call last):
File "", line 1, in
File "M:\PythonScripts\dataprocessing_Python\pysolar\solar.py", line 135, in get_azimuth_fast
altitude_rad = math.radians(get_altitude(latitude_deg, longitude_deg, when))
File "M:\PythonScripts\dataprocessing_Python\pysolar\solar.py", line 58, in get_altitude
jd = time.get_julian_solar_day(when)
File "M:\PythonScripts\dataprocessing_Python\pysolar\time.py", line 742, in get_julian_solar_day
+
AttributeError: 'datetime.datetime' object has no attribute 'timestamp'

I'm trying to create a solar path graph, and what I see is that instead of a nice smooth transition I get kinks.
So instead of

(from https://permaculturenews.org/wp-content/uploads/2015/10/ravsunImage10.jpg)

I get

Code is here : https://gist.github.com/jvhaarst/6ee7c6c5972afcddfa1904777fe7d5a8

Are the path that I calculate the truth, and thus the other ones an perfection, or is pysolar slightly off when calculating the positions ?

I'm trying to get pysolar to work on a Win7 laptop but am having no luck 'finding' e.g. get_altitude. Might a "Windows" heading be added to the manual with a short description of what needs appending to PATH or PYTHONPATH etc. i.e. what file is in the folder I need to direct PATH to?

Hi there!

I think the documentation is a little bit outdated. The latest version 0.8.0 does only support Python 3.6+.
The documentation points to 3.4 and talks about not supporting python 2.

This was the commit breaking <3.6 support: 6c52c70#r31253580

I don't really mind about supporting anything but Python 3.7, but I guess the documentation could be improved.

Best
-Joe

PIP is now installed with python 2.x, so a 0.6.0 package of this lib makes sense.

There seems to be a problem registering to the mailing list. I tried twice, by sending email to the address listed in the README.
I got the following reply from the mailer daemon:

Delivery incomplete

There was a temporary problem delivering your message to [email protected]. Gmail will retry for 21 more hours. You'll be notified if the delivery fails permanently.
 

The values returned by get_azimuth_fast are completely different from those returned by get_azimuth. After verification it seems that get_azimuth_fast is the culprit. Offset of 180 ?

from pysolar import solar
import numpy as np
from datetime import datetime
import pytz

lat = 50.
lon = 3.
time = datetime(2018, 5, 8, 12, 0, 0, tzinfo=pytz.UTC)

print(solar.get_azimuth(lat, lon, time))        # returns 186.8391776928919
print(solar.get_azimuth_fast(lat, lon, time))   # returns 6.8545786939043`

This code is broken, when I attempt to use the function I get the error:
TypeError: unsupported operand type(s) for +: 'datetime.datetime' and 'float'
It probably needs to use the datetime.timedelta() object. I can do this, but I'm still unsure of myself so I'm submitting it as an issue for my coding betters to assess.

It is also wrong. Delta-T cannot be treated as a constant, as far as I know it is an observation-only data point and the code should pull Delta-T (as well as leap second logs, but I think that is included in the datetime lib) from almanacs.

However, this function does not appear to be used anywhere. Unless I call it specifically, it does not seem to get called anywhere.

def GetJulianEphemerisDay(julian_day, delta_seconds = 66.0):
    """delta_seconds is the value referred to by astronomers as Delta-T, defined as the difference between
    Dynamical Time (TD) and Universal Time (UT). In 2007, it's around 65 seconds.
    A list of values for Delta-T can be found here: ftp://maia.usno.navy.mil/ser7/deltat.data

    More details: http://en.wikipedia.org/wiki/DeltaT

    """
    return julian_day + (delta_seconds / 86400.0)

Using the following code to show a 24 hour cycle at 0.1 hour intervals using the pysolar library, I get very unusual outputs which I can't explain:

import matplotlib.pyplot as plt
from pysolar.solar import *

SI=[]
date = datetime.datetime(2010, 1, 1, 0, 0, 0, 130320)
end_date = datetime.datetime(2010, 1, 1, 23, 0, 0, 130320)
long = -71.4
lat = 42.3

while (date <= end_date):
    date = date + datetime.timedelta(hours=0.1)
    altitude_deg = get_altitude(lat, long, date)
    azimuth_deg = get_azimuth(lat, long, date)
    SI.append( radiation.get_radiation_direct(date, altitude_deg) )

plt.plot(SI)
plt.show()

The plot from this is:

The spikes occur when the 'altitude' parameter tends to 0, but not necessarily when it is negative, for example, at 0.564 degrees, the solar irradiance is computed at 15953163.

If I only capture the solar irradiance when the altitude > 1 degree, I get this (as expected):

The code for this is:

import matplotlib.pyplot as plt
SI=[]
date = datetime.datetime(2010, 1, 1, 0, 0, 0, 130320)
end_date = datetime.datetime(2010, 1, 1, 23, 0, 0, 130320)
long = -71.4
lat = 42.3

while (date <= end_date):
    date = date + datetime.timedelta(hours=temporal_resolution)
    altitude_deg = get_altitude(lat, long, date)
    azimuth_deg = get_azimuth(lat, long, date)
    if altitude_deg > 1:
        SI.append( radiation.get_radiation_direct(date, altitude_deg) )

plt.plot(SI)
plt.show()

Also, shouldn't altitude be called elevation? In physics, the angle subtended from the horizon to some object is generally referred to as the elevation angle, or am I misunderstanding its meaning?

The version of pysolar hosted on PyPI labeled 0.7 is from April 2015. Do you consider releasing a newer version 0.8 (or similar) there to also make recent developments and fixes in pysolar available for installation via pip?

get_hour_angle seems to have the wrong sign.

For example 1.6.1 in the book "Solar Engineering of Thermal Processes by Duffie and Beckman, fourth edition, Wiley 2013" the hour angle should be -22.5. (-22.5 % 360.0 = 337.5)

get_hour_angle returns 22.534353021748803
get_local_hour_angle returns 337.5524428538668

In the book the hour angle is defined as:
"Hour angle, the angular displacement of the sun east or west of the local meridian
due to rotation of the earth on its axis at 15° per hour; morning negative, afternoon
positive."

A solution would be to change

def get_hour_angle(when, longitude_deg):
    solar_time = get_solar_time(longitude_deg, when)
    return 15 * (12 - solar_time)

to

def get_hour_angle(when, longitude_deg):
    solar_time = get_solar_time(longitude_deg, when)
    return 15 * (solar_time-12.0)

get_azimuth_fast often fails with "ValueError: math domain error":

pysolar.solar.get_azimuth_fast(48, 14, datetime.datetime(2015, 3, 10, 16, 30))

---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-114-4c2d9c95eae0> in <module>()
----> 1 pysolar.solar.get_azimuth_fast(48, 14, datetime.datetime(2015, 3, 10, 16, 30))

C:\...\site-packages\pysolar\solar.py in get_azimuth_fast(latitude_deg, longitude_deg, when)
    135     altitude_rad = math.radians(get_altitude(latitude_deg, longitude_deg, when))
    136 
--> 137     azimuth_rad = math.asin(math.cos(declination_rad) * math.sin(hour_angle_rad) / math.cos(altitude_rad))
    138 
    139     if(math.cos(hour_angle_rad) >= (math.tan(declination_rad) / math.tan(latitude_rad))):

ValueError: math domain error

pysolar version is 0.7 on python 3.4 / windows x64.

Hi Brandon,
Is there any function implemented on Pysolar, which day length could be computed based on specific sun Altitude as boundary limits?

Thank you,
Arnaldo.

Hey. I'm an amateur in these things, but isn't the reference graphic exactly wrong in terms of azimuth? The text says zero is south, and positive values go from there to the east. Yet the arc goes from south to the west towards the example position, which would mean an azimuth of maybe 70°. When in fact the "right" way would be all the way around and more like 290°.

radiation.get_radiation_direct() returns incorrect values when there is a negative or 0 based sun angle (altitude). altitude_deg should be checked at the start of the function and should return 0 if the altitude_deg is 0.0 or less.

Hello,

Is it required to set the UTC time zone in order to use get_azimuth or get_altitude as is required by the Sun Position Algorithm in Matlab? Because I get different results from the two algorithms and the difference is related to the UTC. If is need to set the UTC where do i set it? I'm using a code like this in Pysolar 0.6:

import pandas as pd
import Pysolar.solar as pys

df = pd.read_csv('radiation.csv', sep=";", index_col='Date Time', decimal=',')
df.index = pd.to_datetime(df.index, unit='s')

azimuth=pys.GetAzimuth(latitude, longitude, df.index[i], elevation)
zenith = 90-pys.GetAltitude(latitude, longitude, df.index[i], elevation)

In the Matlab version of the algorithm the funztion sun_position takes as input 2 structs one containing location info (lat, lon, elev) and a time struct that contains (Year, Month, Day, Hour, Minute, Second and UTC time).

Thanks

Hi !
I'm using pysolar with a gps and actual time, I'm trying to make it works but it seems that I have some problems.
EDIT:
How can I handle this warning without considering that is it an error and do a try: except:? :

/usr/local/lib/python3.4/dist-packages/pysolar/time.py:105: UserWarning: I don't know about leap seconds after 2015
  (leap_seconds_base_year + len(leap_seconds_adjustments) - 1)

Any ideas ? Thanks in advance !

The doc comparing PySolar with PyEphem and SunPy are awesome! Do you have some differences related to the Astral library too? https://github.com/sffjunkie/astral

Hello,

I wonder how one can take into account a surface declination either for Altitude and Direct Radiation,
which function may I touch to insert in a correct way either a PV tilt and azimuth w.r.t the references?

As the following code considers a plane tangent to the simulation point on the ground:

import pysolar
import numpy as np
from datetime import *
import pytz as tz

dt_start = datetime(2018,6,18, 0, 0, 0, tzinfo=tz.utc)
dt_end = datetime(2018,6,19, 0, 0, 0, tzinfo=tz.utc)
lat, long, elevation = 45, 11, 100
step = 60
tilt = 10; declination = 10 #degrees

alt_func = lambda t: pysolar.solar.get_altitude(lat, long, t)

alt_func_vect = np.vectorize(alt_func)

sim_time_array = np.arange(dt_start, dt_end, timedelta(seconds = step)).astype(datetime)

altitues = alt_func_vect(sim_time_array)

rad_func = lambda date, altitude_deg: pysolar.radiation.get_radiation_direct(date, altitude_deg)

rad_func_vect = np.vectorize(rad_func)

radiations = rad_func_vect(sim_time_array, altitues)

radiations[altitues<=0] = 0

So I would like to know first this is already considered in kind of function arguments and if not, which one can I modify to add this functionality.

Thanks in advance.

I have been calculating altitude using getAltitude() for every second in a given day, and I've found that some values for utc_datetime result in weird altitude values.

To illustrate the problem, I've created a simple loop that calculates the altitude for each second in a 10 second range.

utc = pytz.timezone('UTC')
tz = pytz.timezone('Australia/Melbourne')
for i in range(0,10,1):
current = tz.localize(datetime.datetime(2015,5,25,17,36,33))
current = current + datetime.timedelta(seconds=i)
u = current.astimezone(utc)
altitude = solar.GetAltitude(lat, long, u)
print(i, current, altitude)

This should result in 10 relatively similar altitude values, right? Here's the actual output:

0 2015-05-25 17:36:33+10:00 -4.590505104749698
1 2015-05-25 17:36:34+10:00 -5.139745001829341
2 2015-05-25 17:36:35+10:00 -5.137986069227229
3 2015-05-25 17:36:36+10:00 -5.113356781660575
4 2015-05-25 17:36:37+10:00 -5.128153217044195
5 2015-05-25 17:36:38+10:00 414.8938077719494
6 2015-05-25 17:36:39+10:00 -5.116501039352879
7 2015-05-25 17:36:40+10:00 -5.085170911710851
8 2015-05-25 17:36:41+10:00 -5.085028778777904
9 2015-05-25 17:36:42+10:00 -5.147078347088631

Note the altitude value for 5. This does not occur when I use the getAltitudefast() function.

I understand there may be a will to have pysolar only depend on the standard library.
However for some applications it would be extremely useful to use numpy instead of math, in order to vectorize operations, and support array inputs/outputs to most of pysolar's functions.
Maybe even support both using something like:

try:
    from numpy import pi, radians, arctan as atan, arcsin as asin # etc
except ModuleNotFoundError:
    from math import pi, radians, atan, asin # etc

Introduce get_transit_time(latitude_deg, longitude_deg, when) function to calculate the Sun transit time.

The azimuth/altitude image shown in the documentation is wrong, but we've lost the source file.

Here's the current PNG file: https://github.com/pingswept/pysolar/blob/master/doc/img/reference_frame.png

We need a version of this file that matches the description of how azimuth is measured on this page: http://docs.pysolar.org/en/latest/ (Altitude is still right, I think.)

The file was originally an SVG made in Inkscape, but the SVG is nowhere to be found, or at least I can't find it. It doesn't appear to have ever been added to the git repo, and it was originally made around March, 2008.

While trying to use GetSunriseSunset if found util.py completely broken, I'm not sure whether my patch (http://pastie.org/901954) will work with current HEAD.

I also think it's very offensive to put modules in package without namespace, after installing pysolar util is accessible just by import util which as you may imagine is a bit fragile, any other python package with the same bad practice will cause trouble.

the azimuth_rad calculation results in a math.asin(-1.1223) output. This is mathematically impossible.

using:
latitude = 52
longitude = 5
datetime:
day=25
hour=6
month=3
year=2014
tzinfo = UTC

The "not" fast calculation does work by the way.

http://docs.pysolar.org/ seems to be gone

http://github.com/pingswept/pysolar/blob/master/radiation.py#L36
http://github.com/pingswept/pysolar/blob/master/radiation.py#L32

make it so the containing functions always yield the same result regardless of day.

>>> set([GetOpticalDepth(d) for d in range(365)])
set([0.17399999999999999])

need to use 360./365 to enforce floating point division. 360/365 is always 0

Hi,

I just updated pysolar --conda -- (so not an old one) and I get the error:
pysolar/time.py:105: UserWarning: I don't know about leap seconds after 2015
(leap_seconds_base_year + len(leap_seconds_adjustments) - 1)

I am looking for some data for 2016 and 2017.
I read the other posts about the issue but I did not get how to solve the problem.
( I am not a professional coder)

Can you explain me in some simple way how to solve this problem?

Version 0.6
pysolar.solar.get_azimuth(48.248282,16.356357,datetime.datetime(2015,2,6,9,0,0,0))
returns -326.96819097903847
which seems quite odd.

What is wrong use UTC ?

Could you explain why it is naive to use datetime in UTC?

I always use UTC (or unix epoch timestamp) for my server Apps because of so many different time zones and daylight savings.

Thanks!
Mike,

It looks like ReadTheDocs has changed the way they talk to Github, so the docs at docs.pysolar.org aren't getting updated automatically any more.

Note that
http://docs.pysolar.org/en/latest/_images/reference_frame.png
is not the same as
https://github.com/pingswept/pysolar/blob/master/doc/img/reference_frame.png
but they should be identical.

In the current release 0.6, tar files for release 0.5 and 0.6alpha are in the dists directory. This is probably not intencional.

Besides issue #75, azimuth's documentation seems at odds with the program: it says south is zero, but retrieving the azimuth for noon at a southern hemisphere point with solar.get_azimuth(-18.9132481, -48.2584742, noon), will give me a value around zero, but it is expected a value around 180, since sun's arc is around north for southern hemisphere.

What is the correct interpretation of the value returned by solar.get_azimuth()?

Hey, I didn't find any doc relative to the differences of these two methods. Any tips?

Also, running get_azimuth for the entire day I didn't get any negative values. Is the doc out of date?

Thanks in advance and congratulations for the cool library!

Version 0.5
Pysolar.GetAltitude(37.43,-122.17,datetime.datetime(2014,3,5,2,27)) returns 20.821778655816612 but should return a value ~ -5. Seems like a general problem with sun angles just below the horizon (In all other cases encountered GetAltitude still returned a negative number, albeit with alot of noise. Problematic for finding sunrise and sunset times. Curiously Pysolar.GetAltitude(37.43,-122.171,datetime.datetime(2014,3,5,2,27)) and Pysolar.GetAltitude(37.43,-122.169,datetime.datetime(2014,3,5,2,27)) return expected values.

UserWarning: I don't know about leap seconds after 2015

Need to update leap_seconds_adjustments and delta_t.

leap_seconds_adjustments only goes to 2015 and delta_t only goes to April 2014.

(I am using the master branch version.)

I am trying to get sunrise and sunset times in high elevations (up to 100 km above sea level). As the get_{altitude|position}() functions take an elevation argument, I would expect them to return a different value for sun altitude, based on the given elevation.

>>> import datetime
>>> from pysolar import solar
>>> sunrise_time = datetime.datetime(2018,3,12,6,55,0)
>>> solar.get_position(46.95, 7.47, sunrise_time, elevation=100000)
(95.03439124507312, 0.5961510806209467)
>>> solar.get_position(46.95, 7.47, sunrise_time, elevation=0)
(95.03439124029069, 0.596183960394498)

The difference between the two altitudes is in the order of 3e-5 and thus much less than expected. What is the elevation parameter and how could I get the sun altitude in arbitrary elevations?

https://github.com/python/typeshed/
You create *.pyi interface stubs that tell Python type checkers (like mypy) what interfaces to expect.
This allows all code that uses pysolar to be type checked even for library calls into pysolar.

As previously reported this method returns an error:

This fails using

import pysolar
import datetime

az=pysolar.solar.get_azimuth_fast(48, 14, datetime.datetime(2015, 3, 10, 16, 30))
print('{}'.format(az))

The reason for there failure is the asin function is being given a value of (1.1); Which is out of bounds... This can be resolved by using %1.

The solution is to change the line in Solar.py

From:

  azimuth_rad = math.asin(math.cos(declination_rad) * math.sin(hour_angle_rad) / math.cos(altitude_rad))

To:
azimuth_rad = math.asin( (math.cos(declination_rad) * math.sin(hour_angle_rad) / math.cos(altitude_rad))%1)

I have not checked to see if this may occur in the get_azimuth method.

I installed pysolar 0.7 via pip on raspberry 2B running on arch linux
by trying the examples like given in the documentation I got different results

[alarm@alarmpi ~]$ python3
Python 3.6.3 (default, Oct 30 2017, 14:58:21) 
[GCC 7.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from pysolar.solar import *
>>> import datetime
>>> d = datetime.datetime(2007, 2, 18, 15, 13, 1, 130320)
>>> print (d)
2007-02-18 15:13:01.130320
>>> get_altitude(42.206, -71.382, d)
30.91446827139096

the value from the documentation is 20.374937135509537 can you help me to bugfix this?
Thank you in Advance

In the function description it is stated "On average the extraterrestrial irradiance
is 1367 Watts/meter2 (W/m2). This value varies by + or - 3 percent as the earth orbits the sun."

I get a value of around -211.

ZA = math.sin(latitude_deg) * math.sin(decl) + math.cos(latitude_deg) * math.cos(decl) * math.cos(ha)

latitude_deg, decl as well ha are in degrees while math.sin / math.cos expect radians.

Package Versions: Python 2.7.5+, Pysolar 0.6

I was working through your examples for retrieving the radiation with solar.radiation.GetRadiationDirect(), but the call failed with "NameError: global name 'solar' is not defined". This is due to referencing day = solar.GetDayOfYear(utc_datetime) in GetRadiationDirect while not having imported the module (doing so would create a circular import between radiation.py and solar.py.)

I'd be happy to code up a fix and submit a pull request if you like. Otherwise if you need further information please ask. This is a great utility and I'm considering using it in my work with atmospheric correction. Thanks!

David

Could you open a dev branch and then I'll make the pull request to that if you will.
I have many changes that should not just be blindly merged. Mine is still in dev so is not yet
complete. My refactoring left two test failing and I may need help to fix them. Thanks.
I'm finding ways to make this package more accurate. Since I got into this one of my starting points
was this site and I just read the source code. LONG-TERM ALMANAC FOR SUN, MOON, AND POLARIS V1.11
Then this one sort of reminds me of that but I can't see any source code and it leaves a few things to be desired. MIDC SPA Calculator
One of the things that bugged me enough to even work on this was the pylint extension for VS-Code editor from Microsoft. Yes I'm on Windows.

when i am running the codes , its showing "ImportError: No module named pysolar".

When I look at 80N 0E at the summer solstice vs 80S 0E at the winter solstice, I get 746 vs 955 W/m^2, which seems weird.

Fri Dec 21 12:00:00 2018 +0000 Winter solstice at 80S: 33.4563051296 deg 955.544296665 W/m^2 distance= 0.983705043957
Thu Jun 21 12:00:00 2018 +0000 Summer solstice at 80N: 33.4587699932 deg 746.293140683 W/m^2 distance= 1.01623557581

I iterated around those times and verified that the sun is at the same elevation and that it's the local maximum, and even checked the earth-sun distance. Neither of those seem like they should account for such a large difference in irradiance. Are you modeling the ozone hole or something?

Test code:

from pysolar import solar
from pysolar import solartime
import datetime

def get_jme(when):
  jde = solartime.get_julian_ephemeris_day(when)
  jce = solartime.get_julian_ephemeris_century(jde)
  jme = solartime.get_julian_ephemeris_millennium(jce)
  return jme

winter_solstice = datetime.datetime(2018, 12, 21, 12, 0, tzinfo=datetime.timezone.utc)
solar_angle = solar.get_altitude(-80, 0.0, winter_solstice)
irradiance = solar.radiation.get_radiation_direct(winter_solstice, solar_angle)
distance = solar.get_sun_earth_distance(get_jme(winter_solstice))

print(winter_solstice.strftime("%c %z"), "Winter solstice at 80S:", solar_angle, "deg", irradiance, "W/m^2", "distance=", distance)

summer_solstice = datetime.datetime(2018, 6, 21, 12, 0, tzinfo=datetime.timezone.utc)
solar_angle = solar.get_altitude(80, 0.0, summer_solstice)
irradiance = solar.radiation.get_radiation_direct(summer_solstice, solar_angle)
distance = solar.get_sun_earth_distance(get_jme(summer_solstice))

print(summer_solstice.strftime("%c %z"), "Summer solstice at 80N:", solar_angle, "deg", irradiance, "W/m^2", "distance=", distance)

Here is an extract of sun azimuth calculations (timestamp|degrees):

'1279857320|-0.617365306042',
'1279857380|-0.483246056623',
'1279857441|-0.34956044612',
'1279857500|-0.217891106545',
'1279857560|-0.0855178728581',
'1279857599|-2.36529300635e-05',
'1279857650|0.113225187247',
'1279857738|0.310546239613',
'1279857783|0.41395730595',
'1279857848|0.563095328235',
'1279857891|0.662896534982',

at timestamp 1279857599 I get a wrong result. If you want I can give you (in private) lat/long for that results.

Bug or my fault :) ?

tnx

Is there a preferred citation for the package? I'm using this package for my senior thesis and would like to properly cite it in my paper. I couldn't find it in the documentation (sorry if I missed it). Github has a really nice guide https://guides.github.com/activities/citable-code/ on making a DOI for a repository.

Thanks for the awesome work!