# Projekttagebuch Smart-HEC
## Probleme OCR-D / AVV
### Cropping
### Deskewing
### Dewarping/De-Keystone
1. Mit https://github.com/mzucker/page_dewarp … (mußte ich erst von Python 2 portieren und ein paar cv2/numpy-Aktualisierungen; außerdem täte vernünftige Paketierung not)
(Also schon mal nicht schlecht; läßt sich aber noch optimieren.)
1. Fred's [unperspective](http://www.fmwconcepts.com/imagemagick/unperspective/index.php) braucht hingegen einen deutlichen Grauwert-Unterschied für den Hintergrund, was hier nicht der Fall ist:
(hier der gescheiterte Versuch, mit Floodfilling die Maske zu finden – eigentlich sollte nur das A4-Blatt weiß sein)
(dies der noch schlimmer gescheiterte Versuch, es mit einer Binarisierung zu machen – Hintergrund innen und außen sind sich einfach zu ähnlich).
Jedenfalls bricht das Tool dann schon ab, weil es keine einheitliche, geschlossene Maskenfläche findet
1. das DFKI-Dewarping ist so dermaßen unterirdisch gemacht, daß man es gar nicht erst probieren kann: [OCR-D/ocrd_anybaseocr#40](https://github.com/OCR-D/ocrd_anybaseocr/issues/40) [OCR-D/ocrd_anybaseocr#61](https://github.com/OCR-D/ocrd_anybaseocr/issues/61)
### Binarisierung
### Tesseract-Sparsemode
### Export für LAREX
### Re-Import für Extraktion
(Rohdaten vs binarisiert, Original vs Cropped/Deskewed)
### Extraktion und Formatkonvertierung (COCO)
### Laufzeit-Komponente für Inferenz
## Probleme LAREX und postdemokratie
### Bookpath und Verzeichnisstruktur-Annahmen
https://github.com/OCR4all/LAREX/issues/160
https://github.com/OCR4all/LAREX/issues/161
https://github.com/OCR4all/LAREX/issues/162
### PAGE-Import
https://github.com/OCR4all/LAREX/issues/172
https://github.com/OCR4all/LAREX/issues/173
https://github.com/OCR4all/LAREX/issues/174
https://github.com/OCR4all/LAREX/issues/176
https://github.com/OCR4all/LAREX/pull/179
https://github.com/OCR4all/LAREX/issues/181
### Build und Konfiguration / Modus
https://github.com/OCR4all/LAREX/issues/180
https://github.com/OCR4all/LAREX/issues/182
### Handling / Bugs
### Dokumentation
### Deployment
## Probleme Mask-RCNN
### EOL / Support
- https://github.com/matterport/Mask_RCNN/issues/936 (PRs/Issues laufen weiter an, keine Freigabe/Archivierung)
- mögliche Alternative auf TF-Basis: https://github.com/tensorpack/tensorpack/tree/master/examples/FasterRCNN
### Keras-Generator / Multithreading
- lief nicht los / nicht weiter nach 1. Epoche
- alle Worker hatten gleiche Daten
- nicht auf leeren Seiten
### Packaging
- requirements
- `metric_tensors`
- `K.tf.where`
### leere Seiten / spärliche Regionen / Hintergrund vs Padding
Falschpositive ...
### Erweiterung auf Input-Annotierung mit Kontext (RGBA)
### Augmentierung
### Training und Inferenz mit inaktiven Klassen / Multiclass
- normalerweise:
- jeder Datensatz (`source`) enthält bestimmte Klassen (`category_id`)
- bei COCO-Import (`load_coco`) werden alle auf interne Klassen des Modells abgebildet (`add_class()`, `class_info`)
- es wird stets zwischen externen und internen Klassen umgerechnet (vorwärts: `map_source_class_id()` mit `"SRC.ID"`, `source_class_ids()`, rückwärts: `get_source_class_id()`)
- beim Training gehen die inaktiven Klassen (die nicht im Datensatz vorkamen) nicht in die Zielfunktion ein
- Probleme:
- wenn man mehrere COCO-Files nacheinander importiert, teilen sie sich keinerlei Klassen (werden alle externen auf verschiedene interne abgebildet)
- wenn man mehrere COCO-Files einzeln importiert, teilen sie sich alle Klassen (werden alle externen auf dieselben internen abgebildet)
- wir wollen jeweils nur 1 Klasse trainieren, aber alle im selben Modell haben (ohne alles auf einmal trainieren zu müssen)
- wir wollen auch bei Inferenz vorab bestimmen, welche Klasse überhaupt erlaubt ist
- also:
- Datensatz = Klasse
- alle Klassen sind immer (statisch) bekannt
## Probleme GPU-Cluster
### Modulsystem und Build
- [offizielle Anleitung](https://doc.zih.tu-dresden.de/hpc-wiki/bin/view/Compendium/BuildingSoftware) lückenhaft
- Haupt-Kritikpunkte:
1. Module vs Partitionen
1. Module hängen an _Toolchains_, welche nicht vermischt werden dürfen – was aber nicht verhindert oder mit Konfliktverwaltung aufgelöst wird
- viele große (aufwendig zu bauende) Bibliotheken für ML stehen nicht in sinnvollen (aktuellen oder älteren, für alle Partitionen/Architekturen) Versionen zur Verfügung, sind teilweise defekt
Bsp.:
- `TensorFlow/1.15.0-fosscuda-2019b-Python-3.7.4` in `modenv/ml` ist kaputt (gegen CUDA gelinkt, aber das ist nicht auffindbar, obwohl `CUDA/10.1.243-GCC-8.3.0` installiert ist)
```
Found device 0 with properties:
name: Tesla V100-SXM2-32GB major: 7 minor: 0 memoryClockRate(GHz): 1.53
...
Cannot dlopen some GPU libraries. Please make sure the missing libraries mentioned above are installed properly if you would like to use GPU. Follow the guide at https://www.tensorflow.org/install/gpu for how to download and setup the required libraries for your platform.
```
- `cuDNN/7.6.4.38-gcccuda-2019b` kaputt
```
module show cuDNN
----------------------------------------------------------------------------------------------------------------------------------------
/sw/modules/scs5/numlib/cuDNN/7.6.4.38-gcccuda-2019b.lua:
----------------------------------------------------------------------------------------------------------------------------------------
...
depends_on("gcccuda/2019b")
prepend_path("CPATH","/sw/installed/cuDNN/7.6.4.38-gcccuda-2019b/include")
prepend_path("LD_LIBRARY_PATH","/sw/installed/cuDNN/7.6.4.38-gcccuda-2019b/lib64")
prepend_path("LIBRARY_PATH","/sw/installed/cuDNN/7.6.4.38-gcccuda-2019b/lib64")
...
ls /sw/installed/cuDNN/7.6.4.38-gcccuda-2019b/lib64
ls: Zugriff auf /sw/installed/cuDNN/7.6.4.38-gcccuda-2019b/lib64 nicht möglich: Datei oder Verzeichnis nicht gefunden
ls /sw/installed/cuDNN/7.6.4.38-gcccuda-2019b/
easybuild include lib NVIDIA_SLA_cuDNN_Support.txt
```
- `Keras/2.3.1-fosscuda-2019b-Python-3.7.4`, die einzige aktuelle Keras-Version (nach TF 1.10), gibt es nicht für `modenv/ml`. Es gibt überhaupt keine kompatible Keras-Version für die Toolchain `fosscuda/2019b`.
- `Python/3.7.4-GCCcore-8.3.0` in `modenv/scs5` bietet kein PIL, und es gibt auch überhaupt keine kompatible Pillow-Version für die Toolchain `fosscuda/2019b`
- keine passenden PyPI-Releases für `ml`-Partitionen (PowerPC): kompilieren (z.B. OpenCV)
```sh
srun -p ml --gres=gpu:1 -n 1 --pty --mem-per-cpu=4000 bash
git clone --recurse-submodules https://github.com/skvark/opencv-python.git
module load CMake/3.15.3-GCCcore-8.3.0
ENABLE_HEADLESS=1 python src/opencv-python/setup.py bdist_wheel
pip install ~/src/opencv-python/dist/opencv_python_headless-4.2.0+d608d69-cp37-cp37m-linux_ppc64le.whl
```
- keine passenden Module auf `ml`-Partition (PowerPC): [Module selber bauen](https://doc.zih.tu-dresden.de/hpc-wiki/bin/view/Compendium/RuntimeEnvironment#Private_Project_Modules_Files) (z.B. GEOS)
### Oversubscription
### Downtime / Abbruch mitten im Job
```
Slurm Job_id=19495810 Name=gpu_training2 Ended, Run time 03:46:48, NODE_FAIL, ExitCode 0
...
Required node not available (down, drained or reserved)
```
### X11
Lösung für Tensorboard:
```shell=bash
mkdir taurus-ws
sshfs rosa992c@taurus.hrsk.tu-dresden.de:ws taurus-ws
tensorboard --logdir $(ls -tr1H taurus-ws/logs/* | tail -1)
```
...und dann lokal weiter mit `https://localhost:6006`
### Abschätzung von Betriebsmitteln und Quota für 0h-Jobs
- kein Zugriff auf `gpu-interactive`, also muß man immer einen kompletten Batch-Job definieren – kontiert wird aber stets die volle _geschätzte_ Zeit, nicht die tatsächlich (wegen Build-/Konfigurationsfehlers) verbrauchte
- teilweise schwer abzuschätzen ("wieviel GPU-Speicher _hätte_ er gebraucht?"), gerade bei gr. Speicherbedarf können sehr lange Wartezeiten entstehen, teilw. auch tagelang `pending`, also noch nicht mal Abschätzung, wann es losgeht
### Support (Zuständigkeit, Reaktionszeit, Sichtbarkeit, Dokumentation)
### Workspace-Timeout / Zugang
- `/scratch`-Speicher (500GB) verschwindet automatisch (ohne Backup), aber wenig Platz auf `/projects` (50GB) und in `~` (20GB); keine Warnung/Benachrichtung beim Löschen
- keine (sauber funktionierende) Quota-Anzeige
```
qinfo quota # as documented, but fails
Cannot read quotas: Cannot read xattr quobyte.quotas for file /projects/p090/p_da_layout
showquota # as documented, but empty
```
- Taurus nicht mehr vom Login-Server erreichbar, nur noch über TUD-VPN
- SSH-Schlüssel alle für ungültig erklärt, kein PW-loser Zugang mehr
Sign in with Wallet
Connect another wallet