Einfacher PV-Modus

[ttjaden]

Ich habe deine Entwicklung im photovoltaikforum verfolgt. Schön, dass du dich der Sache angenommen hast. Ich hatte beruflich als wissenschaftlicher Mitarbeiter der Hochschule Emden (vorher HTW Berlin) auch schon mit den Daten gearbeitet.

Aktuell muss man ja Modul, Anzahl, Wechselrichter usw. definieren. Der Aufwand ist recht groß und der Mehrwert eher gering bzw etwas für "Nerds". Die Unterschiede moderner Wechselrichter und PV-Module sind sehr gering und auch die Spannungsabhängigkeit der Wechselrichterwirkungsgrade ist geringer geworden.

Vorschlag zur Vereinfachung oder als weitere Option:

• Nutzung der ModelChain aus pvlib
• Nutzung des pvwatts-Modell
• Nutzung des erbs-Modells zur Berechnung von DHI und DNI aus GHI

Vorteile: Man braucht nur noch

• DC-Leistung des PV-Generators in Wp
• Ausrichtung und Neigung

Hier mal eine Notebook-Auszug als Beispiel mit der Validierung Anhand unserer PV-Anlage am Campus (Blau = Simulation und Rot = Messung). Zwischen Simulierten und gemessen AC-Ertrag liegt dabei nur 1,5%. Grundlage der Simulation sind Messdaten unserer Wetterstation.

--> Dokumentation:

Einfachste Simulation mit generischem PV-Modul, Wechselrichter und pvwatts-Modell

import pvlib
import pandas as pd
# import plotly.express as px
from pvlib.location import Location
from pvlib.pvsystem import PVSystem
from pvlib.modelchain import ModelChain
from pvlib.temperature import TEMPERATURE_MODEL_PARAMETERS
import pytz

# Definition: Ort
location = Location(53.37, 7.21, 'Europe/Berlin',2,'Emden')

# Definition: PV-Anlage am Campus Emden mit 40kWp STC Leistung und 40KW Wechselrichter
# gamma_pdc: Temperature coefficient in units of 1/C. Typically -0.002 to -0.005 per degree C.
# --> findet sich auf jedem Datenblatt eines PV-Moduls
module_parameters = dict(pdc0=40000, gamma_pdc=-0.003)
inverter_parameters = dict(pdc0=40000)
temperature_parameters = TEMPERATURE_MODEL_PARAMETERS['sapm']['open_rack_glass_polymer']

system = PVSystem(surface_tilt=30, surface_azimuth=160,
                  module_parameters=module_parameters,
                  inverter_parameters=inverter_parameters,
                  temperature_model_parameters=temperature_parameters)

# Model-Chain erstellen mit Default-Modellen
mc = ModelChain.with_pvwatts(system,location,name='40kWp-Emden')

# Jetzt lade ich das Wetter von der Wetterstation und simuliere damit.
# Strahlung
strahlung = pd.read_csv('input_strahlung.csv', header = 0, index_col = 0, parse_dates = [0])
strahlung.index = strahlung.index.tz_localize('Europe/Berlin', ambiguous='infer')
# Wind
wind = pd.read_csv('input_wind.csv', header = 0, index_col = 0, parse_dates = [0])
wind.index = wind.index.tz_localize('Europe/Berlin', ambiguous='infer')
# Lufttemperatur
luft = pd.read_csv('input_luft.csv', header = 0, index_col = 0, parse_dates = [0])
luft.index = luft.index.tz_localize('Europe/Berlin', ambiguous='infer')

weather = pd.concat([strahlung['Globalstrahlung (CMP3) in W/m²'].clip(lower=0),
                     wind['Windgeschwindigkeit in m/s'],
                     luft['Temperatur in °C']], 
                     axis=1, keys=['ghi', 'wind_speed', 'temp_air'])

# Es fehlen uns noch Diffusstrahlung (dhi) und Direktnormalstrahlung (dni)
# Daher werden diese nun empirisch errechnet.
# siehe https://pvlib-python.readthedocs.io/en/stable/api.html#dni-estimation-models
zenith = location.get_solarposition(times=weather.index, temperature=luft['Temperatur in °C'])
missing_strahlung = pvlib.irradiance.erbs(weather['ghi'], zenith['zenith'], weather.index)
weather['dhi']=missing_strahlung['dhi']
weather['dni']=missing_strahlung['dni']

# Simulation starten
mc.run_model(weather)

ModelChain: 
  name: 40kWp-Emden
  orientation_strategy: None
  clearsky_model: ineichen
  transposition_model: perez
  solar_position_method: nrel_numpy
  airmass_model: kastenyoung1989
  dc_model: pvwatts_dc
  ac_model: pvwatts_inverter
  aoi_model: physical_aoi_loss
  spectral_model: no_spectral_loss
  temperature_model: sapm_temp
  losses_model: pvwatts_losses

# Reale daten der PV-Anlage laden
messung = pd.read_csv('pv.csv', header = 0, index_col = 0, parse_dates = [0])
messung.index = messung.index.tz_localize('Europe/Berlin', ambiguous='infer')

# Simulation auf kW skalieren
simulation = pd.DataFrame.from_dict(mc.ac) / 1000
# DataFrame für den Vergleich
vergleich = pd.concat([pd.DataFrame.from_dict(simulation),
                     messung['Wirkleistung in kW']], 
                     axis=1)

# Vergleich Simulation und Messung
energie=vergleich.sum()
energie[0] / energie['Wirkleistung in kW']
# nur 1,5 Prozenz Abweichung zwischen Simulation und Messung bei sehr einfachem Simulationsansatz

1.0149914547739214

#px.line(vergleich)

# Scatter Wechselrichter Wirkungsgrad
#eta = mc.ac / mc.dc
#px.scatter(x=mc.ac, y=eta)

[ttjaden]

Wer das ganze nachsimulieren möchte, hier noch die die CSV Dateien mit den minütlichen Strahlungsdaten und Messwerten der PV-Anlage aus dem Beispiel oben: https://re-lab.hs-emden-leer.de/s/WfSJe7CAibfp8AW

[kilianknoll]

Zunächst mal vielen Dank für die ausführliche Darstellung und auch den "Soll"-"Ist" Vergleich. Mich würde natürlich auch interessiern, wie genau die DWD Vorhersage sich mit der Realität an diesem Standort deckt. Ich hab jetzt mal den Vorschlag mit der derzeitigen Umsetzung verglichen. Benötigter Input für beide Lösungen:

• Standort
• Ausrichtung
• Neigung
• Wetterdaten

Der einzige Unterschied ist wie Du oben schreibst eine reine Spezifikation des DC Wertes des WR und des gamma_pdc für die Module - ist das so richtig ? Also aktuelle Umsetzung - weiterer Input:

• Wechselrichter
• Module mit Modulanzahl und Strings

Alternativvorschlag - weiterer Input:

• Wechselrichter DC
• Temperaturkoeffizient Module

[ttjaden]

Mich würde natürlich auch interessiern, wie genau die DWD Vorhersage sich mit der Realität an diesem Standort deckt. Du arbeitest ja mit den Mosmix-Prognosen. In jedem Fall sind diese etwas besser als die ebenfalls frei verfügbaren COSMO-D2 Prognosen. Zumindest, was die Vorhersage für den nächsten Tag anbelangt. Hier mal ein Vergleich aus dem April

COSMO-D2 --> COSMO-D2 unterschätzt vor allem sonnige Tage in ihrer Ausprägung

MOSMIX --> eher symmetrische Streuung

Von daher ist Mosmix doch eine gute Datenbasis. Vorteil bei COSMO-D2 wäre, dass man direkt mit Logitude/Latitude arbeiten kann, da das Raster 2x2km über Deutschland beträgt. Nachteil an COSMO-D2: Mehr Daten zum Download, mehr Prozessierungsaufwand --> Entpacken, Grib-Files handhaben, Zeitreihe Zusammensetzen.

Der einzige Unterschied ist wie Du oben schreibst eine reine Spezifikation des DC Wertes des WR und des gamma_pdc für die Module - ist das so richtig ? Ja.

• das gamma_pdc macht man in der ini auf einen üblichen Wert für aktuelle PV-Module. Wird wohl eher selten angepasst werden.
• Die pvlib-Funktion braucht tatsächlich die maximale DC-Leistung des Wechselrichters. Ich würde vorschlagen, dass man in der ini-Datei jedoch die AC-Nennleistung des Wechselrichter angibt, da die Personen die in jedem Fall kennen, und dann in der Berechnung die DC-Nenneleistung mit pvlib ausrechnen lässt.
• Was du bei den weiteren Inputs vergessen hast: Bei deiner Lösung gibt man Anzahl der Module und Strings an und bei meiner Lösung lediglich die Größe des PV-Generators in kWp.

Beste Grüße, Tjarko

[StefaE]

Ich bin mit Kilian: PVWatts hat ein anderes Anwendungsgebiet, nämlich schnell das Potential einer Solaranlage zu ermitteln. Deshalb werden alle möglichen Losses (z. B. 3% fuer Shading, 3% fuer Availability, ...) global eingerechnet.

Fuer Shading steht z.B. im Manual: The default assumption for shading losses represents blocking of the horizon due to faraway features such as large buildings, mountains, or other obstructions. Surveys of installed systems indicated that the average losses due to shading on systems described as "unshaded" was roughly 3 % [14]. Diese 3% sind aber natürlich gleichmässig über den Tag verteilt und würden bei stündlicher Auflösung Fehler ergeben.

Kilian, zu Deiner Frage zum Vergleich: y=Sim (DISC) vs. x=Actual fuer 10. Oct. - 14. Nov., Kleve (am Niederrhein):

Hmm... da bleibt noch was zu tun. Ich vermute, der MOSMIX Parameter RRad1 muss uns helfen ... werd' mal ein paar Versuche starten. (COSMOS-D2 waere natuerlich schoen, aber der Extraktionsaufwand übersteigt meine Lust zu programmieren - man hätte dort DHI und DNI direkt)

Hast Du Vergleiche Sim vs. Actual fuer Deinen Standort?

Stefan

[StefaE]

Hallo Kilian,

... das hat jetzt etwas länger gedauert, als ich eigentlich wollte.

Ursprünglich hatte ich gehofft, dass MOSMIX zwei unabhängige Parameter (Rad1h und RRad1) zur Verfügung stellt, und dass man damit die Prognosen verbessern könnte. Viele Abende später habe ich jetzt gelernt:

1. das scheint so nicht zu stimmen
2. man kann mit Bewölkungsdichte (Parameter N in MOSMIX) eine ähnlich gute Prognose erstellen wie mit Rad1h
3. wirklich spannend scheint mir SolCast

Software dazu habe ich jetzt auch auf Github gestellt und im Solaranzeige Forum angekündigt.

Jetzt warte ich mal ein paar Monate und vergleiche dann die statistische Relevanz der verschiedenen Ansätze für verschiedene Vorhersagezeiträume.

Stefan

[dz9n20]

Hallo @ttjaden!

Ich finde Deinen einfachen Ansatz sehr interessant und denke, dass dieser für meinen Anwendungsfall völlig ausreichend wäre. Leider funktioniert der von Dir angegebene Link nicht mehr. Ich wollte mir die Struktur Deiner CSV-Files etwas genauer anschauen. Du hast die Strahlungsdaten ja von Eurer eigenen Wetterstation. Kann ich verwertbare Daten auch aus DWD-MOSMIX bekommen und damit das Modell füttern? Wäre schön, wenn Du evtl. die Beispiel-CSVs neu posten oder verlinken könntest.

Vielen Dank im Voraus und Grüße aus Bayern

[ttjaden]

Hallo @ttjaden!

Ich finde Deinen einfachen Ansatz sehr interessant und denke, dass dieser für meinen Anwendungsfall völlig ausreichend wäre. Leider funktioniert der von Dir angegebene Link nicht mehr. Ich wollte mir die Struktur Deiner CSV-Files etwas genauer anschauen. Du hast die Strahlungsdaten ja von Eurer eigenen Wetterstation. Kann ich verwertbare Daten auch aus DWD-MOSMIX bekommen und damit das Modell füttern? Wäre schön, wenn Du evtl. die Beispiel-CSVs neu posten oder verlinken könntest.

Vielen Dank im Voraus und Grüße aus Bayern

Link ist korrigiert: https://re-lab.hs-emden-leer.de/s/WfSJe7CAibfp8AW Die DWD-MOSMIS Daten kannst du dir ja ganz normal und frei zugänglich eim DWD runterladen.

P.s. Ich denke aber, dass du auch mal @StefaE Lösung testen kannst mit der Implementierung von Solcast: https://github.com/StefaE/PVForecast

[dz9n20]

Hallo @ttjaden! Ich finde Deinen einfachen Ansatz sehr interessant und denke, dass dieser für meinen Anwendungsfall völlig ausreichend wäre. Leider funktioniert der von Dir angegebene Link nicht mehr. Ich wollte mir die Struktur Deiner CSV-Files etwas genauer anschauen. Du hast die Strahlungsdaten ja von Eurer eigenen Wetterstation. Kann ich verwertbare Daten auch aus DWD-MOSMIX bekommen und damit das Modell füttern? Wäre schön, wenn Du evtl. die Beispiel-CSVs neu posten oder verlinken könntest. Vielen Dank im Voraus und Grüße aus Bayern

Link ist korrigiert: https://re-lab.hs-emden-leer.de/s/WfSJe7CAibfp8AW Die DWD-MOSMIS Daten kannst du dir ja ganz normal und frei zugänglich eim DWD runterladen.

P.s. Ich denke aber, dass du auch mal @StefaE Lösung testen kannst mit der Implementierung von Solcast: https://github.com/StefaE/PVForecast

Hallo @ttjaden!

Vielen Dank für Deine schnelle Antwort und die Korrektur des Links!

Ich schaue mir die Solcast-Lösung von @StefaE definitv auch noch an. Die DWD-Mosmix-Daten habe ich aber trotzdem (allein schon aus Interesse) jetzt auch mal etwas genauer analysiert.

[olikra]

@ttjaden Hallo Tjarko,

habe einmal Deinen vereinfachten Ansatz bei mir umgesetzt. Das hat auf Anhieb gute Werte ergeben. Das hat mich positiv erschrocken. Da ist noch viel Verfeinerung notwendig, aber der erste "Schuss" war schon sehr überzeugend. Magst Du Deinen Code in Deinem github-repo ablegen? Dann kann man direkt auf den Code referenzieren und muss das nicht in einem issue innerhalb eines anderen repos machen. Das wäre klasse. Danke und herzliche Grüsse

[StefaE]

In meiner PVForecast kannst Du sowohl PVWatts als auch die volle Modulierung mit pvlib wählen. MOSMIX wird natürlich unterstützt (ebenso wie andere Forecast Providers)

[olikra]

@StefaE Danke. Werde mir Dein PVForecast auf jedenfall noch genauer anschauen. Ich möchte nur erst pvlib als ganzes besser verstehen wollen. Heute nachmittag ist bei mir die folgende Frage aufgekommen:

In den MOSMIX-Daten werden ja pro Stunde Daten in der Rücksicht ausgegeben und in der Voraussicht: Rad1h beschreibt die Strahlung der vergangenen Stunde. TTT beschreibt die prognostizierte Temperatur in der folgenden Stunde.

Passt pvlib diese beiden Blickwinkel (Vergangenheit/Zukunft) pro Zeitstempel an, oder muss/sollte man z.B. den Rad1h in Pandas entsprechend verschieben?

[olikra]

@StefaE you already figured it out: "MOSMIX Rad1h is (according to DWD customer service) the integrated radiation over the last hour prior to the forecast time stamp. For VisualCrossing, the documentation states that solarradiation is the power at the instantaneous moment of the forecast. Hence, it probably best reflects the average radiation for a period beginning 30min before and ending 30min after the forecast timestamp. To account for this, the forecast time stamp period_end is corrected by +30min (which is then slightly misleading for the secondary weather parameters reported) once it gets written out"