-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Fixed inconsistent azimuth angle in the ephemeris function #41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…n module reverted version of RA (Feb 18,2014)
The results of ephemeris are now similar to the results of pyephem. Both results are feasible for the location "Berlin/Europe" but I didn't checked the details. |
Thanks. Did you change anything about the algorithm itself (other than south=180) or is everything just PEP8 changes? It's hard to see on the diff. Are you interested in getting into the details, improving the function, and thoroughly testing it, or would you prefer to just go ahead and call it good? While I'm all for the careful approach on the principle of making a good and dependable library, I'm not sure if it's worth the time. Also, @alorenzo175 was working on implementing NREL's SPA algorithm with numba wrappers. |
Pascals. | ||
temperature : float | ||
temperature : float [default: 12] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most of the pvlib docstrings do not have defaults in the parameter descriptions. This is mostly because I personally don't like to put them there, and I removed them when cleaning up the docstrings. I think I might be in the minority, though, so maybe consider starting an issue for this. I'm ok with keeping this here, as long as we know about the inconsistencies.
Can you go ahead and run the modified code on the standard NREL test? See |
I made different commits to make it easier to understand.
|
Physical feasibility test. DaFrOut_a = pvlib.solarposition.get_solarposition(time=data.index,
location=location, method='pyephem')
DaFrOut_b = pvlib.solarposition.get_solarposition(time=data.index,
location=location, method='ephemeris')
# zenith over azimuth
plt.plot(DaFrOut_a['azimuth'], 90 - DaFrOut_a['zenith'], '.')
plt.plot(DaFrOut_b['azimuth'], 90 - DaFrOut_b['zenith'], '.')
plt.show()
# zenith over index(time)
plt.plot(90 - DaFrOut_a['zenith'], '-')
plt.plot(90 - DaFrOut_b['zenith'], '-')
plt.show() In the first plot both models look pretty much the same but in the second plot you can see an offset of one hour between the methods (two hours during the summer period). Half an hour of this is corrected in line 312 (there is already o comment of @wholmgren ) # ToDo: Will H: surprised to see the 0.5 here, but moving on...
UnivHr = DecHours + utc_offset #- .5 If there would be a minus 1 than everything would be the same between the two models during the winter time. But I cannot explain it so I didn't changed it.
Any ideas? I'm absent until Monday. |
Ok, I just wanted to make sure that there were no other changes hidden in the PEP8 commit. I'm not sure where exactly the problem is. My memory is that I never got the results that I expected from this function, didn't trust it, and after making minimal effort at compatibility with the Location class, I gave up on it in favor of making a pyephem wrapper. I thought that the utc_offset code handled daylight savings time, but apparently not (no DST is one of the few things that Arizona does right!). After that, @Calama-Consulting added the NREL spa and nobody seriously looked at ephemeris again until now. I'm ok with merging this now and opening a new PR for addressing the remaining problems in 0.2. Maybe keep #40 open instead of making a new issue. Sound good @Calama-Consulting or @bmu? |
The difference between the two sun rises of the green line is 23 hours. Summer time means that the time is set one hour ahead. At two o'clock the time is set to three o'clock. So the ephemeris keeps the real local time and the pyephem keeps the local standard time (winter time). I would prefer the second variant but I have to look how our weather data set is like. Still don't understand the -1 in line 312. @wholmgren I agree with merging it and moving the time shift problem to a new issue. I can do that next week. |
I strongly agree that processing modules should keep to standard (winter) On Thu, Mar 26, 2015 at 3:28 AM, ukrien [email protected] wrote:
|
I'm going to go ahead and merge and we'll deal with the tz problem separately. |
Fixed inconsistent azimuth angle in the ephemeris function
Fixed #40.