Skip to content

Add geometric solar position method to get_solarposition - #2915

Open
divyanshisingh987456321 wants to merge 2 commits into
pvlib:mainfrom
divyanshisingh987456321:geometric-solarposition
Open

divyanshisingh987456321 wants to merge 2 commits into
pvlib:mainfrom
divyanshisingh987456321:geometric-solarposition

Conversation

@divyanshisingh987456321

Copy link
Copy Markdown
  • Closes offer "geometric/analytic" solar positions as method/how in get_solarposition #2914
  • I am familiar with the contributing guidelines
  • I attest that all AI-generated material has been vetted for accuracy and is in compliance with the pvlib license
  • Tests added
  • Updates entries in docs/sphinx/source/reference for API changes.
  • Adds description and name entries in the appropriate "what's new" file in docs/sphinx/source/whatsnew for all changes. Includes link to the GitHub Issue with :issue:`num` or this Pull Request with :pull:`num`. Includes contributor name and/or GitHub username (link with :ghuser:`user`).
  • New code is fully documented. Includes numpydoc compliant docstrings, examples, and comments where necessary.
  • Pull request is nearly complete and ready for detailed review.
  • Maintainer: Appropriate GitHub Labels (including remote-data) and Milestone are assigned to the Pull Request and linked Issue.

Adds pvlib.solarposition.geometric, a fast but approximate solar position calculation, and makes it available as method='geometric' in get_solarposition, as requested in #2914.

Approach

  • Declination and equation of time come from the Spencer (1971) series (declination_spencer71, equation_of_time_spencer71).
  • Zenith and azimuth come from the existing solar_zenith_analytical and solar_azimuth_analytical.
  • Atmospheric refraction is neglected, so apparent_zenith and apparent_elevation equal zenith and elevation. This is stated in a warning in the docstring.
  • The hour angle is wrapped to [-180, 180) degrees before computing the azimuth, since the azimuth branch depends on its sign.
  • Timezone-naive times are treated as UTC, as in ephemeris.

Accuracy: compared with spa_python hourly over all of 2026 at four sites (Golden, Gurugram, Sydney, Tromsø). The maximum zenith difference was about 0.6 degrees and the maximum daytime azimuth difference about 1 degree.

Tests added in tests/test_solarposition.py: comparison with SPA at the four sites above, output columns and ranges, naive times treated as UTC, and dispatch through get_solarposition.

Open design questions (also asked in #2914):

  • Is method='geometric' the right interface, or should it be something else?
  • Should geometric be a public function like ephemeris, or private?
  • Should the apparent_* columns be returned, or omitted since refraction is neglected?

I used an AI assistant (Claude) to help draft this change. I reviewed the code, ran the tests locally and take responsibility for it.

@github-actions

Copy link
Copy Markdown

Hey @divyanshisingh987456321! 🎉

Thanks for opening your first pull request! We appreciate your
contribution. Please ensure you have reviewed and understood the
contributing guidelines.

If AI is used for any portion of this PR, you must vet the content
for technical accuracy.

Finally, be sure the PR description includes the PR
checklist,
and complete the items you are able to.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

offer "geometric/analytic" solar positions as method/how in get_solarposition

1 participant