76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Auch dass unterschiedliche Einheiten / Korrekturen zusammen verwendet werden.

Kannst du erläutern wo? Ich achte genau darauf dass Einheiten innerhalb einer Formel passen.
Kann natürlich auch mal übersehen werden.

Wie gesagt, die Matrix kann ich weiter untersetzen.

Übrigens wird die Matrix ausschließlich beim Model DWD benutzt, alle anderen API verwenden die genaue Azimutangabe in Grad aus setupStringAzimuth sofern man die Azimutangabe und nicht die Kennung (N, NE,...) angibt. Nur als Hinweis. 

[andi11]

Kannst du erläutern wo? Ich achte genau darauf dass Einheiten innerhalb einer Formel passen.

Ich meinte diesen Hinweis:

Schließlich muss man an der Sache noch eine generelle Kritik anbringen. Denn diese Flächenfaktoren beziehen sich auf den _Jahresertrag_. Es ist also einfach sachlich falsch, den prognostizierten Ertrag an einem bestimmten Tag, mehr noch zu einer bestimmten Stunde, mit Hilfe dieses Flächenfaktors zu bestimmen. Richtiger wäre, Azimut und Elevation der Sonne (z.B. aus dem Astro-Modul) mit horizontaler Ausrichtung und Neigung der PV-Anlage zu verrechnen, das sind tatsächlich nur ein paar Winkelfunktionen.

[DS_Starter]

Achso, ok.
Also ich bin durchaus geneigt und interessiert das Model DWD auf den Ansatz von pah mit dem Snippet sub PVExpectedYield umzustellen. Die Angaben von SunAlt und SunAz hatte ich ja bereits vor einiger Zeit aus Astro ins Modul geholt. Alle andere APIs arbeiten nicht mit der Matrix.

Als Beobachtung kann ich allerdings sagen, dass ich das Model DWD auch neben meinem prod. Model SolCastAPI mitlaufen lasse, welches mit den genauen Grad-Angaben eingerichtet wird.
Wenn ich z.B. die Ergebnisse von gestern vergleiche, was wirklich kein guter Tag war, lag die Solcast-Abweichung bei 6,7% und DWD bei 7,3%.
Also so verkehrt kann die Vorgehensweise m.M. nach nicht sein. Ich kann mir allerdings auch vorstellen, dass sich vor allem bei Direkteinstrahlung Unterschiede bemerkbar machen und nicht so sehr bei diffuser Bestrahlung was wiederum durch die permanente Fortschreibung von Korrekturfaktoren (auch zur Einbeziehung spezifischer Anlagenkennwerte) ausgeglichen wird. Zumindest nach einer gewissen Laufzeit.

[stefanru]

Hallo zusammen,

habe gerade von DWD Ensembel wieder auf DWD API umgestellt.
Hatte gestern -5,2% und heute +1,5%.
Ich bin total begeistert von DWD API so wie sie ist.
Für mich viel besser als die anderen.
Habe anscheinend Glück, habe 2 Stationen im Umkreis von 3-4km und die scheinen gut zu meinem Setup zu passen
Lernzeit hatte die Anlage noch nicht.

Natürlich bin ich auch, wenn möglich, für die genaueste Berechnungsmethode, was sicherlich die Formel ist.
Aber in der Informatik muss man auch immer die 80/20-Regel beachten.
Wenn man noch 80% Aufwand reinstecken muss, nur um die letzten 20% rauszuquetschen, dann macht es vom Aufwand her vielleicht keinen Sinn mehr, zum Glück ist das hier alles ein Hobby .

Und für mich persönlich ist es bei der DWD Vorhersage so, dass sie einwandfrei funktioniert und es eigentlich nur schlechter werden kann
Muss aber nicht für jeden so sein.

Viele Grüße,
Stefan

[Prof. Dr. Peter Henning]

Zumindest nach einer gewissen Laufzeit.

Das habe ich ja schon geschrieben.

Der Knackpunkt ist aber, dass man mit einem falschen Ansatz beliebig viele Ergebnisse produzieren kann, die "ungefähr richtig" sind. Und das trifft eben in diesem Falle zu: Eine Vorhersage der (richtungsunabhängigen, momentanen) Globalstrahlung mit einem (richtungsabhängigen, aus Jahr bezogenen) Faktor zu multiplizieren, ist schon etwas willkürlich. Das ist ungefähr so, als ob ich aus der Länge und Breite eines Schiffes auf das Alter des Kapitäns schließen wollte - eben schon irgendwie korreliert, weil man eine gewisse Erfahrung braucht, um einen dicken Pott zu steuern.

@pah, Frage ... Was steckt in $pi180 = 0.0174532918889 ?

Pi/180

Und was zeigst du uns damit? Dass du in ziemlich genau 12 Minuten dass erzeugen kannst, was deiner Meinung nach besser durch eine Formel abgebildet werden kann?

Bitte genauer lesen, was ich geschrieben habe: Es ist keine Kunst, die Tabelle mit weiteren Zwischenwerten anzureichern, wenn man das in Mathematica hat (schon gar nicht benötigt man dafür Winterabende). Das ist aber eben nicht das Ziel, sondern das Ziel ist, die Sache zu vereinfachen. Daran arbeite ich gerade, dann wird es einen Wiki-Artikel dazu geben.

LG

pah

[kask]

Ja, eine Formel wäre immer schicker als statische Tabellen. Der Sinn erschliesst sich mir aber nicht unbedingt, ausser es vieleicht/eventuell/mutmasslich genauer zu machen in der Theorie.
Vieleicht habe ich da aber auch etwas nicht verstanden.
Mit der Genauigkeit ist es dann schon dahin wenn der erlernte Korrekturfaktor mit in die Auswertung eingeht.

Klar wäre es schöner alle Werte so genau wie möglich zu haben um etwas zu prognostizieren.
Allerdings sind hier, in dem Fall, mehrere und größere Ungenauigkeiten als die Winkelangabe bzw. dessen Ausgabe der Strahlungswerte.
Der Korrekturfaktor sollte diese Ungenauigkeit schon weiter ausgleichen. Da der Winkelfehler ja immer gleich bleibt.
Das läst die Genauigkeit der Anzeige bzw. dessen Ausgabewert verfälschen. Aber die Tendenz bleibt die gleiche.
Das ein Physiker/Mathematiker die genauen Werte anstrebt ist verständlich (Wäre auch schlimm wenn nicht).
Der kleine Bürger will eher Werte die plausibel erscheinen und reproduzierbar sind.
Ihm ist da die absolute Genauigkeit zweitranging.
DEm Proletariat ist es zudem egal ob das mit einem geeichten Messgerät erfolgt oder nicht.

Die Verschattung kommt auch mit da rein. Zudem ist die Vorhersage der API's genauso ungenau Teilweise und Fehlrbehaftet.
Ich glaube da fällt der Winkelfehler dann am Ende nicht so ins Gewicht. Weil, wie schon erwähnt, dieser immer gleich "falsch" ist.

Aber @pah du hast da schon Recht das genauer zumachen macht sicher ein bischen Sinn.
Dadurch würde der Korrekturfaktor ja gezwungenermassen genauer werden, und dieser verfälscht ja auch mit. Nur dann etwas weniger eventuell.
Alles nicht ganz so einfach.

[kask]

@pah, Frage ... Was steckt in $pi180 = 0.0174532918889 ?

Pi/180

Ich glaube die Frage war eher "warum" und nicht "was" das ist.

Um in Bogenmass weiter zu rechnen (2pi = 360°).

https://de.wikipedia.org/wiki/Radiant_(Einheit)

[Prof. Dr. Peter Henning]

So, voila.

Mit der nachstehenden Funktion lässt sich der Flächenfaktor im gesamten Winkelbereich der Tabelle sehr genau reproduzieren.

Code Auswählen Erweitern

###############################################################################
#
#  Flächenfaktor Photovoltaik
# 
#  Prof. Dr. Peter A. Henning, September 2024
#
###############################################################################

sub PV_hff($$){

  my ($neigung,$ausrichtung) = @_;
  my $pi180  = 0.0174532918889;
 
  return undef
    if( $neigung<0.0 || $neigung>90.0 || $ausrichtung<0.0 || $ausrichtung>360. );
   
  my $x=$neigung*sin($ausrichtung*$pi180);
  my $y=$neigung*cos($ausrichtung*$pi180);
 
  my $x2 = $x**2;
  my $x4 = $x2**2;
 
  my $res = 3.808301895960147E-7 - 8.650170178954599E-11 * $x2 + 5.50016483344622E-15 * $x4;
  $res = $res*$y + 0.00007319316326291892 - 3.604294916743569E-9 * $x2 - 2.343747951073022E-13 * $x4;
  $res = $res*$y - 0.00785953342909065 + 1.1197340251684106E-6 * $x2 - 8.99915952119488E-11 * $x4;
  $res = $res*$y - 0.8432627150525525 + 0.00010392051567819936 * $x2 - 3.979206287671085E-9 * $x4;
  $res = $res*$y +  99.49627151067648 - 0.006340200119196879 * $x2 + 2.052575360270524E-7 * $x4;
 
  return  $res
}
Die Abweichung von den Werten in der Tabelle liegt fast überall unter 2%, und diese werden nur an wenigen Stellen erreicht. Näheres dazu auch in diesem Wiki-Artikel: https://wiki.fhem.de/wiki/Ertragsprognose_PV

LG

pah

Im Bild links die interpolierte Tabelle (ohne Glättung), rechts die mit der o.a. Funktion berechnete Näherung. Darunter der Absolutbetrag der Abweichung der Näherung von der Tabelle (in Prozent).
Du darfst diesen Dateianhang nicht ansehen.Du darfst diesen Dateianhang nicht ansehen.
Du darfst diesen Dateianhang nicht ansehen.

[DS_Starter]

Hallo pah,

danke für die Zuarbeit. 

Die Tabelle im Modul würde ich mit deiner Funktion substituieren.
Wie ich sehe, läuft hier das Azimut/Modulausrichtung von 0-360°, richtig? Denn im Setup lassen sich 180 ...0 ...-180 angeben, was ich intern entsprechend umrechnen würde.

Für einen Lerneffekt wäre es allerdings nicht verkehrt die Schritte zur Herleitung der Funktion zu verstehen.

LG
 

[Prof. Dr. Peter Henning]

Na ja, die Himmelsrichtung wird nicht von -180° bis 180° angegeben, sondern von 0 - 360°.

Und "Herleitung" ist gut:

1. Umschreiben der Tabelle auf die Variablen x=Neigung*Sin(Ausrichtung) und y=Neigung*Cos(Ausrichtung)
2. Cleverer Ansatz, nämlich das Tensorprodukt der Funktionen (1,x²,x⁴) mit (1,y,y²,y³,y⁴). Für x braucht man wegen der Symmetrie nur gerade Potenzen.
3. Ausgleichsrechnung, welche die 15 Koeffizienten des Tensorproduktes so wählt, dass die Summe der quadratischen Abweichungen zur Tabelle minimal wird.

Letzteres natürlich nicht manuell, sondern mit Mathematica https://www.wolfram.com/mathematica/. Nutze ich seit 1988 für meine physikalischen Forschungen.

LG

pah

[DS_Starter]

Mathematica hatte ich mir schon im Web angeschaut. Ist leider für Privatnutzer nicht kostenlos. Für euch im HS bzw. Forschungsbereich vermutlich schon.

[Prof. Dr. Peter Henning]

Für euch im HS bzw. Forschungsbereich vermutlich schon.

Nö, kostenlos ist gar nichts. Das bezahle ich aus meinen Forschungsmitteln, die ich mir mühsam verdiene... Oder verdient habe.

Tipp für Hobbyanwender: Es gibt eine sehr schöne App für Wolfram Alpha, mit der man die wichtigsten Features von Mathematica nutzen kann.

LG

pah

[DS_Starter]

@all,
morgen früh ist eine neue Version im Update.
Die interne Lookup-Tabelle ist durch die Flächenfaktor-Formel von pah ersetzt.
Für den Anwender ergeben sich dadurch keinerlei ToDos.
Wer es noch nicht getan hat, kann im Setter setupStringAzimuth seine Anlagenausrichtung auf ganzzahlige Zwischenwerte von -180 bis 180 einstellen statt N, NE etc.
Einen evtl. Impact gibt es nur beim Model DWD.

LG,
Heiko

[stefanru]

Ok, vielen Dank.
Ich werde testen.
Habe ja DWD im Idealfall merke ich nichts oder die Vorhersage wird noch besser
Auch heute bei katastrophalen Bedingungen nur 8,3% Abweichung.

Gruß,
Stefan

[DS_Starter]

Moin,
habe gerade festgestellt, dass die Änderung negative Auswirkungen auf die OpenMeteo Modelle hat.
Das ist aber mein Fehler weil ich eine interne Abhängigkeit nicht bedacht hatte.
Ich fixe es und gebe kurzfristig Bescheid.

LG