10_old_german_chapters.Rmd

---
title: "FAKIN Projektdokumentation"
author: "Hauke Sonnenberg & Michael Rustler"
date: "2018-06-08"
site: bookdown::bookdown_site
output: bookdown::gitbook
documentclass: book
bibliography: [book.bib]
biblio-style: apalike
link-citations: yes
github-repo: kwb-r/fakin.doc
url: 'https\://kwb-r.github.io/fakin.doc'
description: "FAKIN Projektdokumentation"
---

# (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](problembereiche) oder 
[Konkrete Aufgaben und Lösungen](loesungen).

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](#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](#miacso) 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](#metadatenbank) 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](#zeitstempel)
    + Geht die interne Uhr immer richtig? Wie gewährleiste ich das?

Beispielprojekte: [MIACSO](#miacso), [KURAS](#kuras), [Flusshygiene](#flusshygiene)


## Grundwassersimulation



Beispielprojekte: [OPTIWELLS](#optiwells), [DEMOWARE](#demoware), [RWE](#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](#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](#ereignisliste)
* [InfoWorks: Erzeugen von Regen-Inputdateien](#input-infoworks-regen)

Beispielprojekte: [MIACSO](#miacso), [KURAS](#kuras), [Flusshygiene](#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:

```{r collapse = TRUE}
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:

```{r collapse = TRUE}
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](#datenimport)

**Werkzeuge:**

* KWB-eigenes R-Paket [`kwb.datetime`](https://kwb-r.github.io/kwb.datetime/dev). 
  Dieses enthält unter anderem die Funktionen
    * [`date_range_CEST()`](https://kwb-r.github.io/kwb.datetime/dev/reference/date_range_CEST.html) 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](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](#metadatenbank) 
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](#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`](https://github.com/kwb-r/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?