-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
add Mount classes #1176
add Mount classes #1176
Conversation
Thanks! This looks like a cleaner solution to me and I suspect it will be easier to maintain.
I ran into this too and put the import in a method: https://github.com/pvlib/pvlib-python/pull/1146/files#diff-49dca2a56e76272f399adc5e162e9e026ddb8b39ab4136d1d106e188691c7be7R1616
Yes, that is part of my goal #1109 (comment). Another win for composition over inheritance. |
I'm not sure what the best move is here for |
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 agree that we only need SingleAxisTracker
to work as it did in v0.8 through a v0.9 deprecation period - it doesn't need any new functionality.
@wfvining it would be great to get your feedback on this draft PR.
self.max_angle, self.backtrack, | ||
self.gcr, self.cross_axis_tilt | ||
) | ||
return tracking_data |
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.
still thinking about interface promises... get_orientation
promises to return something dict-like that includes keys surface_tilt and surface_azimuth.
I don't think it's possible (or particularly useful) to test the @cwhanse you brought up |
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 think the only big thing we're missing on this PR is @cwhanse's opinion of the approach. Of course other opinions are welcome too.
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 think move both racking_model
and module_height
to Mount
and see how this progresses.
pvlib/pvsystem.py
Outdated
class AbstractMount(ABC): | ||
|
||
@abstractmethod | ||
def calculate_orientation(self, solar_zenith, solar_azimuth): |
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.
maybe get_module_orientation
? Or get_module_position
? get_orientation
?
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.
pvlib methods prefixed with 'get' typically have 'how' or 'method' kwargs. Python discourages the prefix in most cases.
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 is this method intended to return? [nvm I read the code again, short memory I guess]. tilt
and azimuth
I assume?calculate
seems like a long way to say get
to me.
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.
After thinking a little more about this... I had an unfair allergic reaction to get
in this case. It's more correct to say that getter methods are not pythonic. This isn't a getter method, so we're ok. We use get
for a lot of things that do calculations, so there's still consistency. I'm now neutral on the prefix.
pvlib/pvsystem.py
Outdated
"specify it as a key in temperature_model_parameters " | ||
"or as an attribute of the Array's Mount." | ||
) | ||
raise ValueError(msg) |
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'm not sure what to do about the various places to look for surface_tilt
now that the PVSystem
and its Mount
aren't guaranteed to have a surface_tilt
attribute. Is it reasonable to remove this complexity and only look in temperature_model_parameters
?
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.
Is it reasonable to remove this complexity and only look in temperature_model_parameters?
Sounds good to me.
Probably a bad idea: An alternative would be calling get_orientation
with something like 0, 0
- doesn't matter for fixed tilt systems and it would make most single axis trackers return 0.
Definitely not interested in adding solar position kwargs to this method.
Finally marking this ready for review. Figured I'd wait to do the whatsnew until folks have a chance to take a look and make sure no other big stuff should go into this PR. |
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.
This is great!
Need to update introtutorial.rst
Object Oriented text and code. Can be a follow up PR if you make a new issue for it.
pvsystem.rst
would benefit from an example with SingleAxisTrackerMount
. Follow up issue/PR ok.
+1 on deprecating SingleAxisTracker
. Follow up issue/PR ok. We shouldn't forget to address pvsystem.rst
SingleAxisTracker
section in that process.
There are a few tests in test_modelchain.rst
that use SingleAxisTracker
. Most if not all of that should be retested using the new mount. That could be an argument for doing the deprecation now. But copy/paste/modify/punt is fine too.
In the interest of not holding this up any longer (sorry again), I think let's push the various |
pvlib/tracking.py
Outdated
|
||
|
||
@deprecated('0.9.0', alternative='PVSystem with SingleAxisTrackingMount') |
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.
hmm seeing the difference with the class name has me wondering... SingleAxisTrackingMount
or SingleAxisTrackerMount
?
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 surveyed n=2 pvlib users and both preferred SingleAxisTrackerMount
. I will make the change.
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.
Turns out it was already called SingleAxisTrackerMount
and I just called it the wrong thing in the deprecation message 🤦♂️
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.
At least we got some data out of it!
Co-authored-by: Will Holmgren <william.holmgren@gmail.com>
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.
@cwhanse ok to merge?
Valid strings are 'open_rack', 'close_mount', and 'insulated_back'. | ||
Used to identify a parameter set for the SAPM cell temperature model. | ||
|
||
module_height : float, optional |
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.
Here, I don't understand module_height
; does it not change with tracker rotation? Maybe axis_height
and an internal calculation would produce module_height
as an attribute, not an input parameter. In FixedMount
, module_height
is merely awkward, as the measurement that seems more likely to be at hand is the height of the bottom of the module above ground.
I'm OK merging this as is and improving in later PRs.
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.
Good points. +1 to improving in later PRs.
thanks for the huge refactor @kanderso-nrel! 🥳 🥳 🥳 |
docs/sphinx/source/api.rst
for API changes.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`
).pvsystem.SingleAxisTracker
?A draft implementation of the
Mount
classes proposed in #1146 (comment). I updated the pvsystem tests, but not anywhere else yet. Note: I made a new module (pvlib.mounts
) as a quick fix for a circular import issue betweenpvlib.pvsystem
andpvlib.tracking
, but I'm not sure that's the right fix in the long run.Sorry if this has already been discussed elsewhere, but: I suspect a consequence of moving tracking calculations down to
Array
, or more specificallyArray.mount
, is thatSingleAxisTracker
(the subclass ofPVSystem
) becomes unnecessary.Example usage:
Click to expand!