Multiple arrays in a PV system

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]

Summarizing some offline conversations for the benefit of all. It seems we are converging to the following pattern:

• add an Array class with a small list of attributes and methods as suggested here
• an Array instance has a single value of tilt, azimuth, etc.
• PVSystem will have a new arrays attribute that is assigned a list of Array instances. PVSystem methods will be modified to operate on elements of PVSystem.arrays. The use of list here is deliberate so that the following works regardless of the length of self.arrays

for array in self.arrays:

• to preserve the current interface, PVSystem.surface_tilt will remain (for a deprecation period), and PVSystem.__init__ will handle conversion of e.g. PVSystem.surface_tilt to an instance of Array assigned to PVSystem.arrays[0]. That way, old user code should still work, except for the case where a user was passing an array to PVSystem.surface_tilt and somehow getting away with it.

I still need to look uphill to ModelChain, where I’m thinking there will be substantial changes in that the attributes recording output of modeling steps may become lists e.g. ModelChain.dc is no longer a Series, it is a list of Series. Might be a more elegant way to handle that.

This pattern meets the use case of a PV system with multiple arrays, with each array connected to a separate MPPT on one system-wide inverter. Follow-on work can extend this pattern to a PV system with one inverter per array.

The case of multiple arrays feeding one inverter without separate MPPT is not addressed, but isn’t ruled out by this pattern. This case would require a new function to compute DC current and voltage at the inverter input, and it’s not clear how that should be done (Kirchoff’s laws of course, but, one likely needs parameters that aren’t already in pvlib).

@wfvining fyi

[wholmgren]

What about an Array with a small number of attributes:

• surface_tilt
• surface_azimuth
• module_parameters
• temperature_model_parameters
• racking_model
• albedo

and methods:

• get_aoi
• get_irradiance
• get_iam

so that a higher level object like PVSystem can do more complicated things? I don’t want to embark on a big redesign only to find that we’ve locked ourselves out of system design and operation that become far more common over the next 5 years (PVSystem is currently 5 years old).

Perhaps rebuild PVSystem to be based on one or more Array objects that it creates based on the inputs? Instances of an Array class could be constructed by PVSystem and hidden for now, that’s a thought.

Is the motivation for this just API compatibility with the existing PVSystem? I’m not too worried about that at this point in the discussion.