Leibniz Centre for Agricultural Landscape Research Möglichkeiten zur Erweiterung des LandCaRe-DSS um Endnutzer- orientierte Modelle Michael Berg Kölpinsee,

Leibniz Centre for Agricultural Landscape Research Michael Berg, Kölpinsee, , Möglichkeiten zur Erweiterung des LandCaRe-DSS um Endnutzer-orientierte Modelle Kurz: Was ist das LandCaRe-DSS (-LSA) ? Was bietet das LandCaRe-DSS ? Zukunft des LandCaRe-DSS als offene Modellplattform Modelle als Plug-Ins / Implementierungsaufwand Zukünftige Funktionalität Ausblick Diskussion: Verbesserungs-/Erweiterungsvorschläge, mögliche andere/neue Modelle etc. Übersicht

Leibniz Centre for Agricultural Landscape Research Michael Berg, Kölpinsee, , Möglichkeiten zur Erweiterung des LandCaRe-DSS um Endnutzer-orientierte Modelle Ein am Institut für Landschaftssystemanalyse (LSA) entwickeltes Entscheidungsunterstützungssystem (DSS) zur Klimafolgenanpassung in der Landwirtschaft Eine offene Modellplattform für endnutzerorientierte Modelle, kein System zur Modellentwicklung für Modelle welche das Prototypstadium verlassen haben bisherige Erkenntnis: Ziel-Nutzer sind im Umgang mit den jeweiligen Modellen und den Modellhintergründen geschult Eine C++/QT Desktop-Applikation für Linux und Windows-Systeme (unter Windows mit Installer) mit Webzugang für Klimadatenzugriffe und Google Maps Fokus derzeit auf ein interaktives, dynamisches System besonders zur Präsentation von Modellen/Ergebnissen mit Raumbezug Was ist das LandCaRe-DSS-LSA ?

Leibniz Centre for Agricultural Landscape Research Michael Berg, Kölpinsee, , Möglichkeiten zur Erweiterung des LandCaRe-DSS um Endnutzer-orientierte Modelle

Leibniz Centre for Agricultural Landscape Research Michael Berg, Kölpinsee, , Möglichkeiten zur Erweiterung des LandCaRe-DSS um Endnutzer-orientierte Modelle

Leibniz Centre for Agricultural Landscape Research Michael Berg, Kölpinsee, , Möglichkeiten zur Erweiterung des LandCaRe-DSS um Endnutzer-orientierte Modelle

Leibniz Centre for Agricultural Landscape Research Michael Berg, Kölpinsee, , Möglichkeiten zur Erweiterung des LandCaRe-DSS um Endnutzer-orientierte Modelle

Leibniz Centre for Agricultural Landscape Research Michael Berg, Kölpinsee, , Möglichkeiten zur Erweiterung des LandCaRe-DSS um Endnutzer-orientierte Modelle Abstrakte Schnittstelle zu verschiedenen Klimadaten (aktuell CLM 20, WETTREG 2006/2010, WEREX, REMO, STAR, STAR2) mit unterschiedlichen Szenarien (A1B, A2, B1) und deren Realisierungen (unabhängige Modellläufe, z.B. WETTREG 2006 = 3, 2010 = 10, STAR2 = 100 etc.) Modell erhält Objekt mit Zeitreihen aller angeforderten Klimaelemente, z.B. tavg, precip, Leicht abstrahierter Zugriff auf MySQL und SQLite Datenbanken Modell spezifiziert abstrakte Datenquelle (z.B. bat) und erhält Datenbankverbindung für SQL-Statements Zugriff auf Kartendaten im ASCII-Grid Format Modell erhält korrekt zugeschnittene Grid-Objekte Modelle spezifizieren benötigte Eingangsdaten (Grids, Schalter, int/double-Wertebereiche, Auswahllisten, [Übergangsweise spezielle Modelle, z.B. cropDistribution = Grid]) werden entsprechend visualisiert und bei Modellläufen automatisch übergeben 2 Kategorien von Ergebnisvisualisierungen, Grid-Ergebnisse als Google-Maps-Overlay, Vielzahl von Punktergebnissen als Ergebnissäulen Was bietet das LandCaRe-DSS ?

Leibniz Centre for Agricultural Landscape Research Michael Berg, Kölpinsee, , Möglichkeiten zur Erweiterung des LandCaRe-DSS um Endnutzer-orientierte Modelle Ca. 4 Jahre Entwicklungsarbeit, besserer Prototyp-Zustand was nun ? Derzeitige Nutzung und Weiterentwicklung im Rahmen von LandCaRe, REKLAM, Carbiocial am LSA Sehr positive Reaktionen und allgemeines Interesse bei Präsentationen suggerieren Öffnung des DSS nach außen Modellplattform Aktuelle DSS-Version ist intern weitgehend modular, erscheint nach außen jedoch monolithisch Modellplattform erfordert komplette Modularisierung mit allen Konsequenzen in naher Zukunft/heute, Modelle und Klimasimulationen als Plug-Ins mittelfristig, Unterstützung im DSS zum Verknüpfen von Modellen & Wegfall von Workarounds (z.B. klimatische Wasserbilanz in Thermischer Vegetationsperiode, Fruchtartverteilungskarte für regionale Modelle, Ökonomische Bewertung von Ertragsmodellen)... Zukunft, Erweiterung des unterstützten Modellspektrums, Einbindung von Legacy-Modellen über Proxy-Plugin-Modelle etc. LandCaRe-DSS-LSA als offene Modellplattform

Leibniz Centre for Agricultural Landscape Research Michael Berg, Kölpinsee, , Möglichkeiten zur Erweiterung des LandCaRe-DSS um Endnutzer-orientierte Modelle Modelle als Plug-Ins = DSS weis nichts von spezifischen Modellen, kennt nur definierte Schnittstellen zu einem Modell Plug-In Modell implementiert eine der bekannten Schnittstellen als Plug-In-Bibliothek übersetzen im DSS Plug-In finden und laden Plug-In Funktionalität wird durch QT bereitgestellt Plug-In Schnittstelle ist ein QT-Objekt Aktuell im Versuchsstadium, in Zukunft mindestens zwei Plug-In Visualisierungs-/Modellkategorien Grid-basierte Modelle mit einem oder mehreren Ergebnis-Grids Säulen-Modelle für Modelle mit einer großen Anzahl von skalaren Ergebnissen Zukünftig entsprechendes Plug-In Management im DSS Aktivieren/Deaktivieren von Modellen im DSS Modelle als Plug-Ins erfordern (wünschenswerte) Mechanismen im DSS zur Modell-Komposition (Modell-Output potentielle Transformation Modell-Input) Modelle als Plug-Ins (1)

Leibniz Centre for Agricultural Landscape Research Michael Berg, Kölpinsee, , Möglichkeiten zur Erweiterung des LandCaRe-DSS um Endnutzer-orientierte Modelle Beispiel BAT-Modell (Biologically Active Time = Wirksame Mineralisierungszeit) Eingangsdaten : Jahrestemperaturmittelwert, Jahresniederschlagssumme, Ton-/Schluff-Gehalt (aus Strukturflächentyp – SFT – der MMK) Ergebnis: Eine Karte mit einem Index zur Wirksamen Mineralisierungszeit = ein Grid Z.B. Implementierungschritte: reines BAT-Modell in C++ aus Turbo-Pascal Vorlage Implementation der Grid-basierten Plug-In Schnittstelle Übersetzen des Plug-Ins/Modelles als Bibliothek (.so /.dll) Kopieren der erstellten Bibliothek/Plug-In in Plug-In-Verzeichnis des DSS Plug-In Implementation (2)

Leibniz Centre for Agricultural Landscape Research Michael Berg, Kölpinsee, , Möglichkeiten zur Erweiterung des LandCaRe-DSS um Endnutzer-orientierte Modelle Modell-Implementation bat.h / bat.cpp (1)

Leibniz Centre for Agricultural Landscape Research Michael Berg, Kölpinsee, , Möglichkeiten zur Erweiterung des LandCaRe-DSS um Endnutzer-orientierte Modelle Ausschnitt Datenbankzugriff bat.cpp (2)

Leibniz Centre for Agricultural Landscape Research Michael Berg, Kölpinsee, , Möglichkeiten zur Erweiterung des LandCaRe-DSS um Endnutzer-orientierte Modelle Modellmetadaten in.ini-File

Leibniz Centre for Agricultural Landscape Research Michael Berg, Kölpinsee, , Möglichkeiten zur Erweiterung des LandCaRe-DSS um Endnutzer-orientierte Modelle Plug-In Interface Implementation bat-dss-plugin.h (1)

Leibniz Centre for Agricultural Landscape Research Michael Berg, Kölpinsee, , Möglichkeiten zur Erweiterung des LandCaRe-DSS um Endnutzer-orientierte Modelle Plug-In Interface Implementation bat-dss-plugin.h (2)

Leibniz Centre for Agricultural Landscape Research Michael Berg, Kölpinsee, , Möglichkeiten zur Erweiterung des LandCaRe-DSS um Endnutzer-orientierte Modelle Essentiell sobald Modelle als Plug-Ins implementiert werden Vereinfacht Modellentwicklung Schnittstellen können einfacher werden, da Spezialfälle wie CropDistribution wegfallen Modelle können einfacher werden, da Modell-Komposition hard-coding ersetzt Nicht-triviales UI-Design: in interaktivem, dynamischen System muss ein einfacher schneller (intuitiver) Weg gefunden werden sinnvollerweise Speichern von Modell-Kompositionen ermöglichen Technische Herausforderungen: Outputs/Inputs müssen zusammenpassen (Typen/Wertebereiche) – relativ einfach falls sie nicht passen, theoretisch beliebige Transformationen (Aggregation) anwenden sinnvolle Use-Cases finden, für einfach verfügbare Standart-Transformationen Zukünftige Funktionalität – Modell-Komposition

Leibniz Centre for Agricultural Landscape Research Michael Berg, Kölpinsee, , Möglichkeiten zur Erweiterung des LandCaRe-DSS um Endnutzer-orientierte Modelle Nicht immer ist eine Reimplantation von Modellen in C++ möglich oder gewünscht Plug-Ins zur Einbindung von vorhandenen Modellen auf unterschiedliche Arten wünschenswert z.B. einfache Plug-Ins denkbar, welche Unterstützung für klassische Input-File(s) Modelllauf Output-File(s) bieten Allgemeines Problem: weniger Kontrolle über die Modelle und deren Laufzeiten aber inhärent im DSS als Framework Gedanke Notwendigkeit kann in laufenden Projekten auftreten Verfügbarkeit / Machbarkeitsstudie womöglich schneller als gedacht Interessant Netzwerk-Proxy-Modelle um Rechen-Cluster oder als Cloud-Services nutzen zu können Zukünftige Funktionalität – Proxy-Plug-In Modelle zur Anbindung von Legacy-/!C++-Modellen

Leibniz Centre for Agricultural Landscape Research Michael Berg, Kölpinsee, , Möglichkeiten zur Erweiterung des LandCaRe-DSS um Endnutzer-orientierte Modelle LandCaRe-DSS-LSA kann hier und jetzt genutzt werden ! ABER: Plug-In Schnittstelle(n) noch nicht vollständig fertig bis dahin kann nicht von Framework gesprochen werden wenn alle bisherigen Modelle zu Plug-Ins transformiert sind, steht ausreichende Beispielsbasis auch komplexer Modelle zur Verfügung Bugs im DSS und bestehende Design-Probleme können nur nach und nach beseitigt werden, z.B. alle langlaufenden Aktionen (z.B. Datenbankabfragen) sollten asynchron erfolgen und den UI- Thread nicht blockieren der DSS Start kann lange Dauern infolge Interaktionsproblemen DSS/GoogleMaps-Javascript Datenbank-Schnittstelle sollte um Connection-Pooling/-Management erweitert werden, z.B. um Verbindungsabbrüche zur Datenbank zu handhaben Grid-Management verdient eine Überarbeitung Ausblick

Leibniz Centre for Agricultural Landscape Research Michael Berg, Kölpinsee, , Möglichkeiten zur Erweiterung des LandCaRe-DSS um Endnutzer-orientierte Modelle Kann sich jemand vorstellen, inspiriert von den vorhandenen / zukünftigen Fähigkeiten des DSS, ein/sein Modell im DSS sehen zu wollen ? Welche Fähigkeiten / Datengrundlagen etc. fehlen für Ihr Modell ? In welche Richtung könnte / sollte sich das DSS entwickeln ? Unter welchen Bedingungen wäre das DSS eine Option als Laufzeitumgebung für Ihr(e) Modelle ? Diskussion: Verbesserungs-/Erweiterungsvorschläge, mögliche andere/neue Modelle etc.