<p>Thanks to @GregMiller for pointing me to his <a href="https://celestialprogramming.com/risesetalgorithm.html" rel="nofollow noreferrer">website</a> that has the formulas I needed.</p>
<p><a href="https://i.sstatic.net/35r4X.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/35r4X.png" alt="enter image description here" /></a></p>

CC BY-SA 4.0
2023-10-26T21:37:06.400Z
Congratulations, problem solved! But to make this a proper Stack Exchange answer, please *add the formula here* or at least an explanation of it. "The answer is in this link" is called a link-only answer and these are not considered good answers because they're not answers. They require each reader to go offsite to actually find the answer, and if/when the link breaks they become totally useless. *Thanks!*
uhoh
CC BY-SA 4.0
2023-10-26T19:06:44.973Z
2023-10-27T22:36:53.223Z
2023-10-27T22:36:53.223Z
BillR
<p>I'm trying to develop an Excel macro to compute when a target will rise above a specified altitude given the date and location.  I can get the correct answer with Stellarium and using a Python program I wrote that leverages the PyEphem library, but for some reason I cannot get the right answer when I try to implement the calculations myself using Excel.  I'm hoping someone can point out the error of my ways.</p>
<p>These are the input variables:</p>
<p>Date: 10/18/2023</p>
<p>Altitude: 30°</p>
<p>Target: M74</p>
<pre><code>RA:   01:36:43.1
Dec:  +15° 47' 08&quot;
</code></pre>
<p>Location:</p>
<pre><code>Lat:  32° 36' 50&quot;
Long: -116° 20' 01&quot;
</code></pre>
<p>According to Stellarium and the Python program using PyEphem, the correct answer is 20:16:55 PDT (03:16:55 UTC the following day).  But I cannot arrive at the same answer and don’t know where I’m going wrong.</p>
<p>As I understand it, the steps are as follows:</p>
<ol>
<li><p>Compute the LHA</p>
<p>Cos(LHA) = [SIN(Alt) - SIN(Lat) * SIN(Dec)] / (COS(Lat) * COS(Dec))</p>
<p>Cos(LHA) =[0.5 - 0.538974977 * 0.272037656] / (0.842321776 * 0.962286607)</p>
<p>Cos(LHA) = 0.435971065</p>
<p>LHA = Acos(0.435971065) = 1.119679324 rad = 64.2° = 4.276860089 hours = 04:16:37</p>
<p>This result is close to the LHA for M74 in the western sky according to Stellarium (04:16:54).  Subtracting that value from 2*Pi to get the LHA when M74 is in the eastern sky, we get:</p>
<p>5.163505973 rad = 295.8° = 19.72 hours = 19:43:23 (Stellarium has 19:43:05)</p>
<p>I’m not sure why there is a difference of 17-18 seconds, but it’s close enough that I’m comfortable with the answer.</p>
</li>
<li><p>Compute the LST</p>
<p>LST(E) = LHA(E) + RA = 5.163505973 + 0.422013334 = 5.585519307 rad = 320.0° = 21.34 hours = 21:20:06</p>
<p>Stellarium has 21:20:58.5 for the Apparent Sidereal Time so the difference is now 52 seconds, but again, it seems close enough to be on the right track.</p>
</li>
<li><p>Compute the GMST</p>
<p>GMST(E) = LST(E) – Long = 5.585519307 – (-2.03040451) = 7.61592393525783</p>
<p>That value is greater than 2<em>Pi; do I need to subtract 2</em>Pi or leave it as is?</p>
</li>
<li><p>Then, using the Meeus formulas, we have:</p>
<p>JD0 = 2460235.5 (for 10/18/2023)</p>
<p>T = (JD0 - 2451545) / 36524.22 = 0.237938003877975</p>
<p>UT = (GMST(E-hours) - 6.697374558 - 2400.051336 * T - 0.000025862 * (T * T)) / 1.0027379093</p>
<p>UT = -547.172006240208  Mod 24 = 4.82799375979209 = 04:49:41</p>
<p>LT (PDT) = UT – 7 = 21:49:41</p>
<p>That answer is incorrect by over 1-1/2 hours; Stellarium and PyEphem both show the correct time should be 20:16:54 PDT</p>
</li>
</ol>
<p>It appears that the calculations are correct through Step 3, but it goes awry sometime during Step 4.  Can anyone see where I’m getting off track?</p>

CC BY-SA 4.0
2023-10-20T20:24:16.847Z
For Step 1: difference might be precession/nutation - are you coordinates for M74 ICRS/J2000 ones or not ?  In Step 3: Yes, you need to normalize this into the range 0...2PI
astrosnapper
CC BY-SA 4.0
2023-10-20T21:15:35.400Z
The M74 coordinates are J2000. If I normalize the GMST values into the range of 0 to 2*PI in the results only change by ~4 minutes, so I'm doing something wrong elsewhere...
BillR
CC BY-SA 4.0
2023-10-21T04:34:43.550Z
Since you have the Meeus book, use the Rise, Set, Transit algorithm, but set $ h_0 $ to the alt you want.
Greg Miller
CC BY-SA 4.0
2023-10-21T10:27:05.200Z
@uhoh I did it.
Snack Exchange
CC BY-SA 4.0
2023-10-21T16:48:59.333Z
@GregMiller - I don't have the book.  I've just done a lot of Internet searches on the subject and thought I had the right equations based on what I've read.  I was hoping someone could point out what I have wrong.
BillR
CC BY-SA 4.0
2023-10-21T18:52:40.850Z
The equations are here: https://celestialprogramming.com/risesetalgorithm.html
Greg Miller
CC BY-SA 4.0
2023-10-22T16:44:32.860Z
@GregMiller - Thanks for that reference.  I decided to try something simple and just compute the meridian transit using those equations but am still not getting the right answer.  One problem I encountered is that the web site appears to assume west longitude as a positive value, is that correct?  Because if I enter a negative value for my west longitude, the result isn't anywhere near close to being correct.  But if I enter it as a positive value, the calculator yield precisely the correct answer. But when I use the equations to compute the transit time, the result is ~30 minutes off.
BillR
CC BY-SA 4.0
2023-10-22T16:53:25.287Z
Using the values in the OP:
JD0 = 2460235
T = (JD0 - 2451545) / 36525 = 0.237932922655715
Theta0 = 3137426.22907707 % 360 = 26.2290770742111
Transit(deg) = 359.648 = 23.976 hours = ~23:58:34
But the correct transit time is 00:37:08, about 40 minutes later.  I can't figure out what I'm doing wrong.
BillR
CC BY-SA 4.0
2023-10-26T15:24:59.417Z
@GregMiller - I think I found the problem.  There appears to be an error with one of the formulas on that website you referenced.  It shows transit = (Dec + Long - GMST)/360, but in your C source code, you have transit - (RA + Long - GMST)/360.  When I use RA instead of Dec in that equation, I get the right answer.
BillR
<ephemeris>
Formula to Determine When a Target Reaches a Specific Altitude
BillR
# Formula to Determine When a Target Reaches a Specific Altitude

(Asked by: username_0 on 2023-10-20)

I'm trying to develop an Excel macro to compute when a target will rise above a specified altitude given the date and location.  I can get the correct answer with Stellarium and using a Python program I wrote that leverages the PyEphem library, but for some reason I cannot get the right answer when I try to implement the calculations myself using Excel.  I'm hoping someone can point out the error of my ways.
These are the input variables:
Date: 10/18/2023
Altitude: 30°
Target: M74
RA:   01:36:43.1
Dec:  +15° 47' 08"

Location:
Lat:  32° 36' 50"
Long: -116° 20' 01"

According to Stellarium and the Python program using PyEphem, the correct answer is 20:16:55 PDT (03:16:55 UTC the following day).  But I cannot arrive at the same answer and don’t know where I’m going wrong.
As I understand it, the steps are as follows:

Compute the LHA
Cos(LHA) = [SIN(Alt) - SIN(Lat) * SIN(Dec)] / (COS(Lat) * COS(Dec))
Cos(LHA) =[0.5 - 0.538974977 * 0.272037656] / (0.842321776 * 0.962286607)
Cos(LHA) = 0.435971065
LHA = Acos(0.435971065) = 1.119679324 rad = 64.2° = 4.276860089 hours = 04:16:37
This result is close to the LHA for M74 in the western sky according to Stellarium (04:16:54).  Subtracting that value from 2*Pi to get the LHA when M74 is in the eastern sky, we get:
5.163505973 rad = 295.8° = 19.72 hours = 19:43:23 (Stellarium has 19:43:05)
I’m not sure why there is a difference of 17-18 seconds, but it’s close enough that I’m comfortable with the answer.

Compute the LST
LST(E) = LHA(E) + RA = 5.163505973 + 0.422013334 = 5.585519307 rad = 320.0° = 21.34 hours = 21:20:06
Stellarium has 21:20:58.5 for the Apparent Sidereal Time so the difference is now 52 seconds, but again, it seems close enough to be on the right track.

Compute the GMST
GMST(E) = LST(E) – Long = 5.585519307 – (-2.03040451) = 7.61592393525783
That value is greater than 2Pi; do I need to subtract 2Pi or leave it as is?

Then, using the Meeus formulas, we have:
JD0 = 2460235.5 (for 10/18/2023)
T = (JD0 - 2451545) / 36524.22 = 0.237938003877975
UT = (GMST(E-hours) - 6.697374558 - 2400.051336 * T - 0.000025862 * (T * T)) / 1.0027379093
UT = -547.172006240208  Mod 24 = 4.82799375979209 = 04:49:41
LT (PDT) = UT – 7 = 21:49:41
That answer is incorrect by over 1-1/2 hours; Stellarium and PyEphem both show the correct time should be 20:16:54 PDT


It appears that the calculations are correct through Step 3, but it goes awry sometime during Step 4.  Can anyone see where I’m getting off track?

**Tags:** ephemeris
> **Comments:**
> **username_1**: For Step 1: difference might be precession/nutation - are you coordinates for M74 ICRS/J2000 ones or not ?  In Step 3: Yes, you need to normalize this into the range 0...2PI  
> **username_0**: The M74 coordinates are J2000. If I normalize the GMST values into the range of 0 to 2*PI in the results only change by ~4 minutes, so I'm doing something wrong elsewhere...  
> **username_2**: Since you have the Meeus book, use the Rise, Set, Transit algorithm, but set $ h_0 $ to the alt you want.  
> **username_3**: @uhoh I did it.  
> **username_0**: @GregMiller - I don't have the book.  I've just done a lot of Internet searches on the subject and thought I had the right equations based on what I've read.  I was hoping someone could point out what I have wrong.  
> **username_2**: The equations are here: https://celestialprogramming.com/risesetalgorithm.html  
> **username_0**: @GregMiller - Thanks for that reference.  I decided to try something simple and just compute the meridian transit using those equations but am still not getting the right answer.  One problem I encountered is that the web site appears to assume west longitude as a positive value, is that correct?  Because if I enter a negative value for my west longitude, the result isn't anywhere near close to being correct.  But if I enter it as a positive value, the calculator yield precisely the correct answer. But when I use the equations to compute the transit time, the result is ~30 minutes off.  
> **username_0**: Using the values in the OP: JD0 = 2460235 T = (JD0 - 2451545) / 36525 = 0.237932922655715 Theta0 = 3137426.22907707 % 360 = 26.2290770742111 Transit(deg) = 359.648 = 23.976 hours = ~23:58:34 But the correct transit time is 00:37:08, about 40 minutes later.  I can't figure out what I'm doing wrong.  
> **username_0**: @GregMiller - I think I found the problem.  There appears to be an error with one of the formulas on that website you referenced.  It shows transit = (Dec + Long - GMST)/360, but in your C source code, you have transit - (RA + Long - GMST)/360.  When I use RA instead of Dec in that equation, I get the right answer.  

---

## 1 answers

### Answer by username_0 on 2023-10-26. Score: 1

Thanks to @GregMiller for pointing me to his [website](https://celestialprogramming.com/risesetalgorithm.html) that has the formulas I needed.

[![enter image description here](https://i.sstatic.net/35r4X.png)](https://i.sstatic.net/35r4X.png)

> **Comments:**
> **username_4**: Congratulations, problem solved! But to make this a proper Stack Exchange answer, please *add the formula here* or at least an explanation of it. "The answer is in this link" is called a link-only answer and these are not considered good answers because they're not answers. They require each reader to go offsite to actually find the answer, and if/when the link breaks they become totally useless. *Thanks!*  

---

