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

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

3 голосов
/ 16 июня 2011

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

соблюдать приведенный ниже пример кода. он перебирает весь год с 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 есть ошибка, либо я неправильно понимаю что-то фундаментальное. любая помощь?

Ответы [ 3 ]

1 голос
/ 02 февраля 2013

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

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

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

1 голос
/ 02 февраля 2013

Я только что запустил вашу программу и получил этот вывод (по каналу "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 минут).

0 голосов
/ 26 июня 2011

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

...