<p>If we draw a circle and draw a 315 degree angle on that circle, in the counter clockwise direction, we would roughly get the same point as when we draw an angle of 44.8 degrees in the opposite direction (the equivalent of drawing -44.8 in the same direction) because 315+45=360. There therefore does not seem to be an error in your results... Visually the two angles are the same. As for the slight inaccuracy, it may be due to floating point precision errors or measurement errors. <br>
If you want positive right ascension, all you need to do is add 360 if it is negative. Before doing that (this is general advice, it may not be important to your code), you ought to subtract the decimal part, get the remainder on dividing by 360, and re-add the decimal part. <br> Edit: The difference between GST and GMST is called the equation of time (for Grinich), and it does not grow beyond 16 minutes, so I think you can use it for estimates, but then there would be no point of rounding your results to the tenth decimal or so. I honestly don't know if there is a "GST for dummies" (normally I wouldn't post an incomplete answer, but the question was edited), but using GMST should suffice if the 16 minute error margin is acceptable. </p>

CC BY-SA 4.0
2019-02-02T15:06:25.390Z
Could you please elaborate, why is it advisable to perform calculations with the decimal part in such a way?
bitemybyte
CC BY-SA 4.0
2019-02-02T16:09:55.540Z
I am not familiar with swift, but in C++ one cannot take the modulo of a floating point integer, so i recommended that course of action.
Tosic
CC BY-SA 4.0
2019-02-02T16:21:45.373Z
Ahh I see, thank you for clarifications. Swift allows taking modulo of a float number. Could you please have a look at my updated question?
bitemybyte
CC BY-SA 4.0
2019-02-03T16:06:04.603Z
Edited. Sorry it took so long, this is the best answer I can give. Out of topic, but I highly recommend posting a new question next time instead of updating your old one to include a new topic, as it will get much more attention that way.
Tosic
CC BY-SA 4.0
2019-02-04T10:45:22.980Z
thank you very much. I thought of creating a separate question, but as the title said "geographical point" and not "right ascension" the thread would be incomplete otherwise
bitemybyte
CC BY-SA 4.0
2019-02-02T10:05:10.667Z
2019-02-03T16:02:46.150Z
2019-02-03T16:02:46.150Z
Tosic
<p>For any who might be looking for the same sort of thing, my <a href="https://astronomy.stackexchange.com/a/54663/47994">own solution</a> to <a href="https://astronomy.stackexchange.com/q/54650/47994">my question</a> does roughly what this question is asking, though the calculations are shown in TypeScript.</p>

CC BY-SA 4.0
2023-09-12T23:07:03.277Z
2023-09-12T23:07:03.277Z
Michael Bonnet
<p>I want to draw a Sun in a 3d scene, so I figured the easiest way would be to calculate the latitude and longitude of the point perpendicular to Sun position and then just move it "up".</p>

<p>As a starting point, I want to calculate it's equatorial coordinates: declination and right ascension.</p>

<p>I followed instructions from <a href="https://en.wikipedia.org/wiki/Position_of_the_Sun" rel="nofollow noreferrer">this page</a>, also cross-referencing with <a href="http://njsas.org/projects/tidal_forces/altaz/pausch/ppcomp.html#6" rel="nofollow noreferrer">this one</a></p>

<p>Here's my code (in Swift):</p>

<pre><code>import Foundation

class Astronomy {

  static func julianDays(since: Date) -&gt; Double {
    return since.timeIntervalSince1970 / 86400 + 2440587.5
  }

  static func daysSinceJ2000(for date: Date) -&gt; Double {
    return julianDays(since: date) - 2451545
  }

  static func sunAxialTilt(for daysSinceJ200: Double) -&gt; Double {
    return 23.4393 - 3.563e-7 * daysSinceJ200
  }

  static func sunEquatorialPosition(on date: Date) -&gt; (declination: Double, RA: Double, distance: Double) {
    let daysSinceGreenwichNoon = daysSinceJ2000(for: date)
    var meanLongitude = 280.460 + 0.9856474*daysSinceGreenwichNoon
    var meanAnomaly = 357.528 + 0.9856003*daysSinceGreenwichNoon
    meanLongitude = meanLongitude.rangedUpTo360
    meanAnomaly = meanAnomaly.rangedUpTo360
    let eclipticLongitude = meanLongitude + 1.915*sin(meanAnomaly.radians) + 0.020*sin(2*meanAnomaly.radians)

    let distanceToEarth = 1.00014 - 0.01671*cos(meanAnomaly.radians) - 0.00014*cos(2*meanAnomaly.radians)

    let axialTilt = sunAxialTilt(for: daysSinceGreenwichNoon)
    let rightAscension = atan2(cos(axialTilt.radians)*sin(eclipticLongitude.radians), cos(eclipticLongitude.radians))
    let declination = asin(sin(axialTilt.radians)*sin(eclipticLongitude.radians))

    return (declination: declination.degrees, RA: rightAscension.degrees, distance: distanceToEarth)
  }
}

extension Double {
  var radians: Double {
    return self * .pi / 180
  }

  var degrees: Double {
    return self  * 180 / .pi
  }

  var rangedUpTo360: Double {
    let multiples = (self/360).rounded(.down)
    return self - 360*multiples
  }
}
</code></pre>

<p>However, it does not seem to be working correctly. As of the time I write this article, the result is <code>declination -16.98772292697088, RA -44.80674952684117</code>. Compared with <a href="https://theskylive.com/sun-info" rel="nofollow noreferrer">https://theskylive.com/sun-info</a> the declination is about right (-17° 03’ 38”), but right ascension is way off:  20h 59m 43s, which is 314.93 degrees according to <a href="https://www.vercalendario.info/en/how/convert-ra-degrees-hours.html" rel="nofollow noreferrer">this site</a></p>

<p>What went wrong?</p>

<p><strong>Edit:</strong>
As it turned out nothing was wrong, I can get to the second part: calculating the geographical point. (the title suggests it after all)</p>

<p>AFAIK for <strong>latitude</strong>, I can use <em>declination</em> as is and for <strong>longitude</strong>, I 
need to calculate <em>Greenwich Hour Angle(GHA)</em></p>

<p>After examining several articles, I found these equations:</p>

<pre><code>SHA[°] = 360 – 15 · RA[h] 
GHAAries[°] = 15 · GST[h] 
GHA = SHA + GHAAries 
</code></pre>

<p>For my case, I suppose I may use RA as is, without multiplying its hour component by 15. What keeps me a bit puzzled is GST:</p>

<ol>
<li>May I use Greenwich Mean Sidereal Time instead if I don't need the calculations to be super precise?</li>
<li>Is there any "GST for dummies"? All the calculations I found rely on some floating second offset, I found <a href="ftp://maia.usno.navy.mil/ser7/ser7.dat" rel="nofollow noreferrer">this table</a> but have no idea how to use it.</li>
</ol>

CC BY-SA 4.0
2019-02-01T22:43:42.430Z
I don't think anything went wrong ... 314.93 - -44.807 is roughly 360 degrees ... meaning it's the same right ascension. The reason for slight inaccuracy likely has things to do with floating-point integer accuracy and the fact that the Sun's right ascension is very difficult to very accurately measure in practice.
Tosic
CC BY-SA 4.0
2019-02-02T06:57:54.353Z
I'm voting to close this question as off-topic because it's about coding rather than astronomy.
Chappo Hasn't Forgotten
CC BY-SA 4.0
2019-02-02T08:52:19.787Z
@Tosic ahh I see, so I have to add 360 if my resulting value would be < 0, thank you very much!
bitemybyte
CC BY-SA 4.0
2019-02-02T08:52:24.343Z
@Chappo I disagree, it is not about how to code something, but about interpreting the results, as the code is essentially math
bitemybyte
CC BY-SA 4.0
2019-02-05T01:17:43.617Z
@Chappo I also disagree with the close; a large number of formulas in astronomy require renormalization into the range 0..360 (or 0..2PI in radians). *Some* texts are good at telling you that you need to do this, some aren't. So a question that illustrates the need to renormalize quantities such as RA or GST or planetary longitudes to get the correct answer is useful IMHO.
astrosnapper
CC BY-SA 4.0
2019-02-05T01:37:03.590Z
@ethamine Not necessarily very "dummies"-like but here is [an explanation of Sidereal Time](http://star-www.rl.ac.uk/docs/sun67.htx/sun67se4.html#x193-6070003). GMST is a function of UT1, which is really a rotation angle of the Earth, rather than a time. You could add the 'UT1-UTC' value from you link to your UTC clock time in your code but the difference is kept <0.9s by leapseconds. If you add your longitude (East positive) to GMST, normalize, then subtract the RA of the Sun, you get local hour angle. Leave out the longitude and you have Greenwich Hour Angle (Hour Angle at 0deg longitude)
astrosnapper
CC BY-SA 4.0
2019-02-08T20:44:51.857Z
@astrosnapper thank you, I think I'm beginning to understand. I found [this](https://astronomy.stackexchange.com/questions/21002/how-to-find-greenwich-mean-sideral-time) question very useful. I think I might have spotted an error in my code. For calculating Julian days, I take a date, but in my code, this date is in the local timezone. Am I correct in assuming that all the dates I use, considering the goal, should be on Greenwich timezone, UTC+0?
bitemybyte
CC BY-SA 4.0
2019-02-08T21:42:04.767Z
Yes, you should be using UTC internally in your code, only converting to and from a local timezone at input (if applicable) and for display at the end. The other time you will need if you are calculating anything to do with the positions of e.g. Sun/Earth  is a Dynamical Time either TDB or TT (the steps in UTC caused by leap seconds make it unsuitable). TT is easier and good enough for almost all purposes; TT-UTC is currently 69.184s made up of TT-TAI=32.184s (fixed forever) and TAI-UTC=37s (currently; changes with leapseconds, see ftp://maia.usno.navy.mil/ser7/tai-utc.dat for past values)
astrosnapper
<the-sun><coordinate><positional-astronomy>
Geographical Point of the Sun
bitemybyte
# Geographical Point of the Sun

(Asked by: username_0 on 2019-02-01)

I want to draw a Sun in a 3d scene, so I figured the easiest way would be to calculate the latitude and longitude of the point perpendicular to Sun position and then just move it "up".
As a starting point, I want to calculate it's equatorial coordinates: declination and right ascension.
I followed instructions from this page, also cross-referencing with this one
Here's my code (in Swift):
import Foundation

class Astronomy {

  static func julianDays(since: Date) -> Double {
    return since.timeIntervalSince1970 / 86400 + 2440587.5
  }

  static func daysSinceJ2000(for date: Date) -> Double {
    return julianDays(since: date) - 2451545
  }

  static func sunAxialTilt(for daysSinceJ200: Double) -> Double {
    return 23.4393 - 3.563e-7 * daysSinceJ200
  }

  static func sunEquatorialPosition(on date: Date) -> (declination: Double, RA: Double, distance: Double) {
    let daysSinceGreenwichNoon = daysSinceJ2000(for: date)
    var meanLongitude = 280.460 + 0.9856474*daysSinceGreenwichNoon
    var meanAnomaly = 357.528 + 0.9856003*daysSinceGreenwichNoon
    meanLongitude = meanLongitude.rangedUpTo360
    meanAnomaly = meanAnomaly.rangedUpTo360
    let eclipticLongitude = meanLongitude + 1.915*sin(meanAnomaly.radians) + 0.020*sin(2*meanAnomaly.radians)

    let distanceToEarth = 1.00014 - 0.01671*cos(meanAnomaly.radians) - 0.00014*cos(2*meanAnomaly.radians)

    let axialTilt = sunAxialTilt(for: daysSinceGreenwichNoon)
    let rightAscension = atan2(cos(axialTilt.radians)*sin(eclipticLongitude.radians), cos(eclipticLongitude.radians))
    let declination = asin(sin(axialTilt.radians)*sin(eclipticLongitude.radians))

    return (declination: declination.degrees, RA: rightAscension.degrees, distance: distanceToEarth)
  }
}

extension Double {
  var radians: Double {
    return self * .pi / 180
  }

  var degrees: Double {
    return self  * 180 / .pi
  }

  var rangedUpTo360: Double {
    let multiples = (self/360).rounded(.down)
    return self - 360*multiples
  }
}

However, it does not seem to be working correctly. As of the time I write this article, the result is declination -16.98772292697088, RA -44.80674952684117. Compared with https://theskylive.com/sun-info the declination is about right (-17° 03’ 38”), but right ascension is way off:  20h 59m 43s, which is 314.93 degrees according to this site
What went wrong?
Edit:
As it turned out nothing was wrong, I can get to the second part: calculating the geographical point. (the title suggests it after all)
AFAIK for latitude, I can use declination as is and for longitude, I 
need to calculate Greenwich Hour Angle(GHA)
After examining several articles, I found these equations:
SHA[°] = 360 – 15 · RA[h] 
GHAAries[°] = 15 · GST[h] 
GHA = SHA + GHAAries 

For my case, I suppose I may use RA as is, without multiplying its hour component by 15. What keeps me a bit puzzled is GST:

May I use Greenwich Mean Sidereal Time instead if I don't need the calculations to be super precise?
Is there any "GST for dummies"? All the calculations I found rely on some floating second offset, I found this table but have no idea how to use it.

**Tags:** the-sun, coordinate, positional-astronomy
> **Comments:**
> **username_1**: I don't think anything went wrong ... 314.93 - -44.807 is roughly 360 degrees ... meaning it's the same right ascension. The reason for slight inaccuracy likely has things to do with floating-point integer accuracy and the fact that the Sun's right ascension is very difficult to very accurately measure in practice.  
> **username_2**: I'm voting to close this question as off-topic because it's about coding rather than astronomy.  
> **username_0**: @Tosic ahh I see, so I have to add 360 if my resulting value would be < 0, thank you very much!  
> **username_0**: @Chappo I disagree, it is not about how to code something, but about interpreting the results, as the code is essentially math  
> **username_3**: @Chappo I also disagree with the close; a large number of formulas in astronomy require renormalization into the range 0..360 (or 0..2PI in radians). *Some* texts are good at telling you that you need to do this, some aren't. So a question that illustrates the need to renormalize quantities such as RA or GST or planetary longitudes to get the correct answer is useful IMHO.  
> **username_3**: @ethamine Not necessarily very "dummies"-like but here is [an explanation of Sidereal Time](http://star-www.rl.ac.uk/docs/sun67.htx/sun67se4.html#x193-6070003). GMST is a function of UT1, which is really a rotation angle of the Earth, rather than a time. You could add the 'UT1-UTC' value from you link to your UTC clock time in your code but the difference is kept <0.9s by leapseconds. If you add your longitude (East positive) to GMST, normalize, then subtract the RA of the Sun, you get local hour angle. Leave out the longitude and you have Greenwich Hour Angle (Hour Angle at 0deg longitude)  
> **username_0**: @astrosnapper thank you, I think I'm beginning to understand. I found [this](https://astronomy.stackexchange.com/questions/21002/how-to-find-greenwich-mean-sideral-time) question very useful. I think I might have spotted an error in my code. For calculating Julian days, I take a date, but in my code, this date is in the local timezone. Am I correct in assuming that all the dates I use, considering the goal, should be on Greenwich timezone, UTC+0?  
> **username_3**: Yes, you should be using UTC internally in your code, only converting to and from a local timezone at input (if applicable) and for display at the end. The other time you will need if you are calculating anything to do with the positions of e.g. Sun/Earth  is a Dynamical Time either TDB or TT (the steps in UTC caused by leap seconds make it unsuitable). TT is easier and good enough for almost all purposes; TT-UTC is currently 69.184s made up of TT-TAI=32.184s (fixed forever) and TAI-UTC=37s (currently; changes with leapseconds, see ftp://maia.usno.navy.mil/ser7/tai-utc.dat for past values)  

---

## 2 answers

### Answer by username_1 on 2019-02-02. Score: 2 | Accepted answer

If we draw a circle and draw a 315 degree angle on that circle, in the counter clockwise direction, we would roughly get the same point as when we draw an angle of 44.8 degrees in the opposite direction (the equivalent of drawing -44.8 in the same direction) because 315+45=360. There therefore does not seem to be an error in your results... Visually the two angles are the same. As for the slight inaccuracy, it may be due to floating point precision errors or measurement errors.   
If you want positive right ascension, all you need to do is add 360 if it is negative. Before doing that (this is general advice, it may not be important to your code), you ought to subtract the decimal part, get the remainder on dividing by 360, and re-add the decimal part.   
 Edit: The difference between GST and GMST is called the equation of time (for Grinich), and it does not grow beyond 16 minutes, so I think you can use it for estimates, but then there would be no point of rounding your results to the tenth decimal or so. I honestly don't know if there is a "GST for dummies" (normally I wouldn't post an incomplete answer, but the question was edited), but using GMST should suffice if the 16 minute error margin is acceptable.

> **Comments:**
> **username_0**: Could you please elaborate, why is it advisable to perform calculations with the decimal part in such a way?  
> **username_1**: I am not familiar with swift, but in C++ one cannot take the modulo of a floating point integer, so i recommended that course of action.  
> **username_0**: Ahh I see, thank you for clarifications. Swift allows taking modulo of a float number. Could you please have a look at my updated question?  
> **username_1**: Edited. Sorry it took so long, this is the best answer I can give. Out of topic, but I highly recommend posting a new question next time instead of updating your old one to include a new topic, as it will get much more attention that way.  
> **username_0**: thank you very much. I thought of creating a separate question, but as the title said "geographical point" and not "right ascension" the thread would be incomplete otherwise  

---

### Answer by username_4 on 2023-09-12. Score: 0

For any who might be looking for the same sort of thing, my [own solution](https://astronomy.stackexchange.com/a/54663/47994) to [my question](https://astronomy.stackexchange.com/q/54650/47994) does roughly what this question is asking, though the calculations are shown in TypeScript.


---

