Multiple arrays in a PV system

[cwhanse]

I'm proposing to add capability to model more than one array in a PV system. Defining the term "array", I mean a collection of PV modules at the same orientation (tilt and azimuth). Many actual PV systems have several arrays, distinguished by different orientation and/or number of modules and strings of modules.

The current PVSystem defines the DC side of a PV system using modules_per_string and strings_per_inverter and applies attributes surface_tilt and surface_azimuth to all modules. A PV system may have a single inverter. This model implicitly describes a PV system with a single array.

@wholmgren have discussed this a bit offline and think a way forward would be to make PVSystem attributes iterable. For example, surface_tilt could contain a list or array, with each element being an array of tilts to be applied to one of the arrays comprising the PV system. PVSystem and ModelChain methods would be extended to perform calculations for each array in the PV system, broadcasting where needed.

Two principles guiding this proposal:

1. maintain the current interface for modeling systems with a single array. It is simple but effective, and modeling a single array system shouldn't become more complicated.
2. methods should return the type indicated by the input attributes, so that a user doesn't need to deal with lists of length 1 when modeling a single array system.

We discussed, and disfavor other approaches:

• a new class for PV systems with multiple arrays, which not appealing when considering the duplication of code, and the likely complication of ModelChain methods.
• subclassing PVsystem or adding attributes, either of which look to be confusing for users.

Open for comments here, before I start a branch to work on this feature.

#457 is relevant. Having multiple arrays lays the groundwork for modeling inverters with multiple MPPTs.

[cwhanse]

Exploring this a bit, to settle on a pattern, using a copy of the PVSystem.get_aoi method:

def get_aoi(surface_tilt, surface_azimuth, solar_zenith, solar_azimuth):
    """Get the angle of incidence on the system.

    Parameters
    ----------
    solar_zenith : float or Series.
        Solar zenith angle.
    solar_azimuth : float or Series.
        Solar azimuth angle.

    Returns
    -------
    aoi : Series
        The angle of incidence
    """

    if (isinstance(surface_tilt, int) or
        isinstance(surface_tilt, float) or
        isinstance(surface_tilt, pd.Series)):
        return irradiance.aoi(surface_tilt, surface_azimuth,
                              solar_zenith, solar_azimuth)

    aoi = [irradiance.aoi(t, a, solar_zenith, solar_azimuth)
        for t, a in zip(surface_tilt, surface_azimuth)]
    # match type of self.surface_tilt
    if isinstance(surface_tilt, np.ndarray):
        aoi = np.asarray(aoi)  # make it an array of Series?

    return aoi


from pvlib import location
loc = location.Location(latitude=35, longitude=-116)

dt = pd.date_range(start='2020-09-20 00:00:00', end='2020-09-22 00:00:00',
                   freq='1H').tz_localize('Etc/GMT+7')
sp = loc.get_solarposition(dt)

# both are int/float
pv = PVSystem()
aoi = get_aoi(pv.surface_tilt, pv.surface_azimuth, sp['zenith'], sp['azimuth'])

# both are arrays of same length
pv2 = PVSystem(surface_tilt=np.array([0., 10.]),
               surface_azimuth=np.array([180., 190.]))
aoi2 = get_aoi(pv.surface_tilt, pv.surface_azimuth, sp['zenith'], sp['azimuth'])

This runs with PVSystem.surface_tilt as an int, float, Series or array, with PVSystem.surface_azimuth of the same type and dimension. Discovered some challenges:

1. The current method returns a Series with index taken from the input solar_zenith and solar_azimuth Series. The above function maintains that behavior if the surface_tilt is a singleton or Series with the same index as solar_zenith and solar_azimuth, but returns a 2D ndarray if surface_tilt is any other kind of iterable.
2. PVSystem.surface_tilt can arrive as a time-indexed Series for a single array on a tracked system. This implies that we would need to restrict PVSystem.surface_tilt to surface_tilt: float or array rather than surface_tilt: float or array-like, because if surface_tilt is a Series of tilt indexed by the arrays, then the code still runs but the returned aoi is garbage (see *)
3. this seems like a clumsy way to get around the fact that neither int nor float are interable.
4. I don't know how to handle the broadcasting case, when e.g. surface_tilt is an array but surface_azimuth is a float, if not using a complicated sequence of if isinstance statements. If this is needed, there's got to be a better way.

• The underlying function pvlib.irradiance.aoi_projection uses the * operator rather than the pandas multiply method. When the factors are Series with different indexes, for the product pandas merges the indexes and fills in nan for indices that aren't in both indexes. This result is not what a user would expect to see.

[wholmgren]

It might simplify things if we said PVSystem could accept any iterable of tilt or azimuth but coerce it into a standard type. For example

class PVSystem:
    def __init__(surface_tilt, surface_azimuth,...):
        self.surface_tilt = np.array(surface_tilt)  # or np.array(surface_tilt).tolist()
        self.sufrace_azimuth = np.array(surface_azimuth)

The following behavior is relevant:

In [7]: np.array(1)
Out[7]: array(1)

In [8]: np.array(1).tolist()
Out[8]: 1

In [9]: np.array([1]).tolist()
Out[9]: [1]

The underlying function pvlib.irradiance.aoi_projection uses the * operator rather than the pandas multiply method. When the factors are Series with different indexes, for the product pandas merges the indexes and fills in nan for indices that aren't in both indexes. This result is not what a user would expect to see.

Two things to try:

1. Swap the multiplication order in aoi_projection.
2. In SingleAxisTracker.get_aoi method, change aoi(surface_tilt,...) to aoi(surface_tilt.to_numpy(),...`

[cwhanse]

It would simplify the typing, but I think we have to resolve the overloading of PVSystem.surface_tilt first.

1. For a PVSystem comprising N several arrays at fixed orientation, PVSystem.surface_tilt is an iterable of N tilts, one for each array.
2. For a PVSystem comprising N arrays with tracking, PVSystem.surface_tilt would be an iterable of length N, each element of which is a Series.

Perhaps a way forward is to use if PVSystem.axis_tilt: to decide how to resolve the ambiguous case when PVSystem.surface_tilt is a Series for a PV system with a single array with tracking.

[wholmgren]

I'm a little confused...

For a PVSystem comprising N arrays with tracking, PVSystem.surface_tilt would be an iterable of length N, each element of which is a Series.

That's a SingleAxisTracker, which can and does reimplement PVSystem methods as needed to deal with these complexities.

[cwhanse]

Aha. PVSystem.get_aoi needs only handle fixed tilt cases, because SingleAxisTracker will handle the tracker cases. I'm tracking now.

[mikofski]

• use duck typing instead of instance checking
• There are a bunch of broadcasting tools in NumPy, try broadcast

[ncroft-b4]

Just as another idea at risk of disrupting this line of thought. Have you considered creating a new type of "Multi Array ModelChain" that could implement and iterate through multiple ModelChains, instead of changing anything with PVsystem? My thinking is that users who use PVsystem typically only need it for single types of arrays given it can only have a single inverter anyway, and if they need multiple sub-arrays they've already built that out of multiple PVSystems. Thus the needs for multiple sub-arrays are likely going to be ModelChain users.

A multiple array ModelChain could accept a single location, an iterable of multiple PVsystem parameters, single inputs for ModelChain parameters, and an iterable of 'inverters_per_system'. The class would then create a list of multiple PVsystem and multiple ModelChain and could have a function to run_model on a weather input that would run each of its sub_models, multiply the ac outputs for the number of inverters of each system, and sum the outputs.

The benefit here would be that all the underlying code could be left as is and I think it would be a relatively simple to implement. But this it would be more of an approach of adding a new wrapper around what is already there rather than building functionality from the bottom-up.

So it could be something like
multiarraysystem = pv.modelchain.MultiArrayModelChain(Location, system_parameters, inverters_per_array, **model_chain_parameters)

where system parameters is a list of dicts and inverters_per_array is a list of integers, and when it initializes is creates unique instances of PVsystem for each dict in the list and also creates instances of ModelChains with them. Then a function like multiarraysystem.run_model() would run the model for each sub-chain and add them together for one output.

[mikofski]

@ncroft-b4 interesting idea, but I think @cwhanse is trying to address subarrays that are connected to the same inverter or to different inputs of a multi-mppt inverter (see #457 )

[mikofski]

Possibly relevant to OpenPVspec and #96

[adriesse]

Or how about using a subarray as a building block and creating a multi-subarray inverter?

[cwhanse]

@adriesse I'm not understanding your suggestion - can you elaborate?

@ncroft-b4 That's a thought... @mikofski the system I have in mind is one inverter with several non-identical DC arrays. @ncroft-b4 is right that the PVSystem attributes I'm taking up here would not address the case of a system with several inverters with different arrays.

[mikofski]

Although several systems connected to different inverters is trivial, just calculate each separately. We don't have any ac post processes. So the most pressing case is the one you and I both describe:

[several] subarrays connected to the same inverter or to different inputs of a multi-mppt inverter

[adriesse]

I'm not understanding your suggestion - can you elaborate?

It's hardly a fully thought-out idea. It just seems a System class could get quite complex as it grows to accommodate more and more types of systems. Perhaps a Subarray class could help to make it more modular.

[cwhanse]

@wholmgren and I discussed an Array class, we haven't ruled it out. I think we are hoping that iterable PVSystem attributes may do the same job.