Migrate efficiency models from pvpltools-python

[adriesse]

Describe the solution you'd like
A number of different models exist to estimate efficiency (or power) as a function of irradiance and temperature. I coded and published many of them in my own repository pvpltools-python as it was quicker to do than a pvlib PR, but I think they would fit nicely into pvlib-python.

https://github.com/adriesse/pvpltools-python/blob/master/pvpltools/module_efficiency.py

Additional context
Oh yes, I almost forgot: I developed such a model myself also and it's in there.

[adriesse]

What do you think, could the module go in pretty much as-is, or should it be organized differently?

[cwhanse]

I'm not in favor of adding the functions to pvsystem.py but that's the only current code module that makes any sense. Most functions return module efficiency eta (or help do so). There's a gap to span between having eta and getting DC power, which could be a new function in pvsystem.py. So for this base layer, I'd favor a new module e.g. pvlib.dc_efficiency.py and I immediately dislike the name.

[adriesse]

So for this base layer, I'd favor a new module e.g. pvlib.dc_efficiency.py and I immediately dislike the name.

I dislike that name too. :)

[adriesse]

I would welcome more opinions on code organization before I continue.

Another option would be to just submit the ADR model and ADR fitting function. In that case, what would be the preferred place(s) to put them?

[kandersolar]

#1572 seems OK to me so far. dc_efficiency seems too broad to me.

[adriesse]

Looking forward to some reviews...

[adriesse]

I am having some second thoughts about where to put this code. In particular, I think that pvefficiency may be too narrow for the module. Steve has already said that LFM does more than efficiency, and I think my model could do more than that as well. Which brings up my doubts about using the bare adr as a function name here also.

Could we create a new module called pvmodule or perhaps even better pvarray? Initially LFM core functions and ADR efficiency and fitting could go in there there and eventually more stuff could be moved from pvsystem to reduce its size.

If this is too complex an issue we could discuss it under #1581, but I would really like to get this ADR code into the next release.

[cwhanse]

Are we talking about a module to contain functions that take in effective_irradiance and temp_cell and output DC quantities and/or efficiency? That would be a logical next step in reducing the scope of pvsystem.py.

[adriesse]

There could be more than those two inputs perhaps. I would see pvarray as a logical destination for all SAPM, PVWATTS, SDE module/array functions, focusing on the electrical side of things. But such moves can be contemplated at leisure.

[steve-ransome]

This is a poster I presented at PVSC this year where I compared some modelling methods http://www.steveransome.com/pubs/2206_PVSC49_philadelphia_4_presented.pdf

SAPM calculates measured values (A and V) of Isc, Imp, Vmp, Voc and Ix and Ixx using a different equation and coefficients for each one. I just looked at the first four as that's all I had from the CFV data.

MPM calculates any of the normalised LFM values (usually nIsc, nImp, nVmp and nVoc from a measurement without complete IV traces as in this poster or nIsc, nRsc, nFFi, nFFv, nRoc and nVoc for good indoor or outdoor IV traces where Rsc and Roc can be calculated) with the same equation.

Although the PVGIS model had only been used for prdc I generalised it to look at other normalised parameters isc, imp, vmp and voc.

It would be good to add these and other models to pvlib and compare their fits alongside factors such as robustness, ability to fit noisy data, meaningful coefficients, performance limits (e.g. low rsc) and degradation analysis (e.g. rising roc) etc.

I haven't seen the PVSC-49 papers being released yet but could post mine here or answer any other questions.

I think we need to allow a PV model that either fits the prdc (= measured_efficiency/reference_efficiency) or one of the other chosen parameters such as isc, rsc, imp, vmp, roc and voc.

As long as the reference values of isc, imp, vmp and voc are available it is straightforward to calculate measured raw values from normalised values or vice versa with meas_to_norm or norm_to_meas functions.,

[cwhanse]

There could be more than those two inputs perhaps. I would see pvarray as a logical destination for all SAPM, PVWATTS, SDE module/array functions, focusing on the electrical side of things. But such moves can be contemplated at leisure.

pvarray to parallel pvsystem I take it.

[adriesse]

Ok, I went ahead and created the pvarray module. Let's see what reactions that provokes. :)

[adriesse]

Regarding some terminology: I notice that Steve likes the term $PR_{DC}$ while I tend to use relative and/or normalized efficiency. Mostly we're talking about the same thing in a PV module context, but in a system context there is a possible distinction. I tend to see $PR_{DC}$ as referring to the entire system up to the inverter, whereas efficiency strikes me as more component-oriented (although it could be calculated for any subsystem as well of course).

Anyway, I just wanted to make this observation and see if anyone sees potential for confusion.

[kandersolar]

Ok, I went ahead and created the pvarray module. Let's see what reactions that provokes. :)

My reaction is that the name pvarray calls to mind a physical installation with characteristics like a racking configuration, GCR, and wiring topology. The efficiency models considered here seem abstracted from that by a step or two. Without thinking too hard about it, I think I'd favor pvmodule (pvdevice?) over pvarray for these functions.

As an aside, I found SAND2020-3877 to be an informative and engaging read. My compliments to the chefs.

[adriesse]

As an aside, I found SAND2020-3877 to be an informative and engaging read. My compliments to the chefs.

Thanks, that's really nice to hear!

[kandersolar]

Ok, I went ahead and created the pvarray module

Are we planning to eventually move some of the pvlib.pvsystem functionality to this new module? If so, as long as we've already deprecated pvlib.pvsystem.pvwatts_dc in #1558, we may as well move that one now so we don't have to deprecate it again later.

[cwhanse]

Are we planning to eventually move some of the pvlib.pvsystem functionality to this new module?

I would vote yes. What about moving PVArray? If I was looking for PVArray, I'd first guess pvarray.py....

[adriesse]

No objection to either move, but maybe we should make a list of moving candidates?