Résolution

Pour résoudre plus efficacement le modèle, une transformation est faite sur la contrainte non-linéaire. Celle-ci est transformée en problème de Programmation sur le Cône du Second Ordre (PCSO). La contrainte non linéaire de ce type de problème doit s’écrire selon l’équation 3.85.

X

i∈I

x2_i ≤ y2 _(3.85)

avec y ≥ 0.

Les contraintes (3.36), (3.37) et (3.38) du problème (P1) sont transformés sous la forme de l’équation 3.85. µ =X i∈I p+_i ∆Pi (3.86) y = µ − Pu Z2 α (3.87) xi = ki∆Pi ∀i ∈ I (3.88) y2 ≥X i∈I x2_i (3.89) y ≥ 0 (3.90)

La variable y ∈ IR+ _{est ajoutée au modèle ainsi que la variable x ∈ IR}1xn_{. Le paramètre k est}

un coefficient issu du calcul de la variance de la réponse et est donc différent selon le degré de regroupement a et b.

ki = q pi(1 − pi) a ∀i ∈ BH ∪ SH (3.91) ki = q pi(1 − pi) b ∀i ∈ COM (3.92)

Les contraintes (3.42), (3.44) et (3.44) du problème (P2) sont transformées également pour obtenir la même forme.

µ =X i∈I p−_i ∆Pi (3.93) y = Pu − µ Z2 α (3.94) xi = ki∆Pi ∀i ∈ I (3.95) y2 ≥X i∈I x2_i (3.96) y ≥ 0 (3.97)

Avec cette nouvelle formulation, n’importe quel solveur traitant les problèmes PCSO peut être utilisé. Ici, le solver Gurobi a été utilisé pour faire la résolution du problème.

3.5.1 Résultats

Trois études de cas ont été testées à la sous-station Buckingham avec les requêtes d’utilités calculées avec β = 0, 10. La sous-station Bukingham a été choisie, car elle a les plus grandes requêtes d’utilités. La valeur de la requête d’utilité de chaque période est montrée à la figure 3.8. Le niveau de confiance α est constant pour les trois études de cas et est égal à 0,95. Un ensemble initial de 30 000 clients a été regroupé avec un niveau de regroupement a = 100 et b = 10 ce qui réduit à 975 le nombre de regroupements. Le cas de base est utilisé à titre de référence pour étudier l’impact des changements sur la solution optimale. Les paramètres des trois études de cas sont présentés dans le tableau 3.5.

Étude de cas de base

Le figure 3.8 montre que seuls les clients ayant une faible probabilité sont sollicités dans le cas de base. L’agrégateur préfère envoyer plus de requêtes à moindre coût pour satisfaire

Tableau 3.5 Paramètre des études de cas

Cas ci ($/kW) nimax Sous-Ensemble

LOW M OD HIGH CAT1 CAT2

Cas de base 1 2 3 21 7 BH, SH, COM

Cas 1 1 1.5 1.75 21 7 BH, SH, COM

Cas 2 1 2 3 1 1 BH, SH, COM

Cas 3 1 2 3 21 7 SH, COM

Tableau 3.6 Resultats des études de cas

Cas Temps de résolution (s) Coût total ($)

Cas de base 2 501 768

Cas 1 1 500 458

Cas 2 2 732 523

Cas 3 12 502 491

la requête d’utilité plutôt que d’envoyer moins de requêtes à plus grand coût. La figure 3.9 montre le coût par kW de réduction ou d’augmentation ($/kW) à travers la semaine. Ce coût représente le coût des requêtes de DR pour une période divisée par la requête d’utilité de cette même période. Ainsi, le coût par kW de réduction ou d’augmentation peut être comparé d’une période à l’autre et d’une étude de cas à l’autre. La figure 3.9 montre que pour le cas de base, ce coût varie entre 1.73 $/kW et 1.81 $/kW. Comme le coût des requêtes des clients des sous-ensembles M OD et HIGH est respectivement 2 $/kW et 3 $/kW, l’agrégateur n’a aucun intérêt à solliciter ces clients.

Étude de cas 1

Cependant, l’agrégateur vise une participation des clients avec une probabilité approchant 1. Un agrégateur a donc de l’intérêt à vouloir prioriser les clients ayant une grande probabilité. Pour ce faire, la détermination des coûts des requêtes doit être faite de façon stratégique. L’étude de cas 1 analyse l’impact des coûts des requêtes sur les sous-ensembles de probabilité sollicités. Le tableau 3.5 montre les coûts de chaque sous-ensemble. Dans la figure 3.8, on voit que le sous-ensemble HIGH est maintenant sollicité avec les nouveaux coûts. Le tableau 3.9 montre que le coût par kW de réduction ou d’augmentation ($/kW) n’a sensiblement pas changé. Les coûts totaux pour le cas de base sont de 501 768 $ et de l’étude de cas 1 est de 500 458 $ ce qui représente 0,26 % de réduction. Bien que les coûts totaux n’ont presque pas changé, l’agrégateur a de l’intérêt à vouloir prioriser les clients ayant une grande probabilité.

(a)

(b)

(c)

Figure 3.8 Répartition des requêtes de DR envoyées à chaque sous-ensemble de probabilité et de secteur pour (a) le cas de case , (b) l’étude de cas 1 et (c) l’étude de cas 2.

Étude de cas 2

L’étude de cas 2 montre les limites du modèle. Le modèle a été testé avec un maximum d’une requête par semaine pour chaque client. La figure 3.9 montre que le coût par kW de réduction ou augmentation varie pendant la semaine. À la fin de la semaine, ce coût est à 3,10 $/kW tandis qu’au début il est à 1,73 $/kW. Cette forte augmentation s’explique avec

Figure 3.9 Coût par kW de réduction ou d’augmentation de chaque période de la semaine ($/kW)

la figure 3.8. Au début de la semaine, l’agrégateur sollicite seulement les clients du sous- ensemble LOW jusqu’à ce qu’aucun client ne soit disponible. L’agrégateur passe ensuite aux clients du sous-ensemble M OD puis aux clients du sous-ensemble HIGH. L’agrégateur n’anticipe pas les décisions prises en début en fonction des conditions de la fin de la semaine, ce qui peut engendrer de grands coûts. Par exemple, une grande requête d’utilité en fin de semaine coûtera presque 2 fois plus qu’une grande requête d’utilité en début de semaine. Une façon de pallier ce problème est de rendre le modèle dynamique. Ainsi, l’agrégateur peut minimiser les coûts totaux de la semaine. Par contre, pour ce faire la méthode de prévision de la consommation doit s’adapter. En effet, un modèle dynamique résout le problème pour une semaine complète. La prévision de la consommation doit donc se faire pour toute la semaine, et ce en début de semaine.

Étude de cas 3

Finalement, un agrégateur peut vouloir analyser l’impact de la participation de certains secteurs aux programmes de DR. Étant donné que les programmes de DR nécessitent une installation d’équipement de communication, des coûts initiaux sont associés à l’implantation

(a) (b)

Figure 3.10 Répartition des requêtes de DR envoyées à chaque sous-ensemble de secteur pour (a) l’étude de cas 1 et (b) l’étude de cas 3.

de ces programmes. Pour être profitable, ces coûts d’installation doivent être faibles par rapport aux profits anticipés par les programmes. La participation des clients ayant une maison de base est analysée pour voir si l’agrégateur tire un profit de leur participation. Une troisième étude de cas est créée pour analyser cet impact. Les paramètres sont les mêmes que le cas de base, mais le sous-ensemble BH est retiré de l’ensemble des clients. La figure 3.8 montre que les secteurs commercial et résidentiel avec maison intelligente ont compensé le sous-ensemble BH. Les coûts totaux du cas de base passent de 501 768 $ à 502 491 $ à l’étude de cas 3. Ceci correspond à une augmentation de 0,41 % ce qui n’est pas significatif. Dans ces conditions, un agrégateur pourrait décider de ne pas installer l’équipement chez les clients ayant une maison de base.