Réservoirs et nœuds de stockage
Last updated
Last updated
description: Cette page décrit le comportement et la configuration des nœuds du réservoir Pywr dans WaterStrategy.
Les nœuds de réservoir et de stockage sont soumis à des pénalités d'allocation (coûts). Un coût négatif signifie que le réservoir va accumuler de l'eau, et un coût positif signifie plutôt que le réservoir va libérer de l'eau. Les pénalités d'allocation peuvent être des constantes (paramètres constants) ou des profils (mensuels, quotidiens, hebdomadaires) qui changent en fonction du temps. En outre, les pénalités d'allocation peuvent avoir différents niveaux définis par différentes courbes de contrôle en fonction du volume du réservoir. Malgré les pénalités d'attribution des réservoirs et des réservoirs influant sur le stockage de l'eau, les rejets provenant de ces nœuds résulteront d'un équilibre des coûts du système tenant compte des pénalités d'allocation des nœuds en aval.
Les différents exemples suivants sont présentés.
Pénalité d'allocation constante
Cet exemple utilisera des valeurs constantes comme pénalités d'allocation pour les différents nœuds d'un réseau. La figure 1 montre un réseau simple comprenant des nœuds de captage, de stockage, de demande et de point de vente.
Figure 1. Modèle Pywr simple implémenté dans WaterStrategy
Le nœud de captage comprend une série chronologique des flux entrants, illustrée à la Figure 2. La capacité maximale du storage node est de 2000000 Mm3, et la demande du nœud de demande est de 92 MM3/jour.
Figure 2. Séries chronologiques des flux entrants associées au nœud de captage
Ce réseau simple comporte deux pénalités d'allocation pour les nœuds de stockage et de demande. La pénalité d'allocation pour le storage node est de -5 et le nœud de demande est -10. La figure 3 montre le volume simulé du storage node et le réapprovisionnement du nœud de demande.
![Un graphique avec une ligne
Description générée automatiquement](../.gitbook/assets/3.png)
Figure 3. Volume simulé pour le storage node et alimentation en eau pour le nœud de demande. Pénalité d'allocation de stockage = -5, pénalité d'allocation de demande = -10
La figure 3 montre que la demande 92 mm3/jour est toujours satisfaite pendant la simulation. Cela est dû au fait que la pénalité d'allocation du nœud de demande est supérieure à celle du storage node. De même, si la pénalité d'allocation pour le storage node n'est pas définie, les résultats seront les mêmes que ceux de la Figure 3. Désormais, si les pénalités d'allocation sont inversées, c'est-à-dire que la pénalité d'allocation de stockage est -10 et que la pénalité d'allocation de la demande est de -5, le storage node retiendra l'eau et il n'y aura aucune alimentation pour le nœud de demande (Figure 4).
![Un graphique avec une ligne montante
Description générée automatiquement](../.gitbook/assets/4.png)
![Un graphique avec une ligne
Description générée automatiquement](../.gitbook/assets/5.png)
Figure 4. Volume simulé pour le storage node et alimentation en eau pour le nœud de demande. Pénalité d'allocation de stockage = -10, pénalité d'allocation de demande = -5
Pénalité d'attribution de profil
Cet exemple utilisera un profil mensuel comme pénalité d'allocation pour le storage node (Figure 5) et une pénalité d'allocation constante égale à -10 pour le nœud de demande. Le réseau de la Figure 1 illustrera l'utilisation d'un Pywr MonthlyProfileParameter. Tout autre paramètre Pywr du profil peut être utilisé de la même manière.
Figure 5. Pénalité d'attribution de profil mensuelle.
De mai à septembre, la pénalité d'allocation est inférieure à la pénalité appliquée au nœud de demande, ce qui entraîne des sorties du storage node uniquement au cours de ces mois pour répondre à la demande (voir Figure 6).
![Un graphique avec une ligne montante
Description générée automatiquement](../.gitbook/assets/7.png)
Figure 6. Volume simulé pour le storage node et alimentation en eau pour le nœud de demande à l'aide d'un paramètre de profil mensuel
Nœuds avec des pénalités d'allocation égales
Comme indiqué dans la section 1.1, les pénalités d'allocation sont utilisées pour représenter les priorités d'approvisionnement d'un réseau. En cas de pénurie d'eau et de l'existence de deux ou de plusieurs nœuds ayant la même priorité, il n'est pas possible d'obtenir un approvisionnement proportionnel en utilisant des pénalités d'allocation égales. La figure 7 montre un exemple de pénurie d'eau dans un réseau comportant deux nœuds de demande ayant la même demande et les mêmes priorités.
Figure 7. Modèle Pywr simple implémenté dans WaterStrategy avec des pénalités d'allocation égales
Si nous gérons le réseau de la Figure 7, nous n'obtenons pas une alimentation égale pour les nœuds Demand 1 et 2 (Figure 8) car cela dépendra de la résolution du problème d'allocation d'eau par le solveur. Dans l'exemple de la Figure 7, le solveur alloue plus d'eau au nœud Demand 2, comme le montre la Figure 8.
![Un graphique avec des chiffres et une droite
Description générée automatiquement](../.gitbook/assets/10.png)
Figure 8. Nœuds d'approvisionnement en eau à la demande avec des priorités d'allocation égales.
Bien qu'il ne soit pas possible d'utiliser des pénalités d'allocation égales pour obtenir un approvisionnement égal, dans WaterStrategy, un « AggregatedNode » peut être utilisé pour obtenir le comportement souhaité, à savoir obtenir un approvisionnement proportionnel en cas de pénurie d'eau (voir Figure 9).
Figure 9. Modèle Pywr simple implémenté dans WaterStrategy avec des pénalités d'allocation égales à l'aide d'un « AggragtedNode »
Dans ce cas, dans l'attribut « nodes » du « AggregatedNode », l'utilisateur doit saisir les nœuds avec une pénalité d'allocation égale et dans l'attribut « factors » pour saisir la proportion d'approvisionnement requise entre les nœuds, par exemple, pour une proportion d'approvisionnement égale dans deux nœuds, les facteurs devraient \ [0.5, 0.5], voir Figure 1234567890__5 2.
Tableau 10. Attribut Nœuds et facteurs dans un nœud agrégé.
Notez que le « AggregatedNode » n'est connecté à aucun nœud du réseau (Figure 9). Si nous gérons ce nouveau réseau, nous obtenons une alimentation en eau égale pour les nœuds Demand 1 et 2 (voir Figure 11).
![Un graphique avec des chiffres et une droite
Description générée automatiquement](../.gitbook/assets/14.png)
Tableau 11. Nœuds d'approvisionnement en eau aux nœuds de demande avec des priorités d'allocation égales et un nœud agrégé.
Pywr ne possède aucun nœud explicite pour modéliser une centrale hydroélectrique. Les utilisateurs peuvent également combiner un nœud « Link », un paramètre Pywr et un enregistreur pour modéliser une centrale hydroélectrique. Le paramètre peut être un « HydropowerTargetParameter » et l'enregistreur un « HydropowerRecorder ». Le paramètre cible hydroélectrique est un paramètre utilisé pour calculer le débit requis pour générer un objectif de production hydroélectrique particulier. Il est destiné à être utilisé sur un nœud représentant une turbine pour laquelle un objectif de production particulier est requis à chaque étape. L'enregistreur hydroélectrique calcule et enregistre la production d'énergie à l'aide de l'équation hydroélectrique. Cet enregistreur enregistre une série de données de production hydroélectrique à chaque pas de temps. Pour faciliter l'interaction de l'utilisateur avec Pywr, WaterStrategy inclut un nœud « Turbine », qui affiche une interface (Figure 12) permettant de saisir les informations de la centrale hydroélectrique et crée en interne un « HydropowerTargetParameter » et un « HydropowerRecorder ».
Graphique 12. Interface dans WaterStrategy pour saisir les données techniques des nœuds Turbine.
Les centrales hydroélectriques à réservoir ou au fil de l'eau peuvent être modélisées dans WaterStrategy à l'aide d'un nœud « Turbine ». La seule différence est qu'un storage node doit être défini pour les centrales hydroélectriques à réservoir afin de tenir compte de la variation du niveau du réservoir pour le calcul de la puissance. La hauteur pour le calcul de la puissance est calculée à partir de l'altitude de l'eau donnée dans le « stockage »._node » et « turbine _valeurs « altitude ». Si un storage node avec une élévation de l'eau est donné, alors la hauteur est la différence d'altitude entre l'eau et la turbine. Si le paramètre d'élévation de l'eau est « Aucun », la hauteur est simplement l'altitude de la turbine.