## 4 The Cooperative Optimization Algorithm
### Feedback Component  
The FC is responsible for extracting as much information as possible from the users with as few interactions as necessary in order to not to fatigue them. In the context of the COA framework, user interactions are understood as letting a user evaluate (a small number of) _location scenarios_. Similar to a solution, a location scenario is a subset of locations in \(V\) at which service stations are assumed to be opened. In contrast to a solution, the budget constraint (1) does not need to be respected, and a location scenario may, therefore, include an arbitrary number of service points. Recall Figure 2 for an example of how an interaction with the COA framework may look from the perspective of a user. Let \(S\subseteq V\) be such a location scenario provided to a user \(u\) with respect to one of the user's SPRs \(r\in R_{u}\). It is then assumed that the user returns as evaluation of the scenario \(S\) either a best suited location \(v_{r,S}\in S\) and the corresponding suitability value \(w(r,v_{r,S})>0\) or the information that none of the locations of the scenario \(S\) is suitable. The latter case implies that \(w_{r,v}=0\) for all \(v\in S\). In case multiple locations are equally well suited, we assume that the user selects one of them at random. It is assumed here that the suitability of a location w.r.t. an SPR can be specified by the user on a five-valued scale from zero, i.e., completely unsuitable, to one, i.e., perfectly suitable; a more fine grained evaluation would not make much practical sense. Clearly, this definition of user interaction is simplified and idealized, particularly as we assume here that all users always give precise answers. In a real application, the uncertainty of user feedback and the possibility of misbehaving users who intentionally give misleading answers also need to be considered among other aspects. Moreover, it would be meaningful to extend the possibilities of user feedback. For example, users could be allowed to optionally rate more than one suitable locations for an SPR in one scenario or to make suggestions which locations to additionally include in a scenario as we considered it in Reference [13]. In each iteration of COA, users are presented with individual sets of location scenarios \(\mathcal{S}_{r}\) for their service point requirements \(r\in R\). These scenarios are compiled according to the following strategies. Remember that location suitability values obtained from the users are later used in the EC for training the surrogate function \(\widehat{w}_{\Theta}\). Moreover, by enforcing that each user is required to select a best suited service point location in a presented location scenario for an SPR \(r\), a suitability value indicated by the user for some location \(v_{r,S}\) also serves as upper bound on the suitability values of all other locations in the location scenario \(S\); thus, \(w_{r,v_{r,S}}\geq w_{r,v},\ \forall v\in S\). By \(w_{r,v}^{\text{UB}}\), the SMC maintains for each SPR \(r\in R\), and each location \(v\in V\) the so far best obtained upper bound on each \(w_{r,v}\); initially, \(w_{r,v}^{\text{UB}}=1\). Let \(V_{w}(r)=\{v\mid w(r,v)>0\}\) be the initially unknown set of locations that are actually relevant to a user \(u\in U\) w.r.t. an SPR \(r\in R_{u}\). A straightforward strategy to identify this set is to iteratively present the user scenarios \(S_{r}^{\text{V}}=\{v\in V\mid(r,v)\
ot\in K\}\), containing all locations \(v\in V\) for which no entry \((v,r)\in K\) exists yet, i.e., locations for which no suitability values are known yet w.r.t. \(r\). Following this strategy, it can be ensured to identify a new location of \(V_{w}(r)\) in every iteration of COA. Note, however, that it can only be guaranteed that \(V_{w}(r)\) is completely known once the user returns that none of the locations in the last scenario \(S_{r}^{\text{V}}\) are suitable for \(r\). Consequently, \(V_{w}(r)\) will be completely known after \(|V_{w}(r)|+1\) user interactions.