Dependency Problem Google ORTools

Hi everyone,

I am trying to set up a highlevel scheduler using Google OR-Tools ( OR-Tools forJava) to solve the MILP.

Unfortunately I get dependency errors when integrating the code in OpenEMS. In a simple maven project the dependency

  		<dependency>
		    <groupId>com.google.ortools</groupId>
		    <artifactId>ortools-java</artifactId>
		    <version>9.12.4544</version>
		</dependency

works fine and I get no error.

If I paste the same dependency to the pom.xml in OpenEMS and add ortools to the buildpath I first get the error message “NoClassDefFoundError: com/sun/jna/Platform”. After also adding this dependency i get the error

Resource ortools-win32-x86/ was not found in ClassLoader

Did anyone use OR-Tools successfully in OpenEMS? Did anyone have the same problem or any advice how to solve this?

Thanks in advance, any help is appreciated!

Regards
Alex

Hallo Alex,

möglicherweise musst du ähnlich wie für andere Libraries einen Wrapper erstellen.
Ich benötige aber auch selten komplett neue Libraries und bin deshalb auch nicht ganz so fit darin.

VG
Sebastian

Hi Sebastian,

danke fĂĽr den Tipp!
Ich habs mal versucht nachzubauen, aber bin mit meinem Halbwissen leider nicht weiter gekommen. Werde versuchen es mit einer anderen Bibliothek zu machen.

GrĂĽĂźe
Alex

Hallo Alex,

kannst du vielleicht mehr über dein Entwicklungsziel sagen? Ich könnte mir vorstellen, dass für dich die Entwicklungen am “Energy Scheduler v2” nützlich sind, an dem wir intensiv arbeiten.

Letzer Backport dazu: Energy Scheduler v2 / Time-of-Use-Tariff optimization (ALPHA) by sfeilmeier · Pull Request #3029 · OpenEMS/openems · GitHub

GruĂź,
Stefan

Hallo Stefan,

ich würde gerne ein MILP-Problem lösen, welches aus PV-Prognose, TOU-Tariff und angeschlossenen E-Fahrzeugen die optimale Lastverschiebung berechnet. Kann der Solver des Energy Schedulers soetwas auch?

Mein aktueller Workaround ist das MILP in Python über Google OR-Tools lösen zu lassen und die Daten über JSON auszutauschen.

Viele GrĂĽĂźe
Alex

Ja, sowas kann der “Energy Scheduler v2” auch und es wäre toll, hier weitere Mitstreiter zu finden.

Hast du einen konkreten Laboraufbau oder findet das alles nur in Simulationen statt?

Der Ansatz in OpenEMS ist kein MILP, sondern ein Fahrplan fĂĽr vordefinierte Betriebsmodi

  • FĂĽr E-Auto-Beladung z. B. “keine Beladung”, “PV-Ăśberschuss”, “Schnellladung” → (siehe Code)
  • FĂĽr Batteriespeicher z. B. “Eigenverbrauchsoptimierung”, “Verzögerte Entladung”, “Beladung aus dem Netz” → (siehe Code und FEMS Anleitung)

Diese Fahrpläne werden dann jeweils simuiliert und anhand einer Kostenfunktion verglichen. Gleichzeitig wird der Fahrplan dann in Echtzeit ausgeführt und viertelstündlich angepasst.

  • Simulation Speicher → Code
  • Kostenfunktion → Code
  • Anwendung in Echtzeit → Code

GruĂź,
Stefan

FYI, hier ist gerade eine Diskussion, die auch interessant sein könnte:

Hallo Stefan,

vielen Dank fĂĽr die ganzen Infos.

Leider muss ich sagen, dass mit meinem mittelmäßigen Verständnis von Java es extrem schwer ist nachzuvollziehen, wie “io.openems.edge.energy” funktioniert.

Aus dem grundlegenden Problem hätte ich folgende Struktur erwartet:

Input Data:

  • System state (e.g. SoE of ESS)
  • Predictions
  • Costs
  • Configurations
    :down_arrow:
    Model:
  • Constraints
  • Physical relations (energy and SoE dependency, efficiency, …)
    :down_arrow:
    Solver:
  • Result: Optimal scheduling of controllable components
    :down_arrow:
    Interpretation of Scheduling:
  • Realtime control of 15 minutes scheduling result (Use Grid Only, Balance Grid, …)

Was ich gefunden habe:
Model → EnergyFlow (io.openems.edge.energy.api)
Interpretation of Scheduling → StateMachine (io.openems.edge.controller.ess.timeofusetariff)

Wie alles miteinander verschachtelt/verknüpft ist, ist für mich nur sehr schwer zu durchblicken, was für mich ein großer Overhead bedeuten würde, um schlussendlich das Modell umzusetzen, welches ich in OR-Tools schon habe. Dies als kleine Rückmeldung dazu, dass man es vielleicht den “kleinen” Programmierern etwas vereinfachen könnte…

Hierzu eine Verständnisfrage:
Warum wurden die Predictions/TOU tariffs nicht als Komponenten ĂĽber die Config hinzugefĂĽgt, sondern ĂĽber einen PredictionsManger (dessen Implementierung ich nicht gefunden habe)?

Dass es einfach wird hat ja auch niemand behauptet. :wink: Ich bin ziemlich ĂĽberzeugt davon, dass der eingeschlagene Weg der Optimierung sinnvoll ist (das sehe ich nicht zuletzt an meinem privaten System aus PV+Speicher+2xE-Autos+Dynamischer Stromtarif).

Und deshalb versuche ich auch Leute dafür zu gewinnen, gemeinsam daran zu arbeiten - um so das Wissen zu verbreiten und die Funktionen zu Dokumentieren (hier um Forum, später auch in der OpenEMS Doku)

Die Variante ĂĽber ein separates MILP in Python etc. ist wiederum fĂĽr uns schwierig, weil sie kompliziert auf tausende Systeme zu skalieren ist. Sind deine Entwicklungen irgendwo offen verfĂĽgbar?

Und nochmal die Frage: Hast du einen konkreten Laboraufbau oder findet das alles nur in Simulationen statt?

Warum wurden die Predictions/TOU tariffs nicht als Komponenten ĂĽber die Config hinzugefĂĽgt, sondern ĂĽber einen PredictionsManger (dessen Implementierung ich nicht gefunden habe)?

Da jeder Predictor definieren kann, fĂĽr welche Channels er geeignet ist (z. B. nur fĂĽr Verbrauch oder nur fĂĽr Erzeugung), ist das ĂĽber den PredictorManager abstrahiert.

FĂĽr den TimeOfUseTariff gibts das noch nicht, allerdings werden wir das vermutlich auch bald brauchen, da wir fĂĽr manche Situationen den Brutto-Preis (Kostenfunktion) und fĂĽr manche den Netto-Preis (Solarspitzengesetz: keine VergĂĽtung der Einspeisung bei negativen Netto-Preisen) brauchen.

Vielleicht ist es auch sinnvoll, dass wir die Fragen mal in einem Teams-Call klären, oder wir diskutieren die Energy-Scheduler-Architektur einmal in einem OpenEMS Networking Friday.

1 Like

Das wäre super, wenn ich mich da einmal per Teams melden könnte, das Angebot nehme ich gerne an! Mein Code ist gerade noch in Bearbeitung sobald ich hier eine Runde Sache habe, würde ich mich nochmal melden.

Der Workaround über Python ist nicht optimal und sicher keine dauerhafte Lösung. Gerne arbeite ich hier bei einer reinen OpenEMS-Lösung mit!

Angewendet werden soll es sowohl in einer Simulation als auch auf der im Rahmen des Forschungsprojektes SKALE aufgebauten Ladestation mit 12 DC-Ladepunkten, PV-Anlage und Batteriespeicher: