egcolib.c

Allgemeine Bemerkung zu egcolib.c

loader(...) -->
             read_ctl_file(...)

In dieser Funktion wird der erste Teil des Kontrollfiles (z.B. ctl.lis) gelesen, der in einem festen Format forliegt. Jede Zeile enthält bestimmte Simulationsparamter am Anfang und einen String mit einer kurzen Beschreibung. Dabei ist zu beachten, dass die Reihenfolge und das Vorhandensein jeder Zeile fest vorgegeben ist.

Der Aufbau der Funktion ist einfach: File öffnen, Zeile für Zeile einlesen, die entsprechenden global_data Variablen setzen und viele Checks machen, ob die Werte im Kontrollfile sinnvoll sind und nicht etwa das Kontrollfile in einem falschen Format vorliegt.

Am Anfang werden erstmal in die Variable global_data->filenames[] die Namen der lis-files eingelesen, die später in der Funktion loader(...) noch alle eingelesen werden müssen. Dann folgen alle Simulationsparameter. Die werden je nach Variablentyp entweder mit read_int_skip(...), read_bool_skip(...) oder read_double_skip(...) eingelesen.

Nach dem Einlesen des Strings, der das Output-Verzeichnis festlegt, wird das Output-Verzeichnis (üblicherweise ./out) erstellt, wenn es noch nicht schon existiert.

Dann gibt es da noch die User-defined integers und doubles, über die Werte an EGO übergeben werden können, die in der global_data Struktur gespeichert und an alle Knoten verschickt werden können. Diese Werte haben für normale Simulationen keine Bedeutung, eignen sich aber wähernd der Programmentwicklung um mal schnell Parameter an EGO übergeben zu können. Bei den User-defined integers und doubles wird die Philosophie des festen Formats des Kontrollfiles von EGO etwas unterlaufen, da es von der Anzahl der User-defined integers und doubles abhängt, wieviele dementsprechende Zeilen einzulesen sind. Naja,... keine Regel ohne Ausnahmen. Bei den Pulling-Parametern geht's dann wieder mit dem festen Format weiter.

Am Schluss der Funktion kommen dann noch viele Checks, ob die eingelesenen Werte auch sinnvol sind.

loader(...) -->
             read_flood_file(...)

Falls im Kontrollfile der Flooding-Algorithmus oder die Translations/Rotationskorrektur eingeschalten worden ist, wird in dieser Funktion eine Liste (flood_used_atoms) eingelesen, die festlegt, auf welche Atome das Flooding-Potential wirken soll, die Zentren der zu floodenden Konformationszustände (flood_cm, "center of gaussians") und jeweils die dazugehörige Flooding-Matrix (flood_matrix).

Das flooding-file wird auch dann eingelesen, wenn nur die Translations/Rotationskorrektur eingeschalten wurde, wobei das flooding-file dann nur die Liste zu enthalten braucht, die festlegt, auf welche Atome die Translations/Rotationskorrektur wirken soll. Diese Liste enthält für jedes Atom entweder eine "0" (Flooding-Potential und Translations/Rotationskorrektur soll auf dieses Atom nicht wirken) oder eine "1" (Flooding-Potential und Translations/Rotationskorrektur soll auf dieses Atom wirken).

Üblicherweise wird ein flooding-file durch das Utility-Program mkflood erzeugt.

loader(...) -->

Hier werden alle Daten eingelesen, die für die Definition des arbitrary-shaped SBOUND benötigt werden. Das Signal für EGO das arbitrary-shaped SBOUND zu verwenden und das entsprechende Daten-file zu lesen ist ein negativer Wert von global_data->sbound_droff[R_SPHERE], der im Kontrollfile gesetzt werden kann. Ansonsten hat die Funktionen einen einfachen Aubau. Man beachte: In dieser Funktion wird nur die Form des arbitrary-shaped SBOUND eingelesen, also die Form des Volumens. Wie das Potential aussieht wird in read_sbound_file(...) eingelesen.

Achtung: Die arbitrary-shaped SBOUND Funktionalität ist in EGO noch nicht ausreichend getestet (Grubi fragen!).

loader(...) -->

Hier wird das Potential für das arbitrary-shaped SBOUND eingelesen. Das ganze ist aber in einem Entwicklungsstadium steckengeblieben und bedarf noch einiger Entwicklungsarbeit.

Achtung: Die arbitrary-shaped SBOUND Funktionalität ist in EGO noch nicht ausreichend getestet. Siehe auch die Funktion read_boundary_file(...).

loader(...) -->

Hier wird, falls vorhanden, das Restart-file eingelesen. Wenn der letzte Buchstabe im Restart-filenamen ein '@' ist, dann wird es jedoch nicht verwendet, auch wenn es vorhanden ist. Dieses Feature ist vor allem für Testzwecke wäherund der Programmentwicklung oder bei Performance-Tests hilfreich. Man muss dann nämlich nicht immer das Restart-file per Hand löschen, um beim nächsten Start von EGO wieder mit Integrationsschritt 0 zu beginnen.

Das Restart-file soll per Definition alle Daten beinhalten, die eine unterbrochene Simulation mit den gleichen Bedingungen weiterführen zu können. Hierzu sind natürlich die Positionen der Atome und die Geschwindigkeiten der Atome nötig. Der Verlet-Algorithmus rechnet allerdings nicht mit Geschwindigkeiten, sondern greift auf die Koordinaten des letzten und des vorletzten Integrationsschrittes zurück. Und genau diese Koordinaten werden auch im Restart-file deswegen gespeichert. Im Koordinaten-file coord.lis ist dies anders. Dort werden die Koordinaten und Geschwindigkeiten angegeben.

Als erstes werden in dieser Funktion die Positionen der Atome des vorletzten Integrationsschrittes in die Variable atom_data[i].vel[0|1|2] eingelesen (Achtung: Obwohl vel natürlich an "Velocity" erinnert, enthält dieser Array im Fall eines Restarts Atompositionen. Nur wenn nicht gerestartet wird, enthält dieser Array Geschwindigkeiten, die aber aus dem File coord.lis gelesen werden).

Als nächstes werden die Positionen der Atome des letzten Integrationschrittes in die Variable atom_data[i].ko[0|1|2] eingelesen. Ausserdem muss noch der Fall berücksichtigt werden, wenn sich die Integrationsschrittweite im Restart-file (old_time_step) von der im Kontrollfile (global_data->time_step) unterscheidet. Dann werden entsprechend dem Unterschied der Integrationsschrittweiten die Atompositionen des vorletzten Integrationsschrittes angepasst. Dies ist durch eine einfache Skalierung mit dem Faktor time_factor möglich.

Am Ende des Restart-files sind noch weitere Daten angehängt, die für einen ordentlichen Restart nötig sind. Dies sind zum einen Daten, die wichtig sind für den Pulling- und Immobilisation Algorithmus wichtig sind. Ausserdem noch Daten für das SBOUND, das QM-Interface und den Flooding-Algorithmus.

Sollten im Zuge weiterer Entwicklungen noch zusätzliche Daten mit ins Restart-file aufgenommen werden müssen, dann sollte man unbedingt darauf achten, dass die Erweiterung so gehalten wird, dass auch "alte" Restart-files gelesen werden können.

loader(...) -->

In dieser Funktion wird der letzte Teil des Kontrollfiles gelesen, der in einem freien Format vorliegt. Hierzu wird das Kontrolfile zum Lesen geöffnet und alle Zeilen bis zum Keywort "END" gelesen. Das Keyword "END" markiert das Ende des Fest-Format Teils des Kontrollfiles. Dann wird jede Zeile der Frei-Format Section in den String sdum hineingelesen. In der Frei-Format Section können neben den Keywords auch Kommentare eingegeben werden. Solche Zeilen beginnen entweder mit "!" oder "#". Ausserdem sind in beschränktem Masse auch C-Komentare mit "/*" und "*/" möglich. Nach dem für eine Zeile festgestellt worden ist, dass es sich um keine Kommentarzeile handelt, wird der String enthalten in sdum in Keyword-Anteil und Rest-Anteil zerlegt. Hierzu wird das erste Zeichen nach der ersten Buchstabenfolge auf 0 gesetzt und damit der Keyword-String sdum terminiert. Dann wird von dort aus nach dem nächsten von einem White-space verschiedenen Character gesucht, so dass der Rest-Anteil der Zeile in sdum+j enthalten ist.

Der Rest der Funktion ist dann von einfacherer Struktur. Es werden einfach String-Compares gemacht (z.B. if (strcmp(sdum,"TOTAL")==0)), um Keywords zu identifizieren und entsprechende Einstellungen vorzunehemen. Wenn ein Keyword passt, dann muss in der Regel auch der String nach dem Keyword, enthalten in sdum+j, analysiert werden. Das geschieht meist durch sscanf, wobei eine global_data-Variable entsprechend gesetzt wird.

Dann gibt es da noch Keywords, die als Parameter einen EGO-Atomselection-String (AS-Strings) enthalten. Diese AS-Strings legen z.B. fest für welche Atome die Gesamtkraft (TOTAL) in eine Datei geschrieben werden soll. In EGO wird diese Information in einem int-Array (hier forceout_atoms[...]) gespeichert, wobei jedes Arrayelement die Information für ein Atom verwaltet. Da nur gespeichert werden muss, ob für das Atom i die Gesamtkraft auf File geschrieben werden soll oder nicht, benötigt diese Information nur ein Bit. Deshalb wird jedes int-Arrayelement als Bitmuster angelegt, wobei z.B. Bit 0 das Rausschreiben der Gesamtkraft steuert, Bit 1 das Rausschreiben der van der Waals Kraft usw.. Wenn also z.B. das Keyword TOTAL erkannt worden ist, dann wird durch
mask = FORCE_TOTAL ein solches Bit spezifiziert. Dann wird durch den Funktionsaufruf set_used_atoms(...) entsprechend dem AS-String ein Array used_atoms aufgebaut, der für jedes ausgewählte Atom eine "1" enthält, sonst lauter "0"-er. Nach dieser Selektion wird dann durch forceout_atoms[i] |= mask das entsprechende Bit in dem forceout_atoms-Array gesetzt. Dieser Array wird dann später an alle Slaves-Knoten verteilt, damit die wissen, welche Kräfte sie dann an den Master zu schicken haben, der diese Kräfte dann raussschreibt. Nach dem sleben Prinzip arbeitet auch die Selektion für die Steuerung der Berechnung der Hesse-Matrix, der Selektion von QM-Atomen und anderen Spezialfunktionen von EGO.

Am Ende der Funktion, nach Analyse aller Zeilen des Frei-Format Abschnittes werden dann noch ein paar Ausgaben und Checks gemacht, die aber leicht zu durchblicken sind.