*4.2. Social Welfare Ordering*

The social welfare ordering is constructed by assigning a social welfare metric to each node *Ni* in the RIG. This then applies that specific notion of social welfare to the group of objectives within that node, which enables selecting a final solution from the Pareto set through a simple algorithm, which will start by visiting node *N*<sup>1</sup> in the RIG and apply the social welfare criterion associated with that particular node to the part of the normalized cost vector that contains costs from objectives in node *N*1. This will yield a subset of one or more solutions that are equal (in terms of the value returned by the applied social welfare metric) from the perspective of objectives in node *N*1. If this subset contains only one solution, the algorithm will terminate and return the solution. Otherwise, the algorithm will continue to traverse the RIG until (a) a subset containing exactly one solution is found or (b) the entire RIG has been traversed. In the latter case, the algorithm will return an arbitrary solution from the final subset, as every solution in this subset is considered equally good from the perspective of every objective in the optimization instance. The pseudo code for the social welfare ordering algorithm can be found in Algorithm 1. The concept of social welfare ordering ensures that higher ranking objectives are prioritized over lower ranking ones during the selection of the final solution. Further, the application of a social welfare metric to each node in the RIG ensures that any conflicts are resolved based on the social welfare metric applied to the particular node level.

#### **Algorithm 1** Pseudo code of the social welfare ordering algorithm.

1: *set* ← *PF set* initially contains the entire Pareto set. 2: 3: **while** *set*.*Size*() > 1 **and** *rig*.*HasNextNode*() **do** 4: 5: *root* <sup>←</sup> *rig*.*NextNode*() 6: 7: *set* <sup>←</sup> *root*.*SocialWel f areMetric*(*set*) 8: 9: **end while** 10: 11: *finalSolution* ← *set*.*GetSolution*()

#### **5. Experimental Setup**

To test the influence of the social welfare ordering and different social welfare metrics, we considered a set of experiments built around a case with commercial greenhouse growers. The case and the associated formal problem definition are described in this section along with the optimization framework and its associated configuration used to solve the problem.

#### *5.1. Case*

In northern countries, Commercial Greenhouse Growers (CGGs) are heavy consumers of energy used to power supplementary lighting, which is needed to facilitate plant growth [14]. We considered a case in which a Resource Domain (RD) was responsible for allocating energy to three CGGs. In this scenario, the task of the RD was to ensure that energy allocation never exceeded system-wide energy limits while adhering to the best of its ability to the energy needs of the CGGs. CGGs use

energy for supplemental light to increase plant yield. However, light is not provided to the plants arbitrarily [20]. Long-day photo-periodic plants require long, uninterrupted periods of light to bloom. Here, supplemental light is often used to extend the natural day length. Short-day plants on the other hand require shorter days and are sensitive to long, uninterrupted periods of darkness. Here, supplemental light is used only when natural daylight is scarce, and only for a limited period of time. Day-neutral plants are insensitive to the length of the day or night and will always be able to utilize the provided supplemental light. To simplify the complexity of the optimization problem, we assumed that the CGGs had only two consumption levels, namely on, at which stage it would consume 1 MW of electricity, or off, where consumption would be 0 MW. However, each CGG can be on or off independent of the other CGGs. This type of problem translates to any domain in which energy allocation is necessary to run a facility.

The case was modeled as a multi-objective multi-variable optimization problem with 7 objectives and 3 variable vectors in total. We optimized to find a 24 h energy allocation schedule for each of the three CGGs.

We used 3 variable vectors to represent the hourly planned electricity allocation for each of the CGGs. To represent 24 h, we set *n* = 24. Here, each element could take on a value of either 0 or 1 (MW). Their definition is found in Equation (14).

$$\begin{aligned} \vec{x} &= [x\_{1}, \ldots, x\_{n}] \\ \vec{y} &= [y\_{1}, \ldots, y\_{n}] \\ \vec{z} &= [z\_{1}, \ldots, z\_{n}] \\ \text{where} \\ x\_{i}, y\_{i}, z\_{i} &\in [0; 1] \end{aligned} \tag{14}$$

The 7 objectives in the optimization problem include 1 system-wide energy constraint objective and 6 objectives that map to the 3 CGGs, 2 objectives for each CGG.

Equation (15) formulates the objective function for the system-wide energy limit objective. It considers the combined energy allocation for each of the CGGs and compares it to its preference vector *pec* by summarizing the absolute distance between elements of the combined allocation vector and the preference vector.

$$f\_1(\vec{x}, \vec{y}, \vec{z}) = \sum\_{i=1}^{n} |(x\_i + y\_i + z\_i) - p\_{\text{cc},i}| \tag{15}$$

Each of the CGGs has 2 objectives representing it. One objective is focused on the amount of energy allocated and the time at which it is allocated for the CGG, whereas the other objective is concerned only with the total amount of energy allocated to the CGG, disregarding the time at which it is allocated. This may seem redundant, but in the context of this optimization problem, this means that shifting energy is perceived as better for the consumers than shedding or removing the energy, in cases where insufficient energy is available in one or more time slots.

Equations (16) and (17) show the definitions for the objective that is concerned with the allocated amount and time of allocation and the objective that is concerned only with the combined allocation across the entire schedule for *CGG*1. Equations (18)–(21) are similar objective definitions for *CGG*<sup>2</sup> and *CGG*3.

$$f\_2\left(\overrightarrow{\mathbf{x}}^{\flat}\right) = \sum\_{i=1}^{n} \left| \mathbf{x}\_i - p\_{\varepsilon \boxtimes \mathbf{J}^1 \vec{\boldsymbol{\omega}}} \right| \tag{16}$$

$$f\_{\mathfrak{F}}\left(\vec{\mathfrak{x}}\right) = \left| \sum\_{i=1}^{n} \mathbf{x}\_{i} - \sum\_{i=1}^{n} p\_{\mathbf{c}\mathfrak{g}\mathfrak{X}^{\mathfrak{F}},i} \right| \tag{17}$$

$$f\_4\left(\vec{y}\right) = \sum\_{i=1}^n \left|y\_i - p\_{\text{cg\\$}\{2,i\}}\right|\tag{18}$$

$$f\_{\vec{\nabla}}(\vec{y}) = \left| \sum\_{i=1}^{n} y\_i - \sum\_{i=1}^{n} p\_{\text{cg}\vec{\otimes}2,i} \right| \tag{19}$$

$$f\_6\left(\vec{z}\right) = \sum\_{i=1}^n \left|z\_i - p\_{c\text{gg3},i}\right|\tag{20}$$

$$f\_{\mathcal{T}}\left(\vec{z}\right) = \left| \sum\_{i=1}^{n} z\_i - \sum\_{i=1}^{n} p\_{\text{c\!\!\!g\text{S}}^{\text{\!\!\! \text{\!\!\!}}} \right| \tag{21}$$

The combined optimization problem is defined in Equation (22).

$$\begin{aligned} \min & \left( f\_1 \left( \vec{x}, \vec{y}, \vec{z} \right), f\_2 \left( \vec{x} \right), f\_3 \left( \vec{x} \right), f\_4 \left( \vec{y} \right), f\_5 \left( \vec{y} \right), f\_6 \left( \vec{z} \right), f\_7 \left( \vec{z} \right) \right) \\ \text{s.t.} & \\ & x\_i, y\_i, z\_i \in \left[ 0; 1 \right] \end{aligned} \tag{22}$$

#### *5.2. Optimization Framework*

The multi-objective optimization problem described in Section 5.1 was solved using Controleum [21,22]. Controleum is an object-oriented genetic algorithm framework. Controleum is one framework to employ a Pareto set to store outcomes. The Pareto set is used to store populations of solutions between evolutions, and once optimization has terminated, a final solution is drafted from the resulting Pareto set. To this end, Controleum uses objective priority and a non-normalized utilitarian social welfare to select a final solution from the Pareto frontier.

Controleum uses the concern abstraction to represent objectives and the issue abstraction to represent optimization variables as vectors. An optimization context in Controleum is defined by *N* concerns that negotiate over *M* issues. Each concern *cn*, *n* ∈ *N* defines an evaluation function that takes into account values of each of the issues, *em*, *m* ∈ *M*, which are part of the objective function. Further, the evaluation function takes into account a concern-specific preference vector, which describes a target that the concern is aiming for. An issue, *em* = {*e*1,*m*,*e*2,*m*, ...*et*,*m*} defines a number of vector elements *t*, as well as the range from which these elements can draw values. In the context of Controleum, a solution, *C*, is a set of values for each of the *M* issues defined. The solution is defined as *C* = *sC*,1, ...,*sC*,*m*, where *sC*,*<sup>i</sup>* is the value for issue *ei* in solution *C*.

The initiation of the algorithm and the optimization process itself was explained in depth in [5], in which Controleum was also extended by (1) introducing the notion of the relative importance of objectives to determine their ordering, (2) utilizing normalized costs of objectives in the selection of a final outcome, and (3) implementing the notions of social welfare presented in Section 3. This enables the configuration of Controleum to use a specific social welfare ordering by deciding on a social welfare metric and by assigning relative importance to objectives.

#### 5.2.1. Issue Configuration

The variable vectors described in Section 5.1 were translated to three corresponding issues, *M* = 3, in Controleum. Each issue was configured with *t* = 24 to cover 24 1 h slots. This meant that each solution comprised 3 vectors, each with 24 values of either 0 or 1. This constituted a complete allocation for each of the CGGs presented as part of the case.

#### 5.2.2. Concern Configuration

Each of the objectives described in Section 5.1 was translated 1:1 to concerns. This meant that we had 7 concerns in Controleum representing the 7 objectives in the optimization problem. These 7 concerns were distributed across 3 types of concerns; we had 1 system-wide energy concern (*SEC*), 3 CGG resource concerns (*CRC*), which consider the amount of energy allocated and the time at which it is allocated for each of the CGGs, and finally, 3 CGG resource sum concerns (*CRC* − *sum*) that consider the total amount of energy allocated and disregard the temporal dimension. Algorithms 2–4 show a pseudo code representation of each of these types of concerns.

**Algorithm 2** Pseudo code representation of the evaluation method in the system-wide energy concern.

**Precondition:** *n* is the number of hours being allocated.

1: **Precondition:** *pre fSEC* is the system-wide energy limit vector with *<sup>n</sup>* elements.

```
2:
3: function EVALUATE(solution)
4:
5: allocsum ← Int[n]
6:
7: while solution.HasNextIssueValue() do
8:
9: allocsum ← allocsum + solution.NextIssueValue()
10:
11: end while
12:
13: result ← calcManhattenDistance(pre fSEC, allocsum)
14:
15: return result
16:
17: end function
```
**Algorithm 3** Pseudo code representation of evaluation method of the CGG resource concern (*CRC*).

**Precondition:** *n* is the number of hours being allocated, and *x* is a CGG ID from 1-3.

1: **Precondition:** *pre fx* is the demand for energy in CGG *<sup>x</sup>*.

```
2:
3: function EVALUATE(solution)
4:
```

```
5: allocx ← solution.getIssueValue(x)
6:
7: result ← calcManhattenDistance(pre fx, allocx)
8:
9: return result
10:
11: end function
```
**Algorithm 4** Pseudo code representation of evaluation method of the CGG resource sum concern (*CRC*).

```
Precondition: n is the number of hours being allocated, and x is a CGG ID from 1–3.
```

```
1: Precondition: pre fx is the demand for energy in CGG x. 2:
 3: function EVALUATE(solution) 4:
 5: allocx ← solution.getIssueValue(x) 6:
 7: allocSumx ← 0, pre f Sumx ← 0
 8:
 9: for i = 0, n do -
                                                          Sum all elements in both vectors
10:
11: allocSumx ← allocSumx + allocx[i] 12:
13: pre f Sumx ← pre f Sumx + pre fx[i] 14:
15: end for
16:
17: result = abs(allocSumx − pre f Sumx) -
                                                                Absolutes sum difference
18:
19: return result
20:
21: end function
```
The variable *pre fSEC* denotes the system-wide energy constraint. As seen from the pseudo code in Algorithm 2, the absolute differences between elements in this vector and the sum of elements in the allocations for each of the CGGs are considered. This means that the system will not tolerate allocations above or below the system-wide energy constraint. We ran two sets of experiments where we varied the value of *pre fSEC*. In one case, the value of the *pre fSEC* vector was equal to the sum of elements in each of the demand vectors of the CGGs. This is illustrated in Figure 2, where the columns are the demands presented by each of the CGGs and the dotted line is a plot of *pre fSEC*. This translates into a resource allocation problem where sufficient resources are available and where the problem is one of allocating these resources to each of the CGGs in a way where every CGGs gets what it demands.

**Figure 2.** Demand profiles of Commercial Greenhouse Growers (CGGs) and the system-wide energy constraint (line) with sufficient energy. SEC, system-wide energy concern.

In the other case, we introduced a constraint on the amount of resources available to the system, by altering *pre fSEC* as shown in Figure 3. Here, we see that *pre fSEC* did not match the need for energy in Slots 11, 12, and 13. In a resource allocation context, the task of the system in this case was to gracefully degrade. Here, the definition of graceful degradation depended on the resource allocation strategy: some systems would like to see the consequences distributed across as many entities as possible. Here, a strategy that distributed resources across entities in a fair manner was needed. In other cases, the number of entities affected by the system state should be reduced. Here, the resource allocation strategy should ensure that the least possible entities were influenced, at the expense of fewer entities, which would be influenced more severely.

**Figure 3.** Demand profiles of CGGs and the system-wide energy constraint (line) with insufficient energy.
