pyephem: невозможно рассчитать восход/заход солнца для полярных регионов

Я пытаюсь рассчитать восходы и закаты с помощью pyephem, но алгоритм никогда не сходится для полярных регионов?

обратите внимание на приведенный ниже пример кода. он повторяет весь год с шагом 10 минут, запрашивая следующий восход и закат. pyephem всегда возвращает сообщение об ошибке AlwaysUpError или NeverUpError, но ведь солнце обязательно должно всходить и садиться хотя бы раз в году?

import ephem
from datetime import datetime, timedelta

obs = ephem.Observer()
obs.lat = '89:30'
obs.long = '0'

start = datetime(2011, 1, 1)
end = datetime(2012, 1, 1)
step = timedelta(minutes=10)

sun = ephem.Sun()

timestamp = start
while timestamp < end:
    obs.date = timestamp

    try:
        print obs.next_rising(sun)
    except (ephem.AlwaysUpError, ephem.NeverUpError):
        pass

    try:
        print obs.next_setting(sun)
    except (ephem.AlwaysUpError, ephem.NeverUpError):
        pass

    try:
        print obs.previous_rising(sun)
    except (ephem.AlwaysUpError, ephem.NeverUpError):
        pass

    try:
        print obs.previous_setting(sun)
    except (ephem.AlwaysUpError, ephem.NeverUpError):
        pass

    timestamp += step

либо я неправильно использую API, либо ошибка в pyephem, либо я неправильно понимаю что-то фундаментальное. любая помощь?


pyephem
person mrgriscom    schedule 15.06.2011    source источник
comment
Я получаю много сотен строк вывода, когда запускаю ваш скрипт. Интересно, чем может отличаться ваша операционная система или среда, если ваша копия того же скрипта ничего не возвращает? Пожалуйста, сообщите нам, какую версию операционной системы, версию Python и версию PyEphem вы используете, чтобы мы могли сравнить. Спасибо!   -  person Brandon Rhodes    schedule 20.04.2013

Ответы (3)


arrow_upward
1
arrow_downward

Я подозреваю какое-то неправильное кэширование. Рассмотреть возможность:

import ephem 
atlanta = ephem.Observer() 
atlanta.pressure = 0 
atlanta.horizon = '-0:34' 
atlanta.lat, atlanta.lon = '89:30', '0' 
atlanta.date = '2011/03/18 12:00' 
print atlanta.previous_rising(ephem.Sun()) 
print atlanta.next_setting(ephem.Sun()) 
atlanta.date = '2011/03/19 12:00' 
print atlanta.previous_rising(ephem.Sun()) 
print atlanta.next_setting(ephem.Sun()) 
atlanta.date = '2011/03/20 12:00' 
print atlanta.previous_rising(ephem.Sun()) 
# print atlanta.next_setting(ephem.Sun()) 
atlanta.date = '2011/09/24 12:00' 
# print atlanta.previous_rising(ephem.Sun()) 
print atlanta.next_setting(ephem.Sun()) 
atlanta.date = '2011/09/25 12:00' 
print atlanta.previous_rising(ephem.Sun()) 
print atlanta.next_setting(ephem.Sun()) 
atlanta.date = '2011/09/26 12:00' 
print atlanta.previous_rising(ephem.Sun()) 
print atlanta.next_setting(ephem.Sun())

который дает:

2011/3/18 07:49:34 
2011/3/18 17:44:50 
2011/3/19 05:04:49 
2011/3/19 21:49:23 
2011/3/20 01:26:02 
2011/9/24 19:59:09 
2011/9/25 04:57:21 
2011/9/25 17:14:10 
2011/9/26 08:37:25 
2011/9/26 14:03:20

что соответствует минуте с результатами USNO:

https://raw.github.com/barrycarter/bcapps/master/db/srss-895.txt

См. Также мою связанную плаксивую жалобу в связанном вопросе.

person Community    schedule 02.02.2013

arrow_upward
1
arrow_downward

Я только что запустил вашу программу и получил этот вывод (переданный в «sort | uniq -c»):

260 2011/3/17 11:32:31
469 2011/3/17 13:42:56
184 2011/3/18 07:25:56
350 2011/3/18 18:13:15
191 2011/3/19 04:41:42
346 2011/9/24 20:25:13
337 2011/9/25 04:27:45
214 2011/9/25 17:36:10
166 2011/9/26 08:00:59
254 2011/9/26 14:37:06

Вы уверены, что у вас правильные отступы? Вот мой необработанный код:

https://raw.github.com/barrycarter/bcapps/master/playground4.py

(результат не соответствует моему другому ответу выше, но мы используем разные горизонты (-34 минуты против -50 минут).

person Community    schedule 02.02.2013
comment
Я также получаю много строк вывода, когда запускаю ваш код, что означает, что восходы и закаты в полярных регионах действительно обнаруживаются, если вы спросите о конкретном дне, когда они происходят. - person Brandon Rhodes; 20.04.2013

arrow_upward
0
arrow_downward

я обнаружил, что использование параметра start для obs.next_rising() и т. д. дает лучшие результаты. однако иногда кажется, что он пропускает определенные переходы; подъемы, которые он находит, не всегда сочетаются с соответствующим набором.

person mrgriscom    schedule 25.06.2011
comment
Не могли бы вы предоставить пример фрагмента кода, в котором отсутствует пересечение, чтобы мы могли изучить его более подробно? Спасибо! - person Brandon Rhodes; 20.04.2013