'PyEphem returning inconsistent right ascension and declination from horizontal coordinates
I have been using PyEphem for a while now and recently an issue was opened on my software in which the calculated declination wasn't constant, despite the altitude on the local horizon being constant. I would imagine, that the declination would be constant as long is the altitude on the local horizon is also constant with only the right ascension changing?
I'm using the radec_of()
function together with a observer class created from the lat/lon coordinates, elevation and preassure set to 0.
self.QTH.lat = str(lat)
self.QTH.lon = str(lon)
self.QTH.pressure = 0
self.QTH.elevation = 0
And my function that returns the equatorial coordinates from local/horizontal coordinates.
# Returns equatorial coordinates
def equatorial(self):
ra, dec = self.QTH.radec_of(str(self.az), str(self.alt))
return round(ra / degree, 1), round(dec / degree, 1)
In my code, the user can choose a specific interval in degrees (RA) to exectute the program for the next 24 hours. My expected output would be a constant declination and a right ascension increasing by the interval the user has chosen. For example if the interval is 4, then the expected output would be something like the following:
ra=100.1, dec=40.5
ra=104.1, dec=40.5
ra=108.1, dec=40.5
ra=112.1, dec=40.5
...
But instead the output is like the following, where changing coordinates are marked with "**"
18.05.21 16:37:00 805465 ra=102.8,dec=48.0.png
18.05.21 16:53:00 807480 ra=106.8,dec=48.0.png
18.05.21 17:09:00 801372 ra=110.8,dec=48.0.png
18.05.21 17:25:00 803262 ra=114.8,dec=48.0.png
18.05.21 17:41:00 799578 ra=118.8,dec=48.1.png
18.05.21 17:57:00 804559 ra=122.9,dec=48.1.png **
18.05.21 18:13:00 807459 ra=126.9,dec=48.1.png
18.05.21 18:29:00 808064 ra=130.9,dec=48.1.png
18.05.21 18:45:00 810290 ra=134.9,dec=48.1.png
18.05.21 19:01:00 806551 ra=138.9,dec=48.1.png
18.05.21 19:17:00 809136 ra=143.0,dec=48.1.png **
18.05.21 19:33:00 808622 ra=147.0,dec=48.1.png
18.05.21 19:49:00 806295 ra=151.0,dec=48.1.png
18.05.21 20:05:00 807896 ra=155.0,dec=48.1.png
18.05.21 20:21:00 809402 ra=159.0,dec=48.1.png
18.05.21 20:37:00 810583 ra=163.0,dec=48.1.png
18.05.21 20:53:00 805021 ra=167.1,dec=48.1.png **
18.05.21 21:09:00 797692 ra=171.1,dec=48.1.png
18.05.21 21:25:00 807645 ra=175.1,dec=48.1.png
18.05.21 21:41:00 805415 ra=179.1,dec=48.1.png
18.05.21 21:57:00 804573 ra=183.1,dec=48.1.png
18.05.21 22:13:00 806138 ra=187.2,dec=48.1.png **
18.05.21 22:29:00 804337 ra=191.2,dec=48.1.png
18.05.21 22:45:00 808220 ra=195.2,dec=48.1.png
18.05.21 23:01:00 808257 ra=199.2,dec=48.1.png
18.05.21 23:17:00 802124 ra=203.2,dec=48.1.png
18.05.21 23:33:00 807289 ra=207.3,dec=48.1.png **
The command used to produce the values above is the following:
python3 H-line.py -n 50000 -i 4 -c
Keep in mind one should also have added a latitude/longitude and altitude/azimuth coordinate on the sky in the config.txt file when running this command. At first I expected this was due to the highly accurate calculations by PyEphem also accounting for refraction, hence why I set the preassure to 0. I'm currently suspecting computation time may be the issue instead. The entire loop controlling when the code should run if an interval is given can be found in this GitHub repository if it may be of any help. The issue opened can be found here, and the coordinate function here.
EDIT: After the suggestion my Brandon Rhodes, I relocated the starting time to outside the for loop and made the end time depend only on the starting time and calculated interval between each data collection.
end_time = current_time + timedelta(seconds = second_interval * (i + 1))
time_remaining = end_time - datetime.utcnow()
This way I would expect the RA to increase by a constant amount each time, but I still get the following results:
07/06/2021 05:32 PM 1,004,512 ra=122.8426,dec=14.5368.png
07/06/2021 05:48 PM 974,403 ra=126.8922,dec=14.5436.png
07/06/2021 06:04 PM 979,557 ra=130.8667,dec=14.5499.png
07/06/2021 06:20 PM 974,845 ra=134.8789,dec=14.5559.png
07/06/2021 06:36 PM 981,583 ra=138.8912,dec=14.5615.png
07/06/2021 06:52 PM 975,283 ra=142.9035,dec=14.5666.png
07/06/2021 07:08 PM 984,823 ra=146.9160,dec=14.5713.png
07/06/2021 07:24 PM 1,000,268 ra=150.9285,dec=14.5756.png
07/06/2021 07:40 PM 998,461 ra=154.9410,dec=14.5793.png
07/06/2021 07:56 PM 994,188 ra=158.9536,dec=14.5825.png
07/06/2021 08:12 PM 978,760 ra=162.9662,dec=14.5852.png
07/06/2021 08:28 PM 983,823 ra=166.9789,dec=14.5873.png
07/06/2021 08:44 PM 998,307 ra=170.9916,dec=14.5889.png
07/06/2021 09:00 PM 980,310 ra=175.0042,dec=14.5899.png
*note that the declination is also changing, which I would expect it not to.
I now begin to think that initiating a new observer each time the for loop runs could cause the issue?
for i in range(num_data + 1):
# Get current equatorial and galactic coordinates of antenna RA and Declination
Coordinates_class = Coordinates(lat = lat, lon = lon, alt = alt, az = az)
ra, dec = Coordinates_class.equatorial()
I hope someone can help me. Thanks in advance!
Solution 1:[1]
I would like to add a reply to my own question, despite it being almost a year old. However, looking back at this question today I found the answer I was looking for! TL;DR, nothing is wrong with the numbers PyEphem is giving me!
The key thing to understand here, is that I'm giving PyEphem a timestamp from the datetime package, where one day is 24 hours. However, upon further inspection I noticed the right ascension after 24 hours was 1 degree larger than the day before. drum roll... sidereal time!!! This means PyEphem is, not suprisingly, right :)
Not many are likely going to benifit from this, but I thought I'd share my answer anyways!
Solution 2:[2]
Is it possible that your starting time is inching slowly forward because you are recomputing the start time with each loop? It might be useful to move this line of code outside of your for
loop:
current_time = datetime.utcnow()
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
Solution | Source |
---|---|
Solution 1 | Victor Boesen |
Solution 2 | Brandon Rhodes |