Computermethoden zur Lösung einiger konkreter kombinatorischer ...

Erstellung von Statistiken für Polytope
3.3 Implementierung & Polymake 61
Das Ziel ist die Erstellung einer möglichst großen Menge von kombinatorisch verschiedenen
Polytopen, wobei Statistiken über den Unterschied der Verteilungen der
kombinatorisch verschiedenen Polytope und geometrisch gleichverteilten Polytope gesammelt
werden sollten. Hierzu werden zwei Experimente durchgeführt, wobei das
erste Experiment signifikant verbessert werden kann.
Die natürliche Vorgehensweise beim Suchen nach kombinatorisch verschiedenen Polytopen
wäre das Testen eines neu erzeugten Polytops auf kombinatorische Äquivalenz
mit einer Menge aus schon gefundenen kombinatorisch verschiedenen Polytopen. Allerdings
ergibt sich ein Problem, falls viele Rechenknoten gleichzeitig ein neues Polytop
der nummerierten Liste hinzufügen wollen. Geprüft müsste auch die Möglichkeit,
dass zwei verschiedene Rechenknoten ein kombinatorisch äquivalentes Polytop gefunden
haben. Da der Aufbau der Programme möglichst einfach gehalten werden soll,
wird auf Bibliotheken zur netzwerkweiten Synchronisation verzichtet. Der Preis dafür
sind 10 Sekunden für ein Einfügen eines Polytops in eine bestehende Liste. Realisiert
wird ein mutex-Algorithmus auf der Basis von NFS (Network File System). Dabei
stellte sich heraus, dass nach einer Vorbereitenden Aufbauphase der Liste kombinatorisch
verschiedener Polytope durch einen einzigen Rechner, somit ohne Synchronisationsprobleme,
bei der anschließenden parallelen Suche, keine Situation mit unnötigen
Wartepausen auftritt. Auch in einer ungünstigen Situation, also bei einer leeren oder
kleinen Liste bekannter kombinatorisch verschiedener Polytope, findet das parallele
Einfügen fast immer jede 10 Sekunden statt, also die minimale Zeit, die sicher zur
Synchronisation aller netzwerkweiter Rechenknoten per NFS ausreicht.
Zur Synchronisation verwendet der NFS mutex-Algorithmus die globale Datei lock,
deren Größe die Anzahl schreibender Rechenknoten anzeigt, die zwar den kritischen
Bereich schon betreten haben, aufgrund der Verteiltheit und der Laufzeiten des Systems
aber den blockierten Status (lock > 0) erst zu spät erfahren haben. Falls dies
der Fall ist (lock > 1), wird eine zufällige Anzahl von Sekunden gewartet und der
Versucht wiederholt. Wie bereits dargestellt, kommt diese Situation selten vor. Wichtig
dabei ist, falls ein neues Polytop in die Liste eingefügt wird, müssten die restlichen
wartenden Rechenknoten ihre Polytope auf Äquivalenz zu diesem neuen Polytop testen.