Rename pvwatts to pvwattsv5 everywhere#1558
Conversation
|
I have no other comment on this PR. The interface (multiple functions For discussion: adding |
Why not? If v10's xxx model is different from v8's I don't seen any reason not to implement both, and that naming scheme seems reasonable to me so long as the model is not taken from elsewhere (for example as |
|
I'm not saying that there isn't value is adding And: if |
|
PVWatts seems to be converging towards a "SAM Lite" with many of the same models, so this proliferation might be asymptotic, but point taken. My view: if the user wants to reimplement PVWatts themselves using pvlib's function layer, I don't mind them having to know that Version N of PVWatts needs a function named |
Co-authored-by: Cliff Hansen <cwhanse@sandia.gov>
We don't have a rule for deciding how many versions a deprecation lasts, right? I am starting to think 0.11 is better. |
|
Since it's not clear that there will be a suitable length of time before 0.10, I have switched the deprecations to be scheduled for removal in 0.11 instead. I'll leave this open for a couple days in case anyone wants to comment, otherwise I'll merge on Dec 14. |
This reverts commit e6e5b04.

docs/sphinx/source/referencefor API changes.docs/sphinx/source/whatsnewfor 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`).remote-data) and Milestone are assigned to the Pull Request and linked Issue.A rather tedious PR, both to prepare and (I imagine) to review.
$ git grep -n -e 'pvwatts[^v]'is invaluable for finding stragglers.For reference, SAM's implementation of PVWatts v8 is out (NatLabRockies/ssc#630), but I don't think there's a publication about it yet, so let's implement v8 later and just focus on making room for it now. This PR is big enough already anyway.