pvlib
clipping off-mpp operating point calculation
Feature request An algorithm that determines the off-mpp operating point for inverters that are clipping
Describe the solution you'd like Assuming that if the converted AC out is greater than rated AC (at the ambient temperature), then the inverter will increase the voltage until the AC output, what is the DC output, DC voltage, and inverter efficiency loss
Describe alternatives you've considered I scripted something really, REALLY basic, I don't suggest something as simplistic as this:
p_ac = pvlib.inverter.sandia(v_mpp, p_mpp, inverter) # use MPP first time
voltage_test_range = (v_oc - v_mpp)/100.0 # divide excess voltage into 100 steps
v_dc = v_mpp
while p_ac > ac_rated:
v_dc += voltage_test_range # add a little
i_dc = np.interp(v_dc, v, i) # v and i are the full IV curve
# NOTE: v must be monotonically increasing for np.interp to work!
p_dc = v_dc * i_dc
p_ac = pvlib.inverter.sandia(v_dc, p_dc, inverter)
But it would be better to redo this with a scalar root finder from scipy.optimize like brentq.
Also, it the AC rated power should be adjusted depending on the ambient temperature, but this could be separate.
Additional context Sorry, I couldn't find any related issues/prs? ICYMI: @abhisheksparikh
I agree, would be a nice feature. Somehow it should accept any of the inverter models, or, be some kind of extension within the existing functions so that a user doesn't have to choose to call an inverter function or this new function.
We could also open issues for:
- inverter temperature derating (would be easy if there is a source for the %AC power / degree C relationship)
- non-unity power factor operations (I think this is difficult, as it would require knowledge of how efficiency changes with power factor, which is not measured AFAIK).
I'd be happy to work on this in the medium term future. Is there a reference that I should work off of? Is a reference necessary for what would essentially be a point on a curve finder?
@kurt-rhee I think the request is to find the point on the IV curve where the AC output of the inverter matches a desired value. pvsystem.i_from_v (or its v_from_i counterpart) seems relevant, for the DC input. Some thought is needed to define how this capability faces the user - additional inputs for a standard inverter function? Or some new function that lives in pvsystem? I don't have an opinion here.
Also, if the inverter has multiple Arrays as inputs, and the Arrays have different conditions, there are likely to be multiple solutions. For now, I think we should assume a single Array and worry about the multiple MPPT case later.
Hi Kurt, I’m happy to jump on a call to discuss. I’m not sure if there are any references, but if not we could put this in the example gallery. I think the description already explains it well, but to clarify, the system must operate off-MPP when clipping, but finding this operating point is not trivial. It’s subject to two constraints:
- Ideally AC out from the inverter must equal the rated power (possibly temperature derated)
- The dc voltage and current must be on the system IV curve
So we probably need to iterate or use a bounded root finder like brentq. Perhaps we can just call this function?
ideal_offmpp_clipped_operation(system, ac_rating): -> (v_dc, i_dc)
Another consideration: maximum/minimum voltage/current limitations of the inverter. If there is no suitable point to the right of the MPP, should the algorithm "fall back" to looking for a suitable point on the left (low voltage, high current) side?
Whether the algorithm interpolates a pre-computed I-V curve, or is given SDM parameters and calls i_from_v internally, must also be decided.
The list of considerations here is already long enough to make me wonder if we are "inventing" too much. Has anyone looked for a reference we could follow? I haven't.
I also haven't been able to find a reference. Both PlantPredict and SolarFarmer have some notes about keeping the inverter input voltage and current within some operating window, but neither have references.
https://mysoftware.dnv.com/download/public/renewables/solarfarmer/manuals/latest/CalcRef/Inverter/Inverter.html
https://terabase.atlassian.net/servicedesk/customer/portal/3/article/1292009483
Good points about minimum voltage and other constraints. PVsyst also has help page with nice diagram.
I propose one of two options:
- Without a reference this is called the “ideal” operation. IMHO opinion this is sufficient and no reference is required because we are simply solving a set of constraints.
- put this in the example gallery
IMHO the reference situation is getting out of hand. Solving a set of equations is math. Only implementations of algorithms should require a reference. We are not describing a sky model here, the two situations are not comparable. There are generally available references for math and other basic solar facts.
Good references serve different useful purposes, but perhaps there's no need to get hung up on that right now if the fall-back is example gallery? Once there is a solution, we'll see how straight-forward it is.
This is interesting: Essentially we are putting a (temperature-dependent) upper bound on the quantity that we are trying to maximize. I don’t think anything a-priori prevents one from defining this like any other nonlinear constraint https://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.NonlinearConstraint.html#scipy.optimize.NonlinearConstraint, and then solving for the maximum power as before, but under this additional constraint. I might try to add this feature to the MPPT-under-mismatch algorithm that I put together in https://github.com/pvlib/pvlib-python/pull/1923. Of course, the devil might be in the details!
Okay finally getting around to this.
My initial thought is to create a function to solve for maximum power at the given ambient temperature #1199 and then I like @mikofski 's brentq solution for calculating the operating point given the constraint.
In a utility scale photovoltaic site with a central inverter, a given inverter will be connected to a set of combiners. Each of these combiners will then be connected to a set of modules which are not necessarily unique. For example, even intra-combiner there can be strings that have different bin classes.
This means that we will need to combine all of the IV curves together into a single IV curve before solving for the point that satisfies the maximum power constraint. This would then necessitate that a user provide a given IV curve in a 2D array of voltages and their corresponding current values.
Perhaps I am overthinking this though, looking forward to hearing everyone's thoughts.
Regarding…
This means that we will need to combine all of the IV curves together into a single IV curve before solving for the point that satisfies the maximum power constraint.
While this is true, if we only consider the “ideal” case, the situation when not all irradiance, module, & string conditions are known, could we first test the general case where the entire system is uniform? Then afterward we could provide particular solutions for more detailed scenarios? Would you be open to this approach first?
combine all of the IV curves together into a single IV curve before solving for the point that satisfies the maximum power constraint.
That's how a single MPPT works, but I don't think that's how clipping works for the whole inverter. I'm no expert by any means, but my understanding is that each MPPT applies the DC current and power limits. In contrast, the temperature limit is applied to the entire device, and I don't know how a temperature curtailment is apportioned among the MPPTs.
Maybe for simplicity sake we can descope away from temperate derating for now and just find the voltage that allows the inverter to operate within its constraints. Take this step by step and solve the simplest most idealistic case first. Then add complexity one at a time. Agile like, okay?
Whether the algorithm interpolates a pre-computed I-V curve, or is given SDM parameters and calls i_from_v internally, must also be decided.
I think the function should accept an IV curve (calculated with whatever algorithms and complexity the user desires), apply the inverter parameters and logic, and output the operating point.
combine all of the IV curves together into a single IV curve before solving for the point that satisfies the maximum power constraint.
That's how a single MPPT works, but I don't think that's how clipping works for the whole inverter. I'm no expert by any means, but my understanding is that each MPPT applies the DC current and power limits. In contrast, the temperature limit is applied to the entire device, and I don't know how a temperature curtailment is apportioned among the MPPTs.
The total inverter power limit is probably the most frequent on to be reached and therefore the most important. Temperature de-rating is no more complicated: it just reduces the inverter total power limit value.
Typically the sum of individual MPPT current and power limits is greater than the total inverter current and power limits, so if you have multiple inputs, there has to be some logic to manage that.
Maybe for simplicity sake we can descope away from temperate derating for now and just find the voltage that allows the inverter to operate within its constraints. Take this step by step and solve the simplest most idealistic case first. Then as complexity one at a time. Agile like, okay?
Sure, but in this case it would be wise to keep DC current limits and temperature derating in mind as we alter the MPP code, since we intend to add those other capabilities.
On a related note, how do people generally decide how many IV points to calculate when combining IV curves?
About 10,000 points seems reasonable. I tend to concentrate them around knees like the max power point.
10,000
That's a point every 10mV. I think one could get a satisfactory curve with 1000 points, or even fewer.
A string could be 1500[V] so 10,000 points evenly spaced is 150[mV], but between Vmp & Voc, current changes very fast. For example, a Longi LR5-72HBD-550M has only 8[V] difference between Vmp & Voc at STC, but changes by 13[A]. If an inverter has strings of 30-qty modules (16.5[kW]), then a 3.3[MW] inverter would have 200 strings, so in a space of 240[V] current changes by 2,600[A]! This region, from Vmp to Voc, will be where off-MPP operation happens, so having a lot of points helps keep current resolution more precise in my opinion.
This is great insight. @mikofski is there a good algorithm for concentrating iv points around the MPPs?
We can reduce the amount of points needed by only considering voltages within the inverter operating window (excluding 0V to Vmin), but the above comment from mark definitely helps me understand what sort of bin? size we need between iv points
is there a good algorithm for concentrating iv points
Unfortunately I don’t have good advice. In the past I’ve used two log-spaces reflected at Vmp but it’s not perfect. (See bishop88.) Also you may encounter many local minima, so an adaptive mesh that is directly proportional to dI/dV might work better. It’s sort of an implicit problem - you need the mesh to know what mesh to use. :/
In my experience the points accumulate in the right places as I build up the composite IV curve, so I never thought much about how many points in total.
Forgive my ignorance, but I am not sure how to create a composite IV curve without selecting a bunch of reference voltages to calculate current at.
A part of me thinks that it might be possible to only combine points on curves that correspond with another curve's MPP, but I am not sure.
Appreciate any insights!
To "add" IV curves for devices in series, I think in terms of drawing horizontal lines, and adding the voltages at each current value. That requires extending each IV curve to currents up to the maximum Isc for all curves. A model for this negative bias part of the curve is thus needed.
The bishop88 functions provide a model. But there are convergence problems when solving the extended IV curve using the Newton method (#1757), and the BrentQ method isn't vectorized, so calculations would be very slow for a large set of curves.
I've taken to simply linearly extending the IV curve to the breakdown voltage and then drawing a vertical asymptote. That simplified calculating current at negative voltages and makes the addition of many curves (or time series of many curves) feasible, without a meaningful loss in precision.
#1781 is a start at a function to add IV curves. It got hung up on the convergence and performance issues with the bishop88 functions. It would be great to see that pushed forward.
It seems to me that the "clipping off-mpp operation point calculation" function should be tested against a handful of IV curves ranging from simple to complex and perhaps with a range of discretization. But if the function merely accepts and IV curve as an input, which I believe is the right way forward, then for now these IV curve calculation problems can be solved by hacky one off code instead of robust pvlib implementations.
Is adding IV curves in scope for this PR? I was thinking the function would only take in a single IV curve then find the operating point that meets the inverters constraints (if not @ MPP) - maybe this is oversimplifying but even multi MPPT inverters have to first handle this individually for each channel right?
On a related note, how do people generally decide how many IV points to calculate when combining IV curves?
@kurt-rhee perhaps you can start a separate discussion on this topic, if needed.