# Differences between alt/az in Stellarium and Astropy

I've just started to learn Astropy. It's a nifty tool. Using some tutorials, I wrote and then made modifications to a little script that finds the Alt/Az of an object at a certain place and time. I then checked Stellarium's calculation for the Alt/Az of the same object (at exactly the same place and time) and found it to be slightly different. I suspected this was due to slight differences in the underlying coordinates, so I tried manually hard coding the coordinate data for the star from Stellarium; it still came out different. Here is the data without the hard coding:

Object: Rasalhague (alf Oph)
Time: 2018-08-28 23:00 (converted to universal in the script)
Latitude: 35
Longitude: -79
Stellarium reported Az/Alt: +247 35 12.3 / +48 00 57.8
Astropy reported Az/Alt: +247 35 37.4939s / +48 00 08.7586


Manually coding:

RA/Dec on date from Stellarium: 17 35 48.82, +12 32 55.9
Astropy reported Az/Alt: +247 22 42.0379 / +48 09 43.0755


I'm guessing that the difference stems from the conversion algorithm to alt/az.

• Did you verify the conversion to Zulu (or Universal) gave the same time as Stellarium uses? Aug 24, 2018 at 17:13
• stackoverflow.com/questions/16293146/… may or may not be helpful.
– user21
Aug 24, 2018 at 19:16
• @CarlWitthoft Yes, the time is the same. Aug 25, 2018 at 0:20
• Among the things that can cause this are 1) precession (different equinox) 2) Aberration (due to Earth's finite speed vs speed of light) 3) refraction (but at alt=-12 degrees you are looking through stone, not atmosphere). Things that are too small to be the cause of this are a) proper motion (at the arcsec level) b) parallax (sub-arcsecond). The 'manual coding' result has a size consistent with precession. Try the calculation on Jan 1, 2000 and see whether things match up. Aug 25, 2018 at 16:31
• @DMPalmer Thanks for your comment. I have tried setting the starting RA/DEC to FK5 with an equinox of J2000.0. It didn't bring it in line with Stellarium. Aug 26, 2018 at 3:29

Perhaps the difference stems from the conversion algorithm?

Almost certainly this is the answer. It's not clear to me exactly what Stellarium assumes for is refraction calculation, but I know Astropy's algorithm. Given that the altitude you've listed here is below the horizon (i.e., alt is negative), it's not really clear what the correct interpretation is: in particular, atmospheric refraction is not really well-defined below the horizon (since it should be invisible anyway!).

Additionally, even well above the horizon where refraction isn't that important, there are several finicky details that you have to account for to properly do the Az/Alt conversions. In addition to the precession that the other answers mention, if you want to get exactly the same answer on two tools, you have to worry about things like how much the axis of the Earth shifts due to, say, major earthquakes ("true polar wander"), the effects of General Relativity on the apparent direction of the incoming light ,etc. Most of these are pretty small, but together they mean it's very hard to ensure all of the software gives exactly the same answer unless they carefully follow the definitions set by the International Astronomical Union.

That said, the differences you see are only ~20 arcsec. The human eye isn't even capable of telling that small of a difference, and almost all telescopes that people would use Stellarium with probably wouldn't either (at least in an absolute sense). So for this particular application they essentially do match.

• Thanks for your reply. I've modified the example I gave to make both Az and Alt positive numbers. Do you know which reference frame Stellarium is using for its coordinates? I think I read somewhere that the Hipparchos catalog might have its own custom frame associated with it... perhaps that's part of the difficulty. Aug 29, 2018 at 3:34

The alt/az coordinates will change as the object moves, and are relative to the observing position. Both programs will need to be configured with the exact same time, latitude, longitude, and altitude. If you want to compare the two, you have to get get readings at precisely the same time.

Even then, it's possible for variation if they are not using the same epoch. If one is using J2000 and another J1950 or J2050, then there will be differences. It might be possible for one or the other to calculate precessional differences to provide something closer to exact coordinates.

• Hi, thanks for your reply. I can confirm that I'm using exactly the same time, latitude, longitude, and altitude for my script in Astropy and my settings in Stellarium. I believe Astropy defaults to ICRS; I tried converting the RA/DEC into FK5 to see if that was closer to Stellarium, and it didn't make up for the difference. Aug 25, 2018 at 0:19

The apparent alt/az position of a star in the night sky depends not only on its underlying equatorial coordinates and position/time of your interest, but also from other conditions which may or may not be accounted for by the one or the other software, depending on how you have configured the software.

One simple example for those conditions would be the atmospheric refraction. Its effect on the apparent alt/az position of a start is: the lower the object is above the horizon, the higher altitude it seems to have.

Since we don't know your script exactly and since you're saying that you've just started learning AstroPy, it could well be that you haven't configured both software with the same conditions for the alt/az calculation algorithm.

• Hi, thanks for your reply. All of the basic parameters for the Alt/Az calculation are the same across both tools. Your point about other concerns (like atmospheric refraction) is something I didn't consider. I'll have to research how to update my script accordingly. Aug 25, 2018 at 0:27