Design Optimization in Constrained Applications
Inside this Article
A constraint does not simply determine the size of a system. Different constraints applied to the same system will lead to dramatically different design choices.
Solar designers all want to make sure they are building an optimized design, or at least “the right” design. But not everyone thinks rigorously about what optimization means. The most basic version of an optimization exercise involves a variable that you change and an objective that you try to maximize: “If I change X, does Y improve?” A slightly deeper understanding of solar optimization acknowledges the importance of inputs such as module cost, electricity value and array location.
Constraints are part of every system design. In fact, they are so commonplace that designers often factor them in without explicitly calling them out. However, few engineers realize that the constraint drives design choices. The naïve concept of a constraint is that designers first determine the optimal array—given the location, costs and so forth—and then look at constraints to understand how much of that system they can build. In practice, the constraints drive the optimal design, and if the constraints change, so does the design.
Here I provide context for how to think about constraints holistically. I then explain the most common constraints. Finally, I show that even with the same set of inputs, such as system costs and utility rates, changing the fundamental constraint can lead to a dramatic change in the optimal system design.
Approaching Constraints Holistically
Constraints might seem like an annoyance to avoid or minimize, but they are intrinsic to real-world activities. If that seems counterintuitive, keep in mind that a system without constraints would be infinitely large!
Often a constraint is so self-evident that you do not think about it explicitly. For example, when building a system on a commercial rooftop, a designer will typically begin the engineering process with the whole roof in mind. The tenant almost always has the energy demand and the budget to justify building out the whole roof; therefore, it is only a question of how to best populate the available area. In this scenario, the designer takes for granted that the roof area, not the budget, will be the dominant constraint of the array. Similarly, for many residential applications, particularly as net metering is on the decline, a designer might instinctively orient the design process around the homeowner’s energy demand, making this the factor that drives many other decisions about the system. These are both examples of constraint thinking at work.
Assess the hierarchy of constraints. As the optimization framework in Figure 1 illustrates, a fairly universal set of attributes commonly constrain a system: the budget, the available roof or land area, and the energy demand. In different applications, these various constraints become more or less relevant. Typically one primary constraint drives a system design. You might think that a system is both space constrained and budget constrained, but in practice, one of those constraints imposes limits first. For example, the budget might constrain the system to be smaller than the rooftop would allow. In that case, the financial budget is the actual bottleneck, even though there is technically also a space constraint. While one constraint might be the primary constraint for an array, all the constraints will exist at some level. No project has infinite land. No financier has an infinite budget. And no off-taker has an infinite demand for energy.
Identify the bottlenecks. An analogy can be helpful here: Any factory machine process has a bottleneck, a step in the process that sets the rate of production for the entire line. When you solve one bottleneck—say, by improving the machine’s speed or adding a second machine to share the load—the result is not that you get rid of all bottlenecks, but rather that the bottleneck shifts to the next-slowest step in the process. Since there will always be a bottleneck somewhere in the system, the goal of the optimization process is not to eliminate bottlenecks but rather to manage them.
Similarly, solar designers always have constraints. The goal is to understand and harness them in designing and delivering the system. One of the key lessons is that you should never starve the bottleneck (the constraint) of resources. In other words, the slowest machine in a manufacturing operation should never spend a moment waiting, since that machine will determine the maximum throughput of the factory. We can apply the same approach to constraints in solar design.
Focus optimization efforts on constraints. Identifying the bottleneck of the design process—the rate-limiting factor—allows designers to focus their efforts on optimizing the array based on that primary constraint. In a space-constrained array, the designer seeks to maximize the energy yield per unit area. Where ac power is capped based on the interconnection capacity, the designer seeks to maximize financial benefits against that maximum power rating. You can begin to intuit why different design constraints, in the hands of a skilled system engineer, lead to different design outcomes.