Leibniz Centre for Agricultural Landscape Research Möglichkeiten zur Erweiterung des LandCaRe-DSS...

Leibniz Centre for Agricultural Landscape Research

Möglichkeiten zur Erweiterung des LandCaRe-DSS um Endnutzer-orientierte Modelle

Michael Berg

Kölpinsee, 26.10.2011


Michael Berg, Kölpinsee, 26.10.2011, 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



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 ?



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, 2011-2040

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 ?



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



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)



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)



Modell-Implementation bat.h / bat.cpp (1)



Ausschnitt Datenbankzugriff bat.cpp (2)



Modellmetadaten in .ini-File



Plug-In Interface Implementation bat-dss-plugin.h (1)



Plug-In Interface Implementation bat-dss-plugin.h (2)



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



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



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



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.

Leibniz Centre for Agricultural Landscape Research Möglichkeiten zur Erweiterung des LandCaRe-DSS...

Documents

Transcript of Leibniz Centre for Agricultural Landscape Research Möglichkeiten zur Erweiterung des LandCaRe-DSS...