Skip to content

implement PVWatts #195

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

Merged
merged 7 commits into from
Jun 27, 2016
Merged

implement PVWatts #195

merged 7 commits into from
Jun 27, 2016

Conversation

wholmgren
Copy link
Member

@wholmgren wholmgren commented Jun 22, 2016

I implemented the PVWatts module and inverter models as described in http://pvwatts.nrel.gov/downloads/pvwattsv5.pdf

I originally proposed something like this for ModelChains in #143, and @cwhanse wisely suggested adding PVWatts. It's probably best to first add the basic functions so that they don't get tied up in ModelChain land.

I'm looking for feedback on the function signatures and variable names so that we can try to maintain consistency throughout the library. I've mostly used the exact names from the PVWatts documentation, but we should consider changing at least a few of them. Keep in mind that we do have a variable/style guide, but also that it's not set in stone:

  • irrad_trans: Short for irradiance_transmitted, long for Itr. There are some other functions (e.g. calcparams_desoto) that currently use poa_global but that perhaps should use this instead.
  • pdc: I might prefer this to e.g. power_dc
  • pdc0: I prefer this to e.g. power_dc_0.
  • gamma: I might prefer temp_coeff or temp_co.
  • eta, eta_nom, eta_ref: I'd consider dc_ac_ratio_* or similar.

To do:

  • add notes to whats new
  • add new terms to style guide

@wholmgren wholmgren added this to the 0.4.0 milestone Jun 22, 2016
@cwhanse
Copy link
Member

cwhanse commented Jun 22, 2016

Hi Will,

pdc and power_dc are intuitive enough, I think either works. Appending a 0 or _stc should indicate a value at STC conditions.

Eta is the conventional symbol for efficiency, I’d stick with it. But I’d add _inv (eta_inv) to indicate the inverter efficiency because eta is also used for cell efficiency (sunlight to current).

I’d use gamma_pdc for the temperature coefficient. Its conventional to use alpha for current temperature coefficients (e.g., alpha_isc), beta for voltage and gamma for power. But some literature also use gamma for the diode factor.

Its crucial to note somewhere that in PVWatts gamma_pdc has units of 1/C, not W/C.

I don’t care for irrad_trans or Itr. However, this is a grey area and there’s no convention I know of. G is most commonly used for broadband irradiance (e.g., Gpoa) and E for effective irradiance (adjusted for spectral content). In PVWatts, Itr represents Gpoa reduced by reflections. I wouldn’t use I for irradiance, so perhaps Gtransmitted?

Cliff

@wholmgren
Copy link
Member Author

Thanks for the helpful comments.

eta (without the _nom or _ref) is actually only used within the pvwatts_ac function. The function arguments would become eta_inv_nom/eta_nom_inv and eta_inv_ref/eta_ref_inv.

I've never cared much for G, but maybe I should learn to live with it. Is irradiance_transmitted too long for an argument name? In principle, one could apply a spectral correction modifier to the irradiance before passing it into the function.

I'll let this sit for a day or two so that other people can comment, too.

@jforbess
Copy link
Contributor

I'm definitely not a fan of irradiance_transmitted, in any form, long or
short, because that's not a term I have ever used. And it doesn't say
anything about what kind of irradiance it is (POA is implied, perhaps, but
I prefer if it is explicit). Not sure what Cliff means by GPOA reduced by
reflections. Do you mean shading? Oh, incident angle reflections, I guess.

As you might guess, I am more comfortable with PVsyst terminology, which
lead to g_poa (or poa_global) and g_poa_effective, where g_poa_effective is
g_poa reduced by incident angle reflection, shading (horizon and near), and
soiling. I would rather use g_poa as an input to ModelChain, and handle all
of the reductions separately, but maybe I'm not understanding how you are
architecting this?

I agree with Cliff's comments on gamma_pdc and eta_inv. (I'd go eta_inv_nom
and ref at the end, myself).

On Wed, Jun 22, 2016 at 2:24 PM, Will Holmgren [email protected]
wrote:

Thanks for the helpful comments.

eta (without the _nom or _ref) is actually only used within the pvwatts_ac
function. The function arguments would become eta_inv_nom/eta_nom_inv and
eta_inv_ref/eta_ref_inv.

I've never cared much for G, but maybe I should learn to live with it. Is
irradiance_transmitted too long for an argument name? In principle, one
could apply a spectral correction modifier to the irradiance before passing
it into the function.

I'll let this sit for a day or two so that other people can comment, too.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#195 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AH66AaIWlpQsXNLfeLe30Rb3r6G-6RsFks5qOYvwgaJpZM4I8B-m
.

@wholmgren
Copy link
Member Author

This PR is totally separate from ModelChain. I'm just implementating two simple equations from pvwatts.

@jforbess
Copy link
Contributor

Ok, I guess I was confused by your first comment of "There are some other
functions (e.g. calcparams_desoto) that currently use poa_global but that
should use this instead." I definitely disagree with that.

On Wed, Jun 22, 2016 at 1:05 PM, Will Holmgren [email protected]
wrote:

This PR is totally separate from ModelChain. I'm just implementating two
simple equations from pvwatts.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#195 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AH66AVK1NyDcGFNdFkc94nfTB377bI5hks5qOZV8gaJpZM4I8B-m
.

@wholmgren
Copy link
Member Author

@jforbess I updated my first comment to make it less specific. The point I was trying to make is that there may be additional cases in pvlib where the important thing is the irradiance after accounting for reflection losses.

Now is a great time to change any names that you don't like, but I'll suggest making a new issue for it if they're not specific to these two functions.

@wholmgren
Copy link
Member Author

I added pvwatts_losses and PVSystem.pvwatts_losses. The function uses a keyword argument with a default value for each of the PVWatts loss parameters.

Here's a link to the readthedocs build for this branch: http://wholmgren-pvlib-python-new.readthedocs.io/en/pvwatts/modules.html#pvlib.pvsystem.pvwatts_ac

A few more notes here regarding the PVWatts model for future reference:

  1. The PVWatts aoi loss model is the same as our physicaliam but with K=4 and L=0.002
  2. The PVWatts thermal model is Fuentes 1987. I'm not familiar with it.
  3. The PVWatts transposition model is Perez, but with isotropic for zenith angles 87.5-90 degrees. Default albedo of 0.2.

@wholmgren
Copy link
Member Author

I'll merge this on Monday unless I hear objections.

@wholmgren wholmgren merged commit 1c02806 into pvlib:master Jun 27, 2016
@wholmgren wholmgren deleted the pvwatts branch June 28, 2016 22:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants