How to calculate Local siderial time that is consistent with Stellarium

Question

I have a number of date and times when I am interested in the location of my zenith and what objects might co-locate with these positions. The easiest way to do this was to put my latitude and longitude into Stellarium and create a bookmark at the North position of the azimuthal grid for each date/time. Stellarium will then give the Ra/Dec J2000 for the bookmark if required. This was ok for a low number of data points but now I have more than 3000 so I used information from this post Local Sidereal Time to calculate LST for all my date and times in Excel. I then loaded all the LST values into a json file and opened them as stellarium bookmarks. The problem is that all the values I calculate are displaced about 50 seconds from positions of stellarium markers based on the same date and time. Consequently there is too large an uncertainty to be sure whether my zeniths are coinciding with anything on Stellarium.

I used the following for my calculations:

LST= 100.4606184+(0.9856473662862 * Julian day)+Long+(decimal UT * 15)

Julian Day number = 367y-INT(7(y+INT((m+9)/12))/4)+INT(275*m/9)+day-730531.5 + ((h + mins/60 + seconds/3600)/24)

The JDN formula came from http://www.stargazing.net/kepler/altaz.html , That website also contains example values which I used as a guide to get my calculations nearly right. The result of the LST calculation was divided MOD.360 I then had to divide by 15 to make it recognisable - which I dont understand as it seems the LST calculation outputs degrees.

In case anyone else is looking to convert degrees to format suitable for json file I did this: starting with separate hour, minute, second columns I used the following excel formula to compile into a column that did not eliminate leading zeros =TEXT(A1,"#00")&TEXT(A2,"#00")&TEXT(A3,"#00.0") I had to make the minutes column an integer otherwise excel rounded it up if the decimals went over 0.5

Then I used this formula to insert the hms text =(REPLACE(REPLACE(A4,3,0,"h"),6,0,"m"))&"s" to give the final format 02h27m13.2s suitable for the Stellarium bookmarks json file.

In options I have set excel to "set precision as displayed" with 8 decimal places in the cells and eliminated any rounding errors I could find. For a starting date of 24/10/2019 00:29:16 my calculation gave 02h27m13.2s and a Stellarium bookmark at the zenith at that time gave 02h26m08.5s

Does anyone have experience of this problem, could suggest where to look next to solve it or spot my mistake?

Answer 1

There has been a wry saying about IT people, that 'they love standards, and that's why there are so many of them': unfortunately something of the same is increasingly true of astronomical standards. So I sympathize with you in your problem, which seems basically due to (a) the number of different astronomical time standards which are (or have recently been) in use, and (b) the fact that people who apply those standards often do not specify full details of what they are using, and where its parts have come from.

As far as I can see, there's a kind of 'gold standard' of definiteness and clarity in specifying these things. Perhaps at the moment it's a joint gold standard between first, 'SOFA' (www.sofa.org), the IAU's website for 'standards of fundamental astronomy', which is pretty complete although intricate (and something of a plus is that it identifies and supplies both present and recent-past standards); and second, the US Naval Observatory's 'Astronomical Almanac' (with current data distributed, a bit less conveniently, between (in part) hard-copy, and (also in part) in the Astronomical Almanac Online).

Turning to the details of your problem, it takes some work to find out (a) what standard your formulae belong to and (b) what standard is in use by the current 'Stellarium' software.

As for (a), after a bit of searching and calculating, it appears to me that your formulae are a slightly rounded set otherwise matching the 1982 standard for GMST -- which is two standards ago by now. Its details (in other units than those you have used) are given for example here, and at Explanatory Supplement to the Astronomical Almanac (1992) at p.50, sec.2.24. This standard came into force in 1984, and has since been superseded by later standards of 2000 (Gmst00) and 2006 (Gmst06). You can see them all among others here at SOFA earth-rotation page.

As for (b) I did not yet succeed in identifying the GMST standard in use by Stellarium. (That's not a negative criticism, btw: Stellarium is an evolving software system, its original purpose (according to the user guide) was "to present a beautiful simulation of the night sky, mostly to understand what is visible in the sky when you leave your house, i.e., for present times". Later on, its developers, appreciating a demand for greater accuracy, began a program of "retrofitting detailed and accurate models", which "has only recently (2021) come to a state where we as developers are beginning to be satisfied".) It's always hard for documentation to keep up, and maybe it has, but I couldn't find a statement of the standards they currently use.

It seems to me that in your current search for accuracy there are two basic approaches either of which you can use.

(1) You could try a largely empirical approach, first applying to your present GMST values the (time-dependent) difference mentioned by Greg Miller between apparent and mean sidereal time (used to be known as 'equation of the equinoxes' or 'nutation in RA' (see the SOFA website given above), its largest term depends on the longitude of the moon's ascending node). If there is any serious residue after that, you could try modeling how the residue behaves for the range of dates in which you are interested, and then apply the result as an empirical correction.

(2) You could try a more fundamental approach: e.g. try each of the likely combinations given by the SOFA software website and see how it fits, and/or ask the Stellarium developers if they can tell you which standards they currently adopt, and use those.

I'd suggest also that it's likely to be easier in the end if your code reproduces whatever standards you adopt, in exactly the same units and numbers as those in which the authoritative source is expressed, and if you then carry out any units-conversions called for by your application in separate operations. This makes it much easier and quicker to cross-check, proof-read your code and calculations, etc, by comparison with original sources, and the extra processing-time entailed in carrying out the calculations is a very tiny amount.

Also, for processing your dates, it's a help if you adopt exactly an authoritative source for your date-conversions, e.g. the Julian-day conversions from the ESAA 1992, given in the page-images reproduced here. This helps to avoid or clarify doubts over such things as offsets of 12h, whether an interval is to be measured in UT or in sidereal time, &c.

Good luck!