Derrière les coulisses : Comment programmer un script Python pour les prévisions énergétiques avec l'API Météo de Meteomatics

La quantité, la qualité et la disponibilité des données météorologiques de Meteomatics conviennent parfaitement aux clients du secteur de l'énergie, qu'il s'agisse de modéliser la demande des consommateurs ou de prévoir la production d'énergie renouvelable, et bien d'autres choses encore.

Les clients vont de Hive Power, qui apprécie la disponibilité à long terme et la précision de nos données météorologiques pour leur intelligence artificielle de prévision de la production d'énergie à court terme, à Heimdall Power, qui utilise nos solutions sur mesure pour la surveillance des lignes afin d'atteindre leur objectif de numérisation du réseau électrique. Meteomatics fournit à plus de 100 clients (BKW, EDF, ENEL, Axpo, Stadtwerke München, etc.) du secteur de l'énergie des solutions météorologiques très précises et les aide à améliorer leurs opérations quotidiennes chaque jour.

Pour démontrer à quel point il est facile d'utiliser les données Meteomatics pour vos besoins de prévision, je vais montrer dans cet article comment j'ai utilisé le Connecteur Python pour créer un script qui produit un pronostic sur l'énergie pour les prochaines semaines. Nous publions désormais tous les quinze jours un bref rapport sur les résultats de ce script automatisé, que vous trouverez dans la section "Actualités" de notre page d'accueil. Si vous êtes intéressé, vous pouvez également me contacter via [email protected] et je vous enverrai une copie du script, qui fournit un modèle pour l'adaptation d'une prévision simple aux zones, aux périodes et aux variables qui vous intéressent ! Je serais également ravi d'échanger des idées sur les améliorations possibles ou de nouvelles idées.

Qu'est-ce qui influence le marché de l'énergie ?

Parmi les nombreux facteurs qui influencent le coût de l'énergie, les deux plus importants peuvent être qualifiés - de manière assez générale - d'"offre" et de "demande". Les conditions météorologiques ont une influence majeure sur ces deux éléments. Du côté de la demande, le comportement des consommateurs change radicalement en fonction de ce qui se passe à l'extérieur.

S'il pleut à verse, les gens sont plus susceptibles de rester à l'intérieur avec leur télévision allumée et, bien sûr, plus il fait froid, plus il faudra de moyens pour garder tout le monde au chaud dans leurs maisons et leurs bureaux. Du côté de l'offre, comme les sources renouvelables fournissent une part de plus en plus importante de la production mondiale, il est essentiel de prévoir le déficit total qui doit être compensé par les sources répartissables pour que le réseau reste équilibré et que les lumières restent allumées.

En conséquence, deux variables météorologiques sont d'une importance capitale pour les perspectives du commerce de l'énergie à court terme. La première est la température, qui influe sur la demande. En fait, plus que la température absolue elle-même, les négociants en énergie s'intéressent souvent à l'"anomalie" de température, c'est-à-dire à la façon dont la température se compare à la moyenne saisonnière. Les gens s'attendent à ce qu'il fasse froid pendant Noël, mais une vague de froid soudaine peut signifier qu'il fait beaucoup plus froid et entraîne une demande de chauffage beaucoup plus élevée que la moyenne pour cette période de l'année. La demande de chaleur est plus élevée que la moyenne pour cette période de l'année.

La deuxième variable que nous partageons dans notre briefing bihebdomadaire est la vitesse du vent, car c'est le facteur sur lequel dépend la production d'énergie éolienne. Une autre source d'énergie renouvelable est l'énergie solaire, mais nous n'essayons pas de la prévoir pour deux raisons : premièrement, en l'absence de nuages, la production d'énergie solaire dépend presque exclusivement du nombre d'heures de lumière du jour qui, sauf éclipse surprise, est extrêmement prévisible ; deuxièmement, les nuages, en revanche, sont extrêmement difficiles à prévoir, en particulier sur les échelles de temps que nous incluons dans notre rapport.

Nous fournissons des séries chronologiques de ces données pour de grandes régions géographiques, donnant un aperçu des fluctuations auxquelles les négociants en énergie devraient se préparer au cours des prochaines semaines. Il y a un juste milieu à trouver : trop de petites régions rendent les informations présentées difficiles à interpréter, mais une grande moyenne spatiale ne s'applique guère à l'ensemble de l'Europe. Notre solution consiste à fournir des séries chronologiques correspondant aux régions couvertes par plusieurs grands marchés du gaz et à compléter ces informations par une carte animée de la température et de la pression¹, qui donne une impression des changements par rapport aux moyennes représentées dans les séries chronologiques à une échelle plus locale.

Notre script automatisé produit ces résultats pour l'Europe. Si vous êtes intéressé par la manière dont ils se présentent pour votre région, ou si vous souhaitez obtenir des informations plus détaillées, téléchargez une copie² et modifiez la configuration en conséquence.

Étant donné que la sortie du script est une collection de tracés, les tests unitaires sont quelque peu difficiles à mettre en œuvre. Si cela ne fonctionne pas pour votre configuration, veuillez nous contacter à [email protected] et nous verrons ce que nous pouvons faire pour résoudre votre problème et rendre le modèle plus robuste à l'avenir. En attendant, pour vous aider à déboguer et à adapter le modèle, le code est écrit de manière fonctionnelle, avec seulement les étapes principales incluses dans __main__. Voyons ce que sont ces étapes et comment elles ont été réalisées :

Polygones et géométries

L'API de Meteomatics permet aux utilisateurs de récupérer des données de séries temporelles pour des points et pour tous les points d'une grille régulière. C'est fantastique, mais malheureusement la géographie est notre ennemie, et la grande majorité des pays ne sont pas rectangulaires. Nous pouvons contourner ce problème en utilisant la requête polygonale de l'API, qui nous renvoie une série temporelle d'une certaine agrégation (c'est-à-dire la moyenne) de toutes les données à l'intérieur d'une zone non carrée. Pour l'utiliser, nous devons d'abord définir nos polygones.

La documentation de l'API vous dira que, pour définir un polygone, vous devez fournir une liste de toutes les paires de coordonnées qui constituent la frontière (chacune d'entre elles sera reliée par une ligne droite). Cela semble laborieux, mais le connecteur Python vient à notre rescousse ! Dans mon script, je montre deux façons simples d'obtenir des polygones précis.

Les deux méthodes utilisent le package GeoPandas. Si vous ne le connaissez pas, il s'agit d'une extension géographique du paquet incroyablement populaire Pandas, qui facilite la manipulation de données étiquetées³. La principale différence de GeoPandas est l'ajout, à chaque (Geo)DataFrame⁴, d'une colonne "géométrie", sans laquelle le GeoDataFrame n'est pas valide. Vous pouvez transformer n'importe quel DataFrame en GeoDataFrame en ajoutant une colonne géométrie, qui doit être constituée d'objets Shapely. Si tout cela vous semble intimidant, ne vous inquiétez pas, ce n'est pas très important⁵. Nous avons besoin de GeoPandas principalement pour exploiter son jeu de données intégré "naturalearth_lowres" - qui fournit des polygones correspondant à chaque pays du monde - et aussi pour lire d'autres géométries que nous créerons. Il convient toutefois de noter que vous devrez installer GeoPandas pour exécuter mon script, ce qui peut s'avérer un peu compliqué. Je vous recommande de créer un nouvel environnement dans lequel vous exécuterez le script, et d'installer GeoPandas avant tout autre paquet, car il peut arriver que les environnements se cassent si les dépendances sont installées dans un ordre différent.

La première méthode est la plus simple, mais elle présente certaines limites. Dans mon script, vous verrez que l'argument 'standard_countries' est juste une liste de noms de pays. Ces pays peuvent être consultés directement dans naturalearth_lowres, donc si vous n'avez jamais besoin d'utiliser des polygones représentant des nations entières, vous pouvez simplement éditer cette liste et passer à la section suivante !

La seconde méthode est un peu plus ardue, mais elle a l'avantage de vous permettre de définir vos propres géométries, et elle est bien plus simple que de lister à la main les coordonnées de tous les coins de vos polygones. Il utilise la méthode GeoPandas 'read_file', qui est essentiellement la méthode Pandas 'read_csv' adaptée aux données GeoJSON. Au cas où vous n'auriez pas de GeoJSON à portée de main pour votre polygone, laissez-moi vous montrer comment j'ai créé le mien :

Il existe une multitude d'outils pour dessiner des polygones sur des cartes. J'ai utilisé un outil fourni par Keene State College, qui enregistre instantanément les coordonnées des points sur lesquels vous cliquez avec le bouton droit de la souris sur la carte, à la fois dans un format séparé par des virgules et dans un format JSON. Vous pouvez voir un exemple de mon action ci-dessus. Il vous suffit de continuer à cliquer jusqu'à ce que vous soyez satisfait de votre polygone, de cliquer sur "fermer la forme" dans le panneau de droite et de copier-coller les données au format JSON dans un fichier texte.

Avant de l'enregistrer, ajoutez le texte en surbrillance (immédiatement après le premier crochet ouvert) :

Enregistrez maintenant votre fichier en précisant que son format est .geojson. Il se peut que votre ordinateur n'enregistre pas ce format comme un type de fichier reconnu, mais cela n'a pas d'importance - GeoPandas le lira sans problème. A moins que vous ne soyez compétent pour écrire des données supplémentaires dans des fichiers GeoJSON, vous allez devoir nommer vos géométries manuelles dans le code. Je le fais en utilisant le dictionnaire 'manual_geometries'.

La deuxième méthode est utile si vous avez besoin d'examiner une zone plus petite qu'un pays⁶, ou si un pays qui vous intéresse est suffisamment petit pour que naturalearth_lowres ne lui rende pas vraiment justice.

Pour les grands pays, bien que vous puissiez créer des polygones beaucoup plus précis et jolis avec la seconde méthode, j'étais content de la première, car la cartographie d'un littoral peut prendre une éternité. Les deux méthodes sont implémentées dans la fonction get_geometries, qui prend un argument supplémentaire 'show' qui vous permet de visualiser les polygones résultants sur la projection cartographique de votre choix pour vérifier qu'ils ont été lus correctement.

Dans l'image ci-dessous, j'ai également utilisé la fonction de superposition de GeoPandas pour dessiner le chevauchement entre mon polygone du nord de la France dessiné manuellement et le polygone grossier de l'Allemagne obtenu automatiquement à partir du jeu de données intégré.

Données et tracés de séries temporelles

Maintenant que nous disposons de polygones correspondant aux géométries pour lesquelles nous souhaitons obtenir des données météorologiques, la production de séries temporelles est aussi simple que de demander les données à l'API et de tracer le résultat.

Afin de récupérer les données des polygones à partir de l'API, les coordonnées des polygones doivent être formatées d'une manière spécifique : une liste de paires de coordonnées par polygone. Ceci est géré par ma fonction make_tuple_lists. Dans le cas où une région d'intérêt est constituée d'un seul polygone, la fonction insère la liste de coordonnées dans une autre liste car, en général, la liste peut contenir plusieurs polygones - c'est le cas pour l'Italie, qui comprend les îles de Sicile et de Sardaigne. Une requête polygonale ne peut renvoyer qu'une certaine agrégation des données à l'intérieur du polygone sous la forme d'une série temporelle, ce qui signifie que, même pour l'Italie, une seule série temporelle est renvoyée (si vous vouliez éviter cela, vous devriez analyser les îles séparées comme des géométries manuelles distinctes). Vous pouvez remarquer que la demande de polygone est faite séparément de l'appel à la fonction de tracé dans __main__. La raison en est qu'il est souhaitable de prendre en compte les données de tous les polygones afin de définir des maxima et des minima globaux pour les axes des ordonnées sur les tracés afin de faciliter les comparaisons. Les graphiques de séries temporelles résultants pour deux des régions que je considère dans mon script sont présentés ci-dessous.

Les panneaux supérieurs de ces graphiques montrent les prévisions pour les 28 jours à venir au moment de la rédaction, ainsi que le contexte climatologique à la même échelle. Les panneaux inférieurs présentent une autre vue de la même information : en soustrayant l'arrière-plan des deux lignes du panneau supérieur, on obtient la différence entre les données et la moyenne historique. Cette différence est clairement nulle pour l'arrière-plan lui-même, et une ligne pointillée est incluse pour mettre en évidence l'écart entre les prévisions et la climatologie. Les périodes où cette différence est supérieure à zéro peuvent conduire à une demande supérieure à la moyenne, et inversement pour les périodes où la différence est inférieure à zéro.

Un bref commentaire sur la climatologie : différentes disciplines peuvent avoir des normes différentes en ce qui concerne la durée nécessaire pour construire une image moyenne précise. Une moyenne précise devrait idéalement inclure autant de données historiques que possible, mais il y a deux limites à cela : les enregistrements précis des données météorologiques peuvent ne pas remonter au-delà de 1980 pour de nombreuses régions du monde ; et les effets du changement climatique, ainsi que les données socio-économiques que l'on peut vouloir comparer (7), peuvent signifier que des données plus récentes sont plus pertinentes pour les questions posées. La durée standard de la période de référence en climatologie est de 30 ans ; dans le domaine de la prévision de l'énergie, elle est plus souvent de 15 ans (selon nos experts). Le script peut être configuré pour l'une ou l'autre de ces périodes, ou pour toute autre durée. Afin d'économiser le temps d'exécution (qui peut être long si l'on recherche un long historique), la climatologie est calculée selon les besoins et enregistrée dans un fichier, à partir duquel elle peut être lue plus rapidement à l'avenir. Les utilisateurs doivent être conscients qu'une climatologie à jour est importante pour un calcul précis des anomalies, et que la climatologie doit être reconstruite périodiquement - de préférence une fois par an.

Données cartographiques et animation

Ces tracés de séries temporelles sont utiles pour montrer clairement et quantitativement à quel point les facteurs météorologiques importants sont susceptibles de différer de la moyenne à long terme dans nos prévisions, mais ils ont l'inconvénient de réduire de vastes zones géographiques à des points de données uniques pour chaque pas de temps. Afin d'avoir une idée des variations que nous pourrions observer sur nos polygones, ainsi que des systèmes météorologiques responsables des schémas que nous voyons dans les séries temporelles, il est intéressant de visualiser la situation météorologique en images, dont une série peut être animée pour voir l'évolution de la situation dans le temps.

Mon script crée des animations à partir d'images de température - représentées par une échelle de couleurs - et de pression - représentées par des contours (également appelés isobares). Contrairement aux tracés de séries temporelles, il n'est pas facile de modifier ou d'ajouter des variables, car en général, différentes représentations seront optimales pour différentes données (par exemple, le vent peut être mieux représenté par des flèches ou des barres ; montrer les précipitations peut nécessiter que les contours ou l'échelle de couleurs soient remplacés par la quantité de précipitations). Cependant, on peut déduire beaucoup de choses d'une carte de pression à l'échelle synoptique.

Le script crée des animations en récupérant des séries temporelles maillées à partir de l'API de Meteomatics, qui peuvent être converties en un ensemble de données Xarray⁸ pour plus de commodité. En fonction de la projection cartographique choisie, les latitudes et longitudes associées aux données récupérées devront être converties afin que le résultat puisse être tracé sur une carte. Je trace ensuite chaque pas de temps séparément avant d'appeler Pillow pour convertir les images en GIF. Les images individuelles sont toutefois conservées, de sorte que vous pouvez les parcourir à un rythme plus lent si vous le souhaitez.

Améliorations possibles

Notre bulletin bimensuel est un résumé de haut niveau de la situation météorologique en Europe. J'espère que le modèle que j'ai fourni vous sera utile, mais en fonction de vos besoins exacts, il se peut que de nombreux éléments doivent être modifiés. Je terminerai cet article par une brève discussion sur certains des facteurs les plus importants à prendre en considération.

La demande d'énergie est influencée plus ou moins fortement par un grand nombre de facteurs. Même la demande de chauffage, qui est indiquée par la série chronologique des températures que nous produisons, est en réalité beaucoup plus complexe. Notre série chronologique est une moyenne de tous les points à l'intérieur d'un polygone donné, qui peut ne pas être représentatif de la distribution réelle de la population. Par exemple, au Royaume-Uni, environ un dixième de la population vit dans l'agglomération londonienne ; très peu, relativement, vivent dans les Highlands écossais. Par conséquent, une température moyenne pour l'ensemble du pays - qui est probablement considérablement influencée par les régions septentrionales étendues et généralement beaucoup plus fraîches - peut ne pas être en parfaite corrélation avec la température à Londres et dans d'autres centres urbains, d'où peut provenir une grande partie de la demande. Une solution grossière à ce problème consisterait à subdiviser le Royaume-Uni en régions plus petites contenant ces zones urbaines ; une technique plus rigoureuse sur le plan mathématique pourrait consister à obtenir des données spatiales (par exemple à partir d'une demande de séries temporelles en grille) et à les pondérer en fonction de la densité de population.

Outre la répartition inégale de la population, des facteurs tels que la qualité de l'isolation, la richesse locale/la pauvreté en combustible et le jour de la semaine affecteront la réponse de la demande à la température. Il est également vrai que même l'anomalie de température n'est pas nécessairement le meilleur indicateur de la façon dont les gens réagiront à la température. Par exemple, National Grid a conclu que les gens sont plus susceptibles d'augmenter leur chauffage s'il fait beaucoup plus froid aujourd'hui qu'hier, et tente d'en tenir compte dans son calcul de la "température effective".

Le chauffage n'est pas le seul élément à prendre en compte dans la modélisation de la demande. Bien qu'elles soient moins répandues en Europe du Nord, dans de nombreuses régions du monde, les températures chaudes impliquent également une modification significative des besoins énergétiques liés à la climatisation. La température - ainsi que de nombreux autres facteurs météorologiques - peut également affecter de nombreux coûts énergétiques auxiliaires, en fonction des activités professionnelles et de loisirs de la population locale.

Comme pour la température du côté de la demande, la production d'énergie par les sources d'énergie éolienne sera généralement mieux modélisée si l'on tient compte des prévisions pour des régions spécifiques où se trouvent des parcs éoliens. Si vous exploitez un parc éolien, notre code peut facilement être adapté à vos besoins grâce à quelques géométries spécifiques. Vous pourriez également être intéressé par le changement de la variable météorologique utilisée dans la prévision du vent. La variable incluse dans notre rapport est la vitesse du vent à 90 m, car il s'agit de la hauteur moyenne du moyeu d'une éolienne terrestre. Pour les parcs offshore, une hauteur différente peut être préférée. Pour de nombreux paramètres météorologiques standard - dont le vent fait partie - l'API Meteomatics permet aux utilisateurs de récupérer des données à partir d'une gamme continue de hauteurs interpolées, de sorte que vous pouvez obtenir des données précises quelle que soit la hauteur de votre moyeu !

Bien que, d'une manière générale, une vitesse de vent plus élevée implique une puissance de sortie plus élevée des turbines, cette relation n'est pas linéaire. Au lieu de cela, les résultats d'une recherche de vent devront être soumis à une "courbe de puissance" pour obtenir la puissance, essentiellement pour modéliser le fait que des vitesses de vent très faibles ne feront pas tourner une turbine efficacement ; que l'efficacité maximale est atteinte à environ 15ms^-1 ; et que la turbine doit être arrêtée à des vitesses dangereusement élevées, donc ne produisant rien.

En outre, les exploitants de parcs éoliens sont bien conscients que d'autres effets des fluides, tels que les effets de blocage et de sillage, sont importants lorsqu'il s'agit de groupes de turbines situés à proximité les uns des autres. Heureusement, Meteomatics réduit toutes les données API à une résolution horizontale de 60 m, ce qui signifie que nous restons une source de données idéale pour la modélisation à haute résolution de ces effets.

Ces suggestions ne couvrent que les variables que nous incluons dans notre mise à jour. Bien entendu, si vous deviez utiliser ce modèle pour examiner d'autres données - que ce soit pour des prévisions énergétiques ou pour tout autre objectif - un ensemble différent d'hypothèses et de corrections sera nécessaire. Ce qu'il faut retenir, c'est que, quelle que soit votre ambition, Meteomatics fournit les données météorologiques dont vous avez besoin pour en faire une réalité, et que notre équipe est plus qu'heureuse de vous aider à trouver des solutions personnalisées à vos problèmes. Contactez-nous dès aujourd'hui pour découvrir comment vous pouvez commencer à exploiter les capacités de l'API météorologique la plus puissante au monde !