-
Notifications
You must be signed in to change notification settings - Fork 33
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
Orientation sphinx documentation #148
Orientation sphinx documentation #148
Conversation
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.
@kperrynrel both this PR and #146 add a SERF data file. Should we merge #146 first and then update this PR to use that dataset?
Co-authored-by: Kevin Anderson <kevin.anderson@nrel.gov>
@kanderso-nrel Yeah I'm for us waiting until #146 is merged before merging this guy. |
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.
What should we do with the SERF data file? It's way more data than this PR needs, so maybe pare it down to just those few days with the expectation that #146 might overwrite it later with a longer dataset?
# %% | ||
# Identifying and masking sunny days for a single-axis tracking system is | ||
# important when performing future analyses that require filtered clearsky | ||
# data. For this example we will use data from the single-axis tracking |
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.
Wording nitpick -- I think it's probably a good idea to avoid using "clear-sky" and "sunny day" as synonyms. Clear-sky (at least in the pvlib world) has some association with smoothness, but I think these functions would not take issue with a jagged input curve so long as the jaggedness is riding on top of the quartic/quadratic profile they're looking for.
The tracking function has the additional requirement that the input isn't a good match to a fixed-tilt profile, so to my mind it's more of a check that the system is tracking properly, and the identification of sunny days was more of an implementation detail than a specific goal. Not sure how relevant that is here though.
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.
I changed the wording to 'sunny day' only in 76c4de1
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.
OK with me!
Description
This PR handles documentation for the sunny day mask for both fixed tilt and single axis tracking systems functions.
Thank you for your contribution! Please provide a brief description of the problem and the proposed solution or new feature (if not already fully described in a linked issue)
Checklist
The following items must be addressed before the code can be merged.
Please don't hesitate to ask for help if you are unsure of how to accomplish any of the items.
You are free to remove any checklist items that do not apply or add additional items that are
not on this list
in
docs/whatsnew
for all changes. Includes link to the GitHub Issue with
:issue:`num`
or this Pull Request with
:pull:`num`
. Includes contributor nameand/or GitHub username (link with
:ghuser:`user`
).