ephem not working correct

[Bram Baert]

Hi all,

I have a new install of weewx 3.3.0 and I am using ephem to get the extended almanac but it isn't working as it should. When I query for the sun rise and start of civil twilight it gives incorrect values. It even says the start of twilight is after the sunrise. 

- I've check other stations in my neighborhood to confirm that my numbers are of (also those for the moon)

- I've check my coordinates in my config file

- I've ran the code manual in a python shell, it also gives the wrong results (based on import weewx.almanac)

- I've edited the almanac.py to make a syslog print to confirm that it is actual loading the ephem library correct

- I've had the thought that if I had a wrong timezone configured I could get a wrong result but then again the worst It would result in is getting results for another plus minus one day. So that can't really be it either.

To see my incorrect results you can go to my site http://weerstationgits.dlinkddns.com/weewx. Correct results can be found at http://weer.lagaisse.com/

anybody has an idea what I could look at next?

Regards

Bram

[gjr80]

Hi,

In my experience pyephem used with weewx has been very robust and accurate. I just put your lat/long (51.006/3.11) and alt (28m) into an instance of weewx 3.3.1 was given the following:

Sun

Start civil twilight: 16:59:49 Sunrise: 17:40:10 Transit: 21:40:39 Sunset: 01:41:03 End civil twilight: 02:20:18
Given that I am UTC+10 and you appear to be UTC+1, we need to take 9 hours off these figures to convert them to your time which gives figures comparable to your comparison site. As you said timezone, is not the issue, it just offsets the resulting times(as happened to me). Whilst there were changes to almanac.py in weewx 3.3.0 these should have no impact on sunrise/set etc (3.3.1 made no changes to almanac.py). Makes me suspect a misconfiguration somewhere. Since you are running 3.3.0 you can use the command line utility wee_debug to generate a debug report that will give a definitive snapshot of your configuration, in particular weewx.conf. Carefully check the wee_debug output for sensitive info/passwords and post the output (as an attached file). Have you made any changes to index.html.tmpl in the Standard skin post install/upgrade? Might also be worthwhile posting a copy of index.html.tmpl from your install; just make sure that you post the file that is actually being used, not the one that was included in the file you downloaded from weewx.com.

Gary

[Thomas Keffer]

The almanac code was completely rewritten in V3.3, so it would not surprise me if there is a problem with it.

However, I tested sunrise, transit, and sunset, using both pyephem and Almanac, and got reasonable times. Here's the program:

import ephem

belgium = ephem.Observer()

belgium.date = '2015/12/11'

belgium.lat = '51:0.4'

belgium.lon = '3:6.6'

belgium.elevation = 28

sun = ephem.Sun()

print "Times using ephem (UTC):"

print "sunrise: ", belgium.next_rising(sun)

print "transit: ", belgium.next_transit(sun)

print "sunset:  ", belgium.next_setting(sun)

# ---------

import os

import time

from weewx.almanac import Almanac

os.environ['TZ'] = 'Europe/Brussels'

tt = (2015,12,11,0,0,0,0,0,-1)

ts = time.mktime(tt)

almanac = Almanac(ts, 51, 3.1)

print "Times using Almanac (local time):"

print "sunrise:", almanac.sun.rise

print "transit:", almanac.sun.transit

print "sunset: ", almanac.sun.set

And here are the results:

Times using ephem (UTC):

sunrise:  2015/12/11 07:39:44

transit:  2015/12/11 11:40:39

sunset:   2015/12/11 15:41:23

Times using Almanac (local time):

sunrise: 08:39

transit: 12:40

sunset:  16:41

You're in Belgium, which is UTC+1, so the times are identical. They are also within a few minutes of your reference station, Heiende, so I suspect the problem is in your station.

In addition to Gary's suggestion of trying the wee_debug utility, double check your index.html.tmpl file and make sure that you are not specifying a horizon value. It should look something like this:

                <tr>

                  <td class="label">Sunrise:</td>

                  <td class="data">$almanac.sun.rise.string($sun_None)</td>

                </tr>

                <tr>

                  <td class="label">Transit:</td>

                  <td class="data">$almanac.sun.transit</td>

                </tr>

                <tr>

                  <td class="label">Sunset:</td>

                  <td class="data">$almanac.sun.set.string($sun_None)</td>

                </tr>

-tk

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Bram Baert]

Hey

- Your code example gives the same results so that is already a good start.

- The index.html.tmpl has the exact syntax as you said (I am sure it is the correct file cause its the one where I changed "Pond" into "Greenhouse". Also if your going to go and have a look to the site it will be obvious I know what file I need to be in :-) )

- I noticed that in my personal code (written for version 2.6.x) I used the syntax almanac.sunrise and almanac.sunset. When I print those right after your example code I get the wrong result as it is on my webpage. (I now already corrected my personal code). Below the result of my testscript

Times using ephem (UTC):

sunrise:  2015/12/11 07:39:44

transit:  2015/12/11 11:40:39

sunset:  2015/12/11 15:41:23

Times using Almanac (local time):

sunrise:  08:39

transit:  12:40

sunset:  16:41

Times using my code (local time):

Start of twiglight:  07:59

sunrise:  07:58

sunset:  07:58

End of twiglight:  17:21

- I wanted to try the wee_debug but I didn't find it, thus I did a grep for wee_debug on the complete weewx folder (python setup) and didn't find it (the only thing that turned up was changes.txt and docs/usersguide.htm). Google wasn't able to point me in the right direction either

Bram

[David Blackwell]

Hi,

First time I've ever used Google groups so I apologise in advance if I've put this message in the wrong place.

I'm having a similar problem. I'm running 2 instances of weewx - 3.2.1 on a ReadyNAS Duo v2 which is still running with the pre-installed American localisation. In preparation to moving the sensors, I made use of an old Win XP machine and did a brand new install of Debian 8 as an headless server with a United Kingdom localisation.. This is running weewx 3.3.1 in simulator mode. The sunrise and sunset on this machine are incorrect. I'm wondering if this is because weewx is converting my British formatted dates to American and is thus providing sunrise and sunset for 12th November 2015 instead of 11th December 2015.

There are no errors in the syslog from either machine and the latitude and longitude are identical

	Machine 1 (ReadyNAS)
	Sunrise: 08:20:01 AM Sunset: 04:01:55 PM Machine 2 (Debian 8) Sunrise: 07:35:15 Sunset: 16:46:27 If I'm right then both machines should be correct tomorrow! I'm don't know enough about weewx to be able to prove or disprove my theory - any pointers would be appreciated Many thanks, David

[Bram Baert]

One day apart won't make the sunrise or sunset change as much as the difference between your two servers the change in geographical location could.

Can you post the coordinates used on both servers?

[gjr80]

Bram,

If you installed 3.3.0 or 3.3.1 wee_debug should be in /usr/share/weewx or /home/weewx/bin depending on your weewx install type. If for some reason it is not there you can pull it down direct from the weewx GitHub site. Getting individual files from GitHub is not too intuitive though, an alternative is to search the forums for wee_debug; I included the file in a post in late November.

Gary

[vince]

On Friday, December 11, 2015 at 1:46:58 PM UTC-8, gjr80 wrote:

Bram,

If you installed 3.3.0 or 3.3.1 wee_debug should be in /usr/share/weewx or /home/weewx/bin depending on your weewx install type. If for some reason it is not there you can pull it down direct from the weewx GitHub site. Getting individual files from GitHub is not too intuitive though, an alternative is to search the forums for wee_debug; I included the file in a post in late November.

There's some kind of 'make dist' issue:

 - not in the 3.3.0 tgz nor the 3.3.1 tgz

 - I tore apart the 3.3.1 deb package, it's not in there

 - I tore apart the 3.3.1 rpm packete, it's not in there either

 

[gjr80]

Hmmm, correct, wondered what was going on though when it appeared in my 3.3.1 upgraded system. Having a closer look at file timestamps and ownership it appears my wee_debug was a remnant of earlier development/testing (probably a good case in hand for keeping development off of production). No matter, am sure it will make it into 3.3.2, in the meantime just get it from github or my 24 Nov post.

Gary

[vince]

I found a cool site where you can check expected results - http://www.timeanddate.com/sun/usa/seattle?month=1&year=2016

Also, here's a little test program I cobbled together from a website example I found.

I get the expected results on my weewx vagrant box (debian) if you're looking for a reference program as a test.

FWIW, the test program below matches the Atlanta data on the website above, correcting for GMT offset hours.

#### this is based on rhodesmill.org/pyephem/rise-set.html

import ephem

atlanta = ephem.Observer()

atlanta.pressure = 0

atlanta.horizon  = '-0:34'

atlanta.lat, atlanta.lon = '33.8', '-84.4'

atlanta.date = '2009/09/06 17:00' # noon EST

print ""

print "sun previous_rising 2009/9/6 11:14:57"

print "                   ", atlanta.previous_rising(ephem.Sun())

print ""

print "sun next_setting    2009/9/6 23:56:10"

print "                   ", atlanta.next_setting(ephem.Sun())

print ""

print "--- use civil twilight ---"

print ""

atlanta.horizon = '-6'  # civil twilight = -6 deg

# nautical = -12

# astronomical = -18

print "sun previous_rising 2009/9/6 10:49:40"

print "                   ", atlanta.previous_rising(ephem.Sun(), use_center=True)

print ""

print "sun next_rising     2009/9/7 00:21:23"

print "                   ", atlanta.next_setting(ephem.Sun(), use_center=True)

 

[gjr80]

Bram,

Thought about this some more...

Regarding almanac.sunrise or almanac.sun.rise, if pyephem is installed they both give the same result as they both call pyephem. If pyephem is not installed then almanac.sunrise uses another method to calculate sunrise and almanac.sun.rise will give an error. So on your site that is why both give the same erroneous value.

- I noticed that in my personal code (written for version 2.6.x) I used the syntax almanac.sunrise and almanac.sunset. When I print those right after your example code I get the wrong result as it is on my webpage. (I now already corrected my personal code).

Exactly what code is in your testscript? I guess you have Tom's code but what exactly is in 'your personal' code, was this something you added to the end of Tom's code? Could you post the entire piece of code you executed? Not doubting what you are doing but just want a clear picture of what 'input' is resulting in the garbage output.

Gary

[mwall]

On Friday, December 11, 2015 at 6:06:31 PM UTC-5, gjr80 wrote:

Hmmm, correct, wondered what was going on though when it appeared in my 3.3.1 upgraded system. Having a closer look at file timestamps and ownership it appears my wee_debug was a remnant of earlier development/testing (probably a good case in hand for keeping development off of production). No matter, am sure it will make it into 3.3.2, in the meantime just get it from github or my 24 Nov post.

wee_debug is in the source tree but did not make it into the weewx installer.  fixed at 839d7c4099b596ef74210f94051b794dafe20b78

meanwhile, it can be downloaded from the source at:

https://github.com/weewx/weewx/blob/master/bin/wee_debug

m

[Luc Heijst]

Tom,

I checked the sun/moon rise/set info of weewx 3.3.1 presented in the almanac page of the amphibian skin (see http://www.lucdesign.nl/data/weewx/amphibian/almanac.html )

with those presented on site: http://www.timeanddate.com/astronomy/suriname/paramaribo. The presented weewx values are not right. I marked them with ?

sun

civil twilight start 06:17 ok

rise 06:40 06:16?

set   18:28 18:52?

civil twilight end 18:50 ok

moon 

rise 06:42 06:17?

transit 12:46 ok

set 18:51 19:15?

Luc

[Thomas Keffer]

Gary: not quite. almanac.sunrise and almanac.sunset are there for backwards  compatibility. If pyephem is present, they use the same algorithm. Otherwise, they use the algorithm supplied by weeutil.Sun.

Nevertheless, I thought I'd test weeutil.Sun. It gives similar results to pyephem, within a couple minutes

import weeutil.Sun

print "Times using weeutil.Sun"

sunrise_utc, sunset_utc = weeutil.Sun.sunRiseSet(2015,12,11, 3.1, 51)

sunrise_h = int(sunrise_utc)

sunrise_m = (sunrise_utc - sunrise_h) * 60

sunset_h =  int(sunset_utc)

sunset_m =  (sunset_utc - sunset_h) * 60

print "sunrise (UTC): %02d:%.1f" % (sunrise_h, sunrise_m)

print "sunset (UTC):  %02d:%.1f" % (sunset_h, sunset_m)

Results

Times using weeutil.Sun

sunrise (UTC): 07:40.2

sunset (UTC):  15:41.2

OK, folks. Someone is going to have to give me something I can test against. All of the tests I've come up with, including the doctests in weewx.almanac, all work. Ideal would be a test case, added to the existing doctests, which is failing.

-tk

[Thomas Keffer]

Luc,

At the top of your page you give a sunrise and sunset that are similar to your expected results. Where do those come from?

I tried my little test program using your location, and got results consistent with your expectations, but not what you're showing in your webpage:

import os

import time

from weewx.almanac import Almanac

os.environ['TZ'] = 'America/Paramaribo'

tt = (2015,12,11,0,0,0,0,0,-1)

ts = time.mktime(tt)

almanac = Almanac(ts, 5.8, -55.2)

print "Times using Almanac (local time):"

print "sunrise:", almanac.sun.rise

print "transit:", almanac.sun.transit

print "sunset: ", almanac.sun.set

Results:

Times using Almanac (local time):

sunrise: 06:39

transit: 12:33

sunset:  18:28

Again, I need something that fails, which I can test against.

-tk

[Luc Heijst]

Tom,

I copied the sections from the amphibian skin, see below.

The strange thing is: both codings are the same, yet the output is different.

Which file(s) do you need for testing?

Luc

file: header.inc

----------------

#if $almanac.hasExtras

      Sunrise <span class='value'>$almanac.sun.rise</span><br/>

      Sunset <span class='value'>$almanac.sun.set</span><br/>

      Moonrise <span class='value'>$almanac.moon.rise</span><br/>

      Moonset <span class='value'>$almanac.moon.set</span><br/>

#else

      Sunrise <span class='value'>$almanac.sunrise</span><br/>

      Sunset <span class='value'>$almanac.sunset</span><br/>

#end if

file: almanac.html.tmpl

-----------------------

#if $almanac.hasExtras

## Extended almanac information is available, do full set of data.

<table>

  <tr><td class="metric_title">Sun</td><td></td></tr>

  <tr>

    <td class="metric_name">Start civil twilight:</td>

    <td class="metric_value">$almanac(horizon=-6).sun(use_center=1).rise</td>

  </tr>

  <tr>

    <td class="metric_name">Sunrise:</td>

    <td class="metric_value">$almanac.sun.rise</td>

  </tr>

  <tr>

    <td class="metric_name">Transit:</td>

    <td class="metric_value">$almanac.sun.transit</td>

  </tr>

  <tr>

    <td class="metric_name">Sunset:</td>

    <td class="metric_value">$almanac.sun.set</td>

  </tr>

  <tr>

    <td class="metric_name">End civil twilight:</td>

    <td class="metric_value">$almanac(horizon=-6).sun(use_center=1).set</td>

  </tr>

  <tr>

    <td class="metric_name">Azimuth:</td>

    <td class="metric_value">$("%.1f&deg;" % $almanac.sun.az)</td>

  </tr>

  <tr>

    <td class="metric_name">Altitude:</td>

    <td class="metric_value">$("%.1f&deg;" % $almanac.sun.alt)</td>

  </tr>

  <tr>

    <td class="metric_name">Right ascension:</td>

    <td class="metric_value">$("%.1f&deg;" % $almanac.sun.ra)</td>

  </tr>

  <tr>

    <td class="metric_name">Declination:</td>

    <td class="metric_value">$("%.1f&deg;" % $almanac.sun.dec)</td>

  </tr>

  #if $almanac.next_equinox.raw < $almanac.next_solstice.raw

  ## The equinox is before the solstice. Display them in order.

  <tr>

    <td class="metric_name">Equinox:</td>

    <td class="metric_value">$almanac.next_equinox</td>

  </tr>

  <tr>

    <td class="metric_name">Solstice:</td>

    <td class="metric_value">$almanac.next_solstice</td>

  </tr>

  #else

  ## The solstice is before the equinox. Display them in order.

  <tr>

    <td class="metric_name">Solstice:</td>

    <td class="metric_value">$almanac.next_solstice</td>

  </tr>

  <tr>

    <td class="metric_name">Equinox:</td>

    <td class="metric_value">$almanac.next_equinox</td>

  </tr>

  #end if

</table>

    </td>

    <td>&nbsp;</td>

    <td>

<table>

  <tr><td class="metric_title">Moon</td><td></td></tr>

  <tr>

    <td class="metric_name">Rise:</td>

    <td class="metric_value">$almanac.moon.rise</td>

  </tr>

  <tr>

    <td class="metric_name">Transit:</td>

    <td class="metric_value">$almanac.moon.transit</td>

  </tr>

  <tr>

    <td class="metric_name">Set:</td>

    <td class="metric_value">$almanac.moon.set</td>

  </tr>

  <tr>

    <td class="metric_name">Azimuth:</td>

    <td class="metric_value">$("%.1f&deg;" % $almanac.moon.az)</td>

  </tr>

  <tr>

    <td class="metric_name">Altitude:</td>

    <td class="metric_value">$("%.1f&deg;" % $almanac.moon.alt)</td>

  </tr>

  <tr>

    <td class="metric_name">Right ascension:</td>

    <td class="metric_value">$("%.1f&deg;" % $almanac.moon.ra)</td>

  </tr>

  <tr>

    <td class="metric_name">Declination:</td>

    <td class="metric_value">$("%.1f&deg;" % $almanac.moon.dec)</td>

  </tr>

  #if $almanac.next_full_moon.raw < $almanac.next_new_moon.raw

  <tr>

    <td class="metric_name">Full moon:</td>

    <td class="metric_value">$almanac.next_full_moon</td>

  </tr>

  <tr>

    <td class="metric_name">New moon:</td>

    <td class="metric_value">$almanac.next_new_moon</td>

  </tr>

  #else

  <tr>

    <td class="metric_name">New moon:</td>

    <td class="metric_value">$almanac.next_new_moon</td>

  </tr>

  <tr>

    <td class="metric_name">Full moon:</td>

    <td class="metric_value">$almanac.next_full_moon</td>

  </tr>

  #end if

  <tr style='vertical-align:top'>

    <td class="metric_name">Phase:</td>

    <td><span class="metric_value">$almanac.moon_phase</span><br/><span class='metric_hilo'>$almanac.moon_fullness% full</span></td>

  </tr>

</table>

#else

## No extended almanac information, fall back to a simple table.

<table>

  <tr><td class='metric_title'>Sun and Moon</td><td></td></tr>

  <tr>

    <td class="metric_name">Sunrise:</td>

    <td class="metric_value">$almanac.sunrise</td>

  </tr>

  <tr>

    <td class="metric_name">Sunset:</td>

    <td class="metric_value">$almanac.sunset</td>

  </tr>

  <tr style='vertical-align:top'>

    <td class="metric_name">Moon Phase:</td>

    <td><span class="metric_value">$almanac.moon_phase</span><br/><span class='metric_hilo'>$almanac.moon_fullness% full</span></td>

  </tr>

</table>

#end if

[Thomas Keffer]

LOL! I need something that will break! Everytime I try your template code, I get the right answer.

-tk

[Luc Heijst]

Tom,

I have set target_unit to METRIC. May be that makes somewhere the difference.

Luc

[Thomas Keffer]

At last! I was able to reproduce the problem. If you use an explicit horizon, it retains the value and uses it again. This fails:

print "sunrise:", almanac.sun.rise

print "Start twilight: ", almanac(horizon=-6).sun.rise

print "sunrise a 2nd time:", almanac.sun.rise

Bug fix to follow.

-tk

[Thomas Keffer]

OK, fixed in commit 450f3d8.

-tk

[Bram Baert]

This indeed fixes it 

PS: sorry about making a "rush" post and thus not posting the code I used, It would have made the debugging easier. I 'll remember for next time.

Bram