In KWB-R/fakin.doc: Does not matter.

(PART) Old Chapters (German) {-}

Einführung

Hier wollen wir die Ergebnisse unseres Forschungsprojekts FAKIN (Forschungsdatenmanagement an kleinen Instituten) veröffentlichen.

Da wir viele, zum Teil ganz unterschiedliche Projekte bearbeiten, sind auch unterschiedliche Bereiche des Forschungsdatenmanagements betroffen.

Wir wollen hier zunächst versuchen, Fallbeispiele herauszuarbeiten, in die sich die verschiedenen Projekte einordnen lassen. Für jedes Fallbeispiel wollen wir dann Gemeinsamkeiten in Bezug auf Anforderungen und Problemstellungen herausarbeiten und für diese dann existierende Lösungen einsammeln oder gezielt neue Lösungen entwickeln. Diese Lösungen sollen dann in zukünftigen Projekten, die sich den jeweiligen Fallbeispielen zuordnen lassen, angewendet werden.

Dazu brauchen wir Eure Mitarbeit! Wer kann Beiträge zur Beschreibung von Problemfällen und eigenen Lösungen liefern?

Projektbeschreibungen

Projektgruppen

Nach welchen Kriterien können wir unsere Projekte gruppieren, wie können wir sie grob klassifizieren?

Was folgt daraus in Bezug auf das Datenmanagement?

Wenn wir Ähnlichkeiten finden, können wir in Zukunft gezielt auf die Lösungen, die in ähnlichen Projekten erzielt (und beschrieben!) wurden, zurückgreifen.

Mögliche Gruppierung nach:

• Abteilung: Grundwasser, Oberflächengewässer und Kanal, Abwasser
• Finanzierung: Sponsoring, EU-Projekt, BMBF-Projekt, Auftrag
• Anzahl Partnern: große Projekte mit vielen Partnern, kleine Projekte mit wenigen Partnern

Im folgenden fangen wir einfach mal an und versuchen, die Projekte, an denen wir mitgearbeitet haben, kurz zu beschreiben und zu charakterisieren. Wenn wir im Rahmen der Projekte bestimmte Lösungen erarbeitet haben, beschreiben wir diese kurz unter Problembereiche oder Konkrete Aufgaben und Lösungen.

Aufbauend auf dieser ersten Aufstellung von Projekten, Aufgabenbereichen und Lösungen wollen wir dann mit Euch zusammen weitere Projekte in die Betrachtung mit einbeziehen. Wir wollen gemeinsam die Charakterisierung und Gruppierung und natürlich insbesondere die Aufgabenbeschreibungen und Lösungen erweitern und verbessern.

Projektbausteine

Wir können "Projektbausteine" definieren, die in verschiedenen Projekten vorkommen. Diese werden im Folgenden einzeln betrachtet.

Monitoring

In vielen Projekten führen wir eigene Messungen durch. Dazu verwenden wir eigene Messgeräte.

In Monitoringprojekten spielen Metadaten eine besonders wichtige Rolle. Wir betreiben viele Messgeräte mit Akkus. Der Zeitpunkt des Austauschs des Akkus ist eine wichtige Metainformation. Wenn Akkus zu spät gewechselt werden können wichtige Daten verloren gehen bzw. verpasst werden! Auch die Reinigung von Messgeräten ist wichtig, z.B. von Sonden mit optischen Messfenstern. Diese muss einerseits regelmäßig erfolgen. Andererseits ist es wichtig zu wissen, wann Reinigungen erfolgten, damit Messwerte entsprechend interpretiert werden können.

Im Projekt MIA-CSO haben wir erst angefangen, diese Informationen in einer Exceldatei zu erfassen. Angesichts der vielen Messgeräte, Pumpen, Kompressoren und anderer Geräte wurde das aber bald unübersichtlich. Später habe ich eine MS Access Anwendung dafür entwickelt, die seither in einigen Projekten zum Einsatz kam.

Problemstellungen:

• verschiedene Geräte verschiedener Hersteller -> verschiedene, meist nicht standardisierte Dateiformate
• Zeitstempel der Messung
  • Stellt das Gerät auf Sommerzeit um? -> Problembereich Zeitstempel
  • Geht die interne Uhr immer richtig? Wie gewährleiste ich das?

Beispielprojekte: MIACSO, KURAS, Flusshygiene

Grundwassersimulation

Beispielprojekte: OPTIWELLS, DEMOWARE, RWE

Kanalnetzsimulation

Datenaustausch mit BWB

Bei der Kanalnetzsimulation arbeiten wir eng mit den Berliner Wasserbetrieben zusammen. Diese haben und pflegen die Modellnetze.

Eine Schwierigkeit besteht im Austausch von Netzen und in der Versionsverwaltung. In welcher Version wurde ein Netz geschickt?

Gibt es dafür ein halbwegs vernünftiges Vorgehen? Wie ich es sehe, besteht eine große Gefahr, dass beim Hin- und Herschicken von Modellnetzen zwecks Abstimmung versehentlich wieder auf eine ältere Version zurückgegriffen wird und neueste Änderungen auf einer alten Version aufsetzen anstatt auf der aktuellen.

Neben Modellnetzen werden auch andere Bausteien, z.B. Regenreihen oder RTC-Bausteine ausgetauscht.

Fragen:

• Wie wird der Datenaustausch dokumentiert?
• Wie werden die ausgetauschten Objekte versioniert? Das müsste einheitlich auf beiden Seiten des Austauschs geschehen.

Modellkalibrierung

Trockenwetterkalibrierung

Die Kalibrierung der Abflüsse bei Trockenwetter wird anhand einer mittleren Trockenwetterganglinie gemacht. Dafür müssen Trockenwettertage aus den Messdaten ausgewählt werden. Wie wird das gemacht? Ist nachvollziehbar, nach welchen Kriterien die Auswahl erfolgte? Wie wird der Mittelwert über die Ganglinien berechnet? Was geschieht mit Ausreißern, was mit fehlenden Werten? Ist die Auswahl und Berechnung reproduzierbar und lässt sie sich leicht auf neue Daten anwenden? Das wäre eine typische Problemstellung, die sich mit Programmierung lösen lässt. Ggf. gibt es aber auch funktionierende Excellösungen dafür. Wie macht ihr das?

Bei der Modellkalibrierung wird versucht, die Modellparameter, die die Abflussbildung auf der Oberfläche beschreiben, so einzustellen, dass die simulierten Abflüsse und Wasserstände den gemessenen Abflüssen und Wasserständen entspricht. Dazu müssen die gemessenen Regenmengen so aufbereitet werden, dass sie in das Modell importiert werden können. Die erste Aufgabe besteht darin, die vollständige Regenmessreihe in Ereignisse zu zerlegen. Das ist wichtig, da InfoWorks ereignisbezoge z.B. die Evaporation berechnet. Nach der Zerlegung in Ereignisse müssen die Ereignisdaten noch in das richtige Format gebracht werden.

Siehe

• Erzeugen einer Ereignisliste
• InfoWorks: Erzeugen von Regen-Inputdateien

Beispielprojekte: MIACSO, KURAS, Flusshygiene

Problembereiche {#problembereiche}

Datenablage {#datenablage}

Datenimport {#datenimport}

Zeitstempel {#zeitstempel}

Frage:

Wie stellen wir die Messgeräte ein? Sollen sie die Uhr automatisch umstellen oder nicht?

Diskussion:

Aus Sicht der Datenverarbeitung bereitet uns die Umstellung von Winterzeit (= Normalzeit) auf Sommerzeit und von Sommerzeit auf Winterzeit immer wieder Schwierigkeiten. Warum?

Umstellung von Winterzeit auf Sommerzeit

Die Uhr wird um eine Stunde von 02:00 CET (Central European Time) auf 03:00 CEST (Central European Summer Time) vorgestellt. Merke: Die Stühle eines Cafés werden vor den Laden gestellt.

In einer Zeitreihe ergibt sich daraus am Tag der Zeitumstellung (z.B. am 25.03.2018) eine Lücke in den Zeitstempeln:

2018-03-25 01:45:00 CET
2018-03-25 01:50:00 CET
2018-03-25 01:55:00 CET
2018-03-25 03:00:00 CEST
2018-03-25 03:05:00 CEST
2018-03-25 03:10:00 CEST

Wenn die als Text vorliegenden Zeitstempel in einen numerischen Zeitstempel umgewandelt werden, gibt es, auch wenn die Angabe CET oder CEST fehlt, im Grunde kein Problem, da sie eindeutig sind. Voraussetzung ist, dass bei der Umwandlung angegeben wird, dass diese Zeitstempel in der Zeitzone "Europe/Berlin" (in der es Sommer- und Winterzeit gibt) aufgenommen wurden.

In der Programmiersprache R ist das auf unseren Rechnern das Standardverhalten, da die Zeitzone vom Betriebssystem abgefragt wird:

as.POSIXct("2018-03-25 01:55:00")
as.POSIXct("2018-03-25 03:00:00")

Interessant an dieser Stelle ist das Verhalten, wenn ein Zeitstempel, der in der Zeitzone "Europe/Berlin" nicht existiert, angegeben wird:

as.POSIXct("2018-03-25 02:30:00")

Leider tritt an dieser Stelle kein Fehler auf!

Umstellung von Sommerzeit auf Winterzeit

Die Uhr wird um 03:00 CEST wieder um eine Stunde auf die Normalzeit 02:00 CET zurückgestellt. Merke: Die Stühle werden wieder in den Laden zurück gestellt.

In einer Zeitreihe ergeben sich daraus am Tag der Zeitumstellung (z.B. am 28.10.2018) Duplikate in den Zeitstempeln:

2018-10-28 02:15:00 CEST
2018-10-28 02:30:00 CEST
2018-10-28 02:45:00 CEST
2018-10-28 02:00:00 CET
2018-10-28 02:15:00 CET
2018-10-28 02:30:00 CET 

Ohne die Information CEST bzw. CEST sind die Zeitstempel (für sich genommen) nicht eindeutig. In Dateien, die wir von den BWB bekommen (z.B. Regendaten) würden die Zeitstempel zum Beispiel in dieser Form vorkommen:

28.10.2018 02:15:00
28.10.2018 02:30:00
28.10.2018 02:45:00
28.10.2018 02:00:00
28.10.2018 02:15:00
28.10.2018 02:30:00

Erst aus der Reihenfolge (erstes Auftreten ist CEST, zweites Auftreten ist CET) lässt sich die Zuordnung rekonstruieren. Dies müssen wir beachten, wenn wir die Daten bearbeiten und ich denke, dass wir dies in den seltensten Fällen tun!

Wir sollten eine einheitliche, eindeutige Vorgehensweise entwickeln.

TODO: Ggf. weitere Beschreibungen in R-Workshop, den ich mal gegeben habe...

Vorschlag:

• Nach Möglichkeit die Messgeräte so einstellen, dass der ausgegebene Zeitstempel den UTC-Offset enthält. Am besten wäre ein Zeitstempel in einem Format, das die Differenz gegenüber Greenwich Mean Time (GMT) bzw. Coordinated Universal Time (UTC) enthält, wie wir es ggf. aus unseren E-Mail-Programmen oder Terminkalendern kennen: 2018-06-01 23:18 GMT+02:00.
• Manchmal gibt es auch die Möglichkeit, dass zusätzlich zum lokalen Zeitstempel der UTC-Offset (+01 im Winter und +02 im Sommer) als extra Spalte ausgegeben wird. Von dieser Möglichkeit sollte dann Gebrauch gemacht werden.
• Ansonsten empfehlen wir, die Geräte so einzustellen, dass sie die Zeitumstellung nicht mitmachen (also immer die Normalzeit, also Winterzeit, aufzeichnen). Dann sind die Zeitstempel eindeutig. Aufzupassen ist dann allerdings bei der Verarbeitung und Interpretation der Daten, dazu mehr unter Datenimport

Werkzeuge:

• KWB-eigenes R-Paket kwb.datetime. Dieses enthält unter anderem die Funktionen
  • date_range_CEST() zur Ermittlung der Tage, an denen die Zeitumstellung stattfindet.

TODO:

• Wichtigste Funktionen des Pakets kwb.datetime(z.B. zur Ermittlung der vollständigen Zeitstempel inklusive UTC-Offset aus fortlaufenden lokalen Zeitstempeln) dokumentieren und hier referenzieren.
• Sollten wir andere Pakete benutzen und wenn ja, welche? Was bietet z.B. lubridate? Es scheint mir allerdings, dass unsere Problematik im WWW etwas unterbeleuchtet ist.

Allgemeine Methoden

Excel

Programmierung {#programmierung}

Wir verwenden die freie Programmiersprache R. Aller Programmcode soll unter Versionsverwaltung stehen. Das ist angesichts unserer über 1000 Skripte und komplexer Abhängigkeiten zwischen den Paketen und Skripten unabdingbar.

Versionsverwaltung

Subversion

Wir verwenden einen KWB-internen Subversion Versionsverwaltungsserver, mit dem wir über die Software Tortoise SVN, die direkt in den Dateiexplorer integriert ist, kommunizieren.

Im Rahmen von FAKIN legen wir fest, dass alle Programmcodes unter Versionsverwaltung gestellt werden sollen. Das gehört rein ins QMS!

Git

Wir haben auch einen öffentlich zugänglichen GitHub Account:

https://github.com/KWB-R.

Auf diesem legen wir nach und nach R-Pakete ab, deren Veröffentlichung keinen Beschränkungen unterliegt, z.B. weil der Code im Rahmen eines Auftragsprojektes erstellt wurde.

Konkrete Aufgaben und Lösungen {#loesungen}

Monitoring: Erfassen von Metadaten

Zur Protokollierung von Routine- und Wartungsarbeiten an den Geräten in Messkontainern habe ich eine komplexe MS Access Anwendung geschrieben. Mit dieser können Messstellen, Geräte, Aktionen (an Geräten) und Personen (die die Aktionen durchführen) verwaltet sowie Aktionen geplant und dokumentiert werden.

Probleme und Fragen

• Wo liegt sie?
• Wie wird sie bedient? Es gibt keine Beschreibung.
• Die Software wird nicht gepflegt
• Sollten wir sie weiter verwenden? Bestimmt gibt es mittlerweile Apps (womöglich kostenfrei), die auf Tablets laufen, benutzerfreundlich und gut dokumentiert sind.

InfoWorks: Erzeugen von Regen-Inputdateien {#input-infoworks-regen}

Methode: Perl-Skript iw_event_writer.pl

• Wo liegt dieses Skript? Erst lokal bei Hauke, mittlerweile unter Subversion, wurde glaube ich von Mathias in ein R-Skript umgewandelt...
• Wie kann es verwendet werden? Dazu benötigt man Perl, das ist standardmäßig auf keinem Rechner installiert. Auf einem Linux-Rechner wäre das der Fall... Sollten wir einen Linux-Rechner für solche Fälle vorhalten? Nun haben wir ja Rupelton...

InfoWorks: Erzeugen von Real Time Control (RTC)-Dateien {#input-infoworks-rtc}

Ziel: Steuerung der Pumpwerke im Modell, wie sie in der Realität gefördert haben.

Benötigte Daten:

• Regendaten der Berliner Wasserbetriebe

Benötigte Metadaten:

• Worauf bezieht sich der Zeitstempel in einer kontinuierlichen Zeitreihe, auf den Anfang oder das Ende des Zeitintervalls mit der Länge eines Zeitschritts?
• Auf welchen UTC-Offset bezieht sich der Zeitstempel? Meiner Erfahrung nach ist bei den Daten der Berliner Wasserbetriebe immer der Lokalzeitstempel angegeben, in ihren Datenreihen gibt es also an den Tagen der Zeitumstellung Lücken bzw. Duplikate.

Manuelle Methode:

• RTC-Modul in Infoworks-Software erzeugen
• RTC-Modul als Text exportieren
• Pumpwerksdaten nach CSV konvertieren
• Pumpwerksdaten im Texteditor mit Suchen/Ersetzen auf das von InfoWorks geforderte Format bringen
• Formatierte Pumpwerksdaten in der RTC-Textdatei an den richtigen Stellen einfügen

Automatische Methode:

• Perl-Skript rtc_generate.pl. Dieses macht die obigen Schritte automatisch.
• Problem: lässt sich nur auf Rechner mit Perl laufen lassen.

Erzeugen einer Ereignisliste {ereignisliste}

Es können Funktionen aus dem Paket kwb.event verwendet werden.

TODO: Schreiben einer Vignette, die einem einen Leitfaden gibt. Es könnte ein Ausschnitt aus einem existierenden Skript verwendet werden.

Wir brauchen unbedingt Testdaten, die wir verwenden können, um bestimmte Dinge zu veranschaulichen oder als Eingangsdaten für den Test von Funktionen.

Aber wo legen wir die Daten hin und dürfen wir das eigentlich? Oder sollten wir künstliche (generierte) Daten verwenden?

KWB-R/fakin.doc documentation built on Sept. 27, 2019, 9:53 p.m.