<blockquote>
  <p>Perhaps the difference stems from the conversion algorithm?</p>
</blockquote>

<p>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, <a href="https://en.wikipedia.org/wiki/Atmospheric_refraction" rel="nofollow noreferrer">atmospheric refraction</a> is not really well-defined below the horizon (since it should be invisible anyway!).</p>

<p>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 <em>exactly</em> 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 <em>exactly</em> the same answer unless they carefully follow the definitions set by the International Astronomical Union.</p>

<p>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 <em>this particular application</em> they essentially do match.</p>

CC BY-SA 4.0
2018-08-29T03:34:15.537Z
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.
Alphecca
CC BY-SA 4.0
2018-08-27T20:30:51.120Z
2018-08-27T22:42:38.357Z
2018-08-27T22:42:38.357Z
eteq
<p>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.</p>

<p>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.</p>

CC BY-SA 4.0
2018-08-25T00:19:06.203Z
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.
Alphecca
CC BY-SA 4.0
2018-08-24T18:11:00.910Z
2018-08-24T18:11:00.910Z
J.M. Haynes
<p>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.</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 4.0
2018-08-25T00:27:25.823Z
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.
Alphecca
CC BY-SA 4.0
2018-08-24T20:08:03.593Z
2018-08-25T06:06:44.643Z
2018-08-25T06:06:44.643Z
SergiusPro
<p>I've just started to learn <a href="http://www.astropy.org/" rel="nofollow noreferrer">Astropy</a>. 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 <a href="https://stellarium.org/" rel="nofollow noreferrer">Stellarium's</a> 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:</p>

<pre><code>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
</code></pre>

<p>Manually coding:</p>

<pre><code>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
</code></pre>

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

CC BY-SA 4.0
2018-08-24T17:13:18.673Z
Did you verify the conversion to Zulu (or Universal) gave the same time as Stellarium uses?
Carl Witthoft
CC BY-SA 4.0
2018-08-25T00:20:12.367Z
@CarlWitthoft Yes, the time is the same.
Alphecca
CC BY-SA 4.0
2018-08-25T16:31:29.370Z
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.
DMPalmer
CC BY-SA 4.0
2018-08-26T03:29:24.280Z
@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.
Alphecca
CC BY-SA 4.0
2018-08-27T14:40:02.427Z
Try setting the observation date to Jan 1, 2000.  Separately, try a star that's high in the sky to avoid refraction effects.
DMPalmer
<coordinate><astropy>
Differences between alt/az in Stellarium and Astropy
Alphecca
# Differences between alt/az in Stellarium and Astropy

(Asked by: username_0 on 2018-08-24)

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.

**Tags:** coordinate, astropy
> **Comments:**
> **username_1**: Did you verify the conversion to Zulu (or Universal) gave the same time as Stellarium uses?  
> **username_0**: @CarlWitthoft Yes, the time is the same.  
> **username_2**: 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.  
> **username_0**: @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.  
> **username_2**: Try setting the observation date to Jan 1, 2000.  Separately, try a star that's high in the sky to avoid refraction effects.  

---

## 3 answers

### Answer by username_3 on 2018-08-27. Score: 2 | Accepted answer

> 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](https://en.wikipedia.org/wiki/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.

> **Comments:**
> **username_0**: 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.  

---

### Answer by username_4 on 2018-08-24. Score: 0

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.

> **Comments:**
> **username_0**: 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.  

---

### Answer by username_5 on 2018-08-24. Score: 0

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.

> **Comments:**
> **username_0**: 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.  

---

