6.12. Implementation des Programmsystems EROS7

EROS7 ist wie die verwendete, neue Datenstruktur RICOS aus Gründen der Datenabstraktion in C++ geschrieben. Wie schon in Abschnitt 3.1 gesagt, besteht ein Programm zur Vorhersage von Reaktionen aus mehreren Teilen. Diese sind noch einmal in Abbildung 137 gezeigt, wobei die Regelschnittstelle als Bindeglied zwischen der Reaktionsgenerierung, der chemischen Datenstruktur und den Regeln eingefügt wurde. Die Regeln fassen die Kodierung der Reaktionstypen und die Bewertung der Reaktionen sowie sämtliche anderen Einstellmöglichkeiten für EROS7 zusammen.

Abbildung 137: Aufbauschema von EROS7.

6.12.1. Aufbau der Reaktionsgenerierung

Analog zum logischen Aufbau von EROS7 in Abbildung 137 gliedern sich auch die Klassen von EROS7. Die Hauptwege, wie die verschiedenen Klassen aufeinander aufbauen, sind in Abbildung 138 dargestellt. Durchgezogene Pfeile zeigen an, daß die Klasse an der Spitze in der Klasse am Ende enthalten ist. Ist der Pfeil gestrichelt, hat die Klasse nur einen Zeiger auf die Klasse und greift über diesen auf deren Elementfunktionen zu. Neben dem Hauptprogramm eros7, der chemischen Datenstruktur RICOS, deren Klassen der Vereinfachung halber zusammengefaßt wurden und die in [52] genauer beschrieben sind, und den wahlweise aufgerufenen Regelfunktionen rules_cc und rules_tcl gliedern sich die Klassen, angezeigt durch ihr Präfix, in drei Gruppen: gg_ (graph generation) Aufbau des Reaktionsnetzwerks und Kinetik, rx_ Reaktionsgenerierung und rul_ (Teil der Regel) ein Reaktionstyp.

Abbildung 138: Hauptbeziehungen der Klassen von EROS7.

Der reine Aufbau des Reaktionsnetzwerks gliedert sich, wie die Funktionalität von EROS7 in das Reaktionsnetzwerk (gg_rnet), die Reaktoren (gg_rctr) und die Phasen (gg_phas2). Da die Reaktoren, Phasen und der Reaktionsgenerator (rx_gen2) auf mehrere gemeinsame Objekte zugreifen müssen, sind diese in einer Klasse zusammengefaßt (gg_pool). Sie enthält die Speicherung der Aggregate bzw. Ensembles (rx_easto) und die der Reaktionen (rx_sto2) sowie die Kinetik (gg_kinet) und davon abgetrennt die aufgestellten Differentialgleichungen (gg_difun). Ein Objekt der Klasse rx_info2 speichert genau eine erzeugte Reaktion. Die Informationen über die verwendeten Regeln sind in den Klassen rx_ruinf (globale Information, wie Zahl der Reaktoren und Phase, usw.) und rul_info (Angabe zu einem Reaktionstyp) gespeichert.

Neben dem Reaktionsgenerator (rx_gen2), der die Regelfunktionen rules_cc bzw. rules_tcl für die Durchführung der Reaktionen aufruft, verbleiben noch die beiden wichtigen Klassen rx_datex (Variablenaustausch zwischen EROS7 und den Regeln) sowie rx_eifc (Zugriff auf die Moleküle und Modifikation der chemischen Struktur), über die die Regeln auf die entsprechenden Teile von EROS7 zugreifen. Hierzu werden die Regelfunktionen jeweils mit einem Zeiger auf die aktuell gültigen Objekte dieser Klassen aufgerufen. Der direkte Zugriff auf die chemische Datenstruktur erfolgt über ein Objekt der Klasse rx_dsifc, das sich die Arbeit der Abbildung der in den Regeln verwendeten Indizes für die Atome, Elektronensysteme, etc. auf die entsprechenden Zeiger der RICOS-Objekte von rx_idx2p abnehmen läßt.

Der Aufbau des Reaktionsnetzwerks wird also von den Klassen gg_rnet, gg_rctr, gg_phas2, gg_pool, rx_sto2, rx_easto und rx_info2 übernommen (vergleiche Abbildung 137). Die Regelschnittstelle gliedert sich in die Klassen rx_ruinf, rul_info, rx_eifc, rx_dsifc, rx_idx2p und rx_datex. Da die Klasse rx_datex den Variablenaustausch mit den Regeln bewerkstelligt und die Regeln auch in Tcl geschrieben werden können, muß diese Klasse auch den Anschluß an die Variablen des Tcl-Teils enthalten. Zu diesem Zweck entspricht diese Klasse im Fall der C++-Regeln der Klasse rul_datx bzw. im Fall der Tcl-Regeln der um die Anbindung der Tcl-Variablen erweiterten Klasse dat_trans. Diese Umschaltung und einige weitere kleine Änderungen werden durchgeführt, wenn bei der Compilation TCL definiert wird. Ist dies der Fall, können zusätzlich zu den C++-Regeln auch compilierte und interpretierte Tcl-Regeln verwendet werden.

6.12.2. Anbindung der Wissenbasis (Regeln) an EROS7

Um keinen eigenen Regelinterpreter schreiben zu müssen, die Konstrukte der mächtigen Sprache C++ nutzen zu können und da bereits bei der Planung an den Anschluß von Tcl gedacht wurde, sind die Regeln als Funktionsaufruf an EROS7 angebunden. EROS7 kann mehrere solcher Funktionen verwalten und ruft standardmäßig entweder die C++- bzw. Tcl-Regeln auf. Als Übergabeparameter erhält sie drei Zeiger auf Klassen und mehrere Schaltervariablen, die festlegen, welcher Teil der Regeln gerade ausgeführt werden soll. Diese drei Klassen sind ein Stream zur Ausgabe von Kommentaren, rx_datex, die Klasse für den Variablenaustausch, und rx_eifc für die Zugriffe und Modifikationen auf der Datenstruktur RICOS.

6.12.2.1. Teile der Regelfunktion

Zunächst wird über die Variable, die die Regelnummer angibt, unterschieden, ob der Regeldateikopf (GLOBAL) gefragt ist oder einer der Reaktionstypen, die Nummern von 1 bis 1000 haben können (siehe Abbildung 139). Die Nummern müssen dabei nicht zusammenhängend sein. Ob der entsprechende Aufruf erfolgreich beendet werden konnte, zeigt die Regelfunktion dadurch an, daß sie den Wert OK (erfolgreich) bzw. BAD als Rückgabewert liefert.

Abbildung 139: Grundgliederung der Regeln.

Der Regelkopf und jeder von den Reaktionstypen sind noch weiter untergliedert. Dies wird von der Variable vom Typ OP (wie operation) selektiert. Für den Regelkopf ist dies in Abbildung 140 gezeigt.

Abbildung 140: Teile des Regelkopfes.

In INIT_RULES werden die Einstellungen für die Reaktoren, Phasen und die Kinetik sowie der Variablenaustausch neben ein paar weiteren globalen Einstellungen, zu denen beispielsweise der Modus für die Valenzprüfung der Produkte gehört, durchgeführt (siehe 6.7 und Anhang B.2). PREP_ROOT, PREP_EDUCT und DISTRIBFUNC sind die Vorbehandlungsfunktionen für die Ausgangsmaterialien (siehe 6.4.1) und die Edukte (siehe 6.4.2) sowie die Verteilungsfunktion (siehe 6.6.4). FINISH (siehe Anhang B.2.11) ist der Teil, der als letztes vor Beendigung eines EROS7-Laufs aufgerufen wird. Er ist für abschließende Tätigkeiten vorgesehen (z.B. Schließen von Dateien), wenn EROS7 als Schnittstelle für andere Programme zur chemischen Datenstruktur RICOS verwendet wird. MODFUNC (siehe Anhang B.2.10) ist ein Teil, der für Erweiterungen von EROS7 vorgesehen ist. Hier können auch andere Funktionen, die nichts mit der Funktion der Regeln zu tun haben, EROS7 bereitgestellt werden. Der Name von MODFUNC kommt vom englischen Ausdruck model function.

Jeder der Reaktionstypen gliedert sich dagegen in nur drei Teile, RULE_INFO (siehe 6.5), der die Definition der Reaktionssubstruktur, den Namen und die Attribute des Reaktionstyps enthält, CONSTR (constraints, siehe 6.5.5), die Überprüfung der Bedingungen am Reaktionszentrum und FUNC (function, siehe 6.6), die Durchführung der Reaktion sowie die Berechnung der Reaktivität.

Abbildung 141: Teile eines Reaktionstyps.

Detaillierte Angaben, wie die Regeln in C++ bzw. Tcl abgefaßt werden, stehen im Anhang B.

6.12.2.2. Datenaustausch zwischen den Regeln und dem Kernsystem

Der Datenaustausch zwischen den Regeln und dem Kernsystem von EROS7 wurde so konstruiert, daß EROS7 leicht erweitert werden kann. Deshalb wurde darauf verzichtet, einen festen Satz von Variablen zu übergeben, über den EROS7 gesteuert wird. Bei Erweiterungen erfordern erfahrunsgemäß auch zusätzliche Einstellungsmöglichkeiten, für die zusätzliche Variablen benötigt werden. Bei einem festen Satz von Variablen müßte auch die Variablenübergabe angepaßt werden. Um dies zu vermeiden, erfolgt die Variablenübergabe zwischen den Regeln und EROS7 über ein Objekt der Klasse rx_datex, bei der die beiden miteinander kommunizierenden Teile die Variablen typsicher unter einem frei wählbaren Namen austauschen. Das Objekt speichert alle von einem Teil angebotenen Variablen, während der andere Teil in diesem Objekt nachsieht, ob die ihm bekannten Variablen enthalten sind. Dieser Teil kann dann dynamisch darauf reagieren, ob eine bestimmte Variable zur Verfügung steht oder nicht. Als mögliche Reaktionen bei Abwesenheit sind denkbar, eine alternative Quelle der Information zu nutzen, beispielsweise Standardwerte zu nehmen, oder bei einer essentiellen Variablen mit einer Fehlermeldung den entsprechenden Programmteil zu verlassen bzw. EROS7 gänzlich zu beenden.

Programmiertechnisch werden in jeweils zwei parallelen Listen für die verschiedenen Variablentypen die Zeiger auf den Namen und auf die Variable selbst gespeichert. Es wird der Zeiger auf die Variable und nicht deren Inhalt übergeben, damit sie nur einmal übergeben werden muß, während sie zu mehreren Zeitpunkten des Programmlaufs gelesen werden kann und man immer den aktuellen Wert erhält. Wichtig ist noch, daß die Variable zum Zeitpunkt des Lesezugriffs noch nicht deallociert wurde. Da die Programmiersprache C++ wie auch C ihre Variablen standardmäßig dynamisch allociert und deallociert, hätte das zur Folge, daß die Variable beim Verlassen eines Programmteils gelöscht würde und somit der später folgende Lesezugriff fehlschlagen würde. Deshalb müssen alle übergebenen Variablen als static deklariert werden, damit sie nach der ersten Allocation erst wieder zum Programmende gelöscht werden. Das gleiche gilt im Grunde auch für die Namen, unter denen die Variablen übergeben werden. Da für sie in der Regel Konstanten verwendet werden, die automatisch static sind, muß für sie nichts besonderes berücksichtigt werden.

Da fast alle Variablen bei der Initialisierung der Regeln ausgetauscht werden, muß auch der erhaltene Zeiger auf eine Variable dauerhaft gespeichert werden, damit er beim nächsten Aufruf noch seinen Wert besitzt. Deshalb müssen auch die gespeicherten Zeiger als static deklariert werden. Da der lesende Teil einen const-Zeiger erhält, kann dieser den Inhalt der Variablen nicht ändern und der setzende Teil kann sich immer darauf verlassen, daß die Variable immer ihren vom setzenden Teil zuletzt zugewiesenen Wert enthält.

Übergeben werden können Zeichenketten, ganzzahlige Werte und Fließkommazahlen sowie Vektoren und Matrizen der beiden letzteren. Konstante Werte werden getrennt übergeben, damit man sich bei ihrer Übergabe eine Referenzierung sparen kann. Für sie werden die Inhalte der Variablen statt der Zeiger auf sie weitergereicht. Die Konstanten werden fast ausschließlich für die Einstellungen von EROS7 verwendet. Da es für Vektoren und Matrizen in C++ schwierig ist, Konstanten anzugeben, können statt Vektoren und Matrizen Konstantenarrays vermittelt werden. Für Konstanten stehen folgende Typen zur Verfügung: ganze Zahlen, Arrays ganzer Zahlen, Fließkommazahlen, Zeichenketten und Arrays von Zeichenketten.

Das folgende Beispiel zeigt die Übergabe der Variablen, die die Geschwindigkeitskonstante für die einzelnen Reaktionen enthält. Drei Punkte stehen im unten angegebenen Code für Teile, die der Übersichtlichkeit halber weggelassen wurden. Die eingerückten Teile zeigen die angesprochenen Abschnitte der Regeln.

 
 rx_datex vars;
 RULE_OK res;
 ...
 // Übergabe des Zeigers auf die Variable mit
 // der Geschwindigkeitskonstante an die Klasse
 // rx_datex
 res = rules_cc(..., &vars, GLOBAL, INIT_RULES, ...);
 	RULE_OK rules_cc(..., rx_datex *val, ...) {
 	  static double k;
 	  ...
 	  case INIT_RULES:
 	    ...
 	    val->put("reactivity", &k);
 	    return OK;
 	  ...
 	}
 
 // Abholen des Zeigers aus dem
 // Objekt der Klasse rx_datex
 static const double *reactivity;
 vars.get("reactivity", &reactivity);
 ...
 
 // Aufruf zur Durchführung einer Reaktion
 // und Setzen der Geschwindigkeitskonstante
 res = rules_cc(..., 0, 1, FUNC, ...);
 	RULE_OK rules_cc(...) {
 	  ...
 	  case FUNC:
 	    ...
 	    k = 1e-13;
 	    return OK;
 	  ...
 	}
 
 // Lesezugriff auf die Variable mit der
 // Geschwindigkeitskonstante und Ausgabe
 cout << "Die Geschwindigkeitskonstante ist: " << *reactivity << endl;

6.12.2.3. Anbindung der Regelfunktion

Da die Regeln als Funktion aufgerufen werden, verhält sich der Aufruf der Regelfunktion wie jeder andere Funktions- oder Subroutinenaufruf. Dementsprechend gibt es für die Anbindung zwei Wege, sie statisch oder dynamisch zum ausführbaren Programm zu binden. Bei der statischen Bindung sind die übersetzten Regeln Bestandteil des Programms. Sollen sie geändert werden, müssen die neuen Regeln übersetzt werden und das gesamte Programm, EROS7, neu gebunden werden. Bei den modernen Compilern und Linkern ist es neben dieser Methode auch möglich, einen Satz von Funktionen in einer Bibliothek dynamisch zum Programm zu binden. Dies bedeutet, daß beim Binden des Programms zwar die Anwesenheit der einzelnen Funktionen in der Bibliothek überprüft wird, die Funktionen selbst aber nicht zum Programm gebunden werden. Es wird lediglich im Programm vermerkt, daß die eine oder andere Funktion aus dieser Bibliothek für das Programm benötigt wird. Wird dieses Programm aufgerufen, werden das Programm und die dynamische Bibliothek in den Hauptspeicher geladen und fertig gebunden. Es ist also möglich, ein EROS7 ohne Regeln zu erzeugen und die Regeln in einer zweiten Datei, einer dynamischen Bibliothek zu halten. Neben diesen beiden Möglichkeiten, die bei jeder modernen Entwicklungsumgebung besteht, gibt es unter Solaris 2 auch einen inkrementellen Linker (ild) [64], der beim ersten Binden etwas Platz im Programm reserviert, wodurch er auch beim fertigen Programm in der Lage ist, einzelnen Module (Funktionen) nachträglich auszutauschen. Wurden zu viele Module ausgewechselt, bindet auch der inkrementelle Linker das gesamte Programm neu.

6.12.2.4. Anbindung anderer Sprachen, wie zum Beispiel Tcl

Soll zur Kodierung der Regeln eine andere Sprache verwendet werden, die gegenüber C++ als geeigneter angesehen wird oder andere Vorteile bietet, liegt die Vorgehensweise auf der Hand. Man erstellt eine Funktion in C++, die beim Aufruf der verschiedenen Teile der Regeln die entsprechenden Abschnitte in der anderen Sprache ausführt. Damit EROS7 neben den Regeln in C++ wahlweise auch Regeln in der anderen Sprache ausführen kann, hat EROS7 standardmäßig zwei gleiche Regelschnittstellen für die Regeln in C++ und Tcl. Da schon während der Entwicklung von EROS7 der Anschluß der Sprache Tcl geplant wurde, heißen die beiden Regelfunktionen rules_cc und rules_tcl. Welche dieser Funktionen aufgerufen wird, wird mit der Option -r beim Starten von EROS7 festgelegt. Fehlt diese Option oder wird -rcompiled_c++ angegeben, werden die C++-Regeln verwendet, anderenfalls wird die Funktion rules_tcl aufgerufen. Notwendige Initialisierungen können beim ersten Aufruf der Regeln (INIT_RULES) vorgenommen werden, wobei auch der Wert der Option -r zur Verfügung steht. Sind in einer Spezialversion weitere Regeln in C++ zu EROS7 gebunden worden, können auch diese mit der Option -r angesprochen werden.

Die Schnittstelle zu Tcl, die von Frau L. Steinhauer erstellt wurde, ruft intern den Tcl-Interpreter auf. Dieser liest die Regeln beim Initialisieren aus der Datei, die für die Regeln angegeben wurde. Durch die Verwendung eines Interpreters kann man auch Regeln verwenden, die erst nach dem Start des Programms eingelesen werden und nicht zum System gebunden sind - eine andere Möglichkeit von dynamischen Regeln. Da eine Datei auch mehrere Tcl-Prozeduren enthalten kann, wird optional auch noch der Name der zu verwendenden Prozedur angegeben. Standardmäßig wird die Prozedur mit dem Namen Tcl_rule genommen. Alternativ dazu kann EROS7 auch so gestartet werden, daß der Tcl-Interpreter eine compilierte und zum System gebundene Tcl-Prozedur aktiviert. Dies erfolgt durch die Angabe der Option -rcompiled_tcl. Die Selektion der einzelnen Abschnitte der Regeln erfolgt in der Tcl-Prozedur über den Inhalt von vordefinierten globalen Variablen, denen die Werte der Schaltervariablen zugewiesen werden, mit denen die Regelfunktion von EROS7 aufgerufen wurde. Für den Variablenaustausch sowie für die Zugriffe auf die chemische Datenstruktur RICOS (Modifikationen und Lesen von Eigenschaften) gibt es Prozeduren, die die Zugriffe auf die Objekte der Klassen rx_datex und rx_eifc bewerkstelligen, über die EROS7 mit den Regeln kommuniziert und die beim Aufruf der Regeln angegeben wurden.

Eine besondere Rolle spielt die Übergabe der Variablen von und zu EROS7, da Tcl nur Variablen vom Typ Zeichenkette sowie Arrays und Listen von Zeichenketten kennt. Bei jedem Austausch müssen die Werte deshalb konvertiert werden. Für die Übergabe von Variablen durch put oder putco, die über ein Objekt der Klasse rx_datex an EROS7 übergeben werden, muß eine C++-Variable vom richtigen Typ allociert werden. Damit der Typ automatisch festgestellt werden kann, muß die Tcl-Variable zum Zeitpunkt der Übergabe einen Wert besitzen, aus dem der Typ abgeleitet werden kann. Damit bei jedem Aufruf und Verlassen des Tcl-Teils die übergebenen Variablen die richtigen Werte enthalten, kann Tcl solche Variablen linken, was bedeutet, daß sie am Anfang und Ende der Tcl-Teile hin- bzw. herkonvertiert werden. Dieser Mechanismus wird auch verwendet, wenn eine Variable mit get in den Regeln von EROS7 abgeholt wird. Diese Funktionalität, das Linken und Konvertieren von Tcl-Variablen, ist der Klasse dat_trans zu der der Klasse rul_datx hinzugefügt worden. Ist EROS7 ausschließlich für C++-Regeln übersetzt worden, verbirgt sich hinter der Klasse rx_datex die Klasse rul_datx, ist auch der Tcl-Teil in EROS7 enthalten, ist sie die Klasse dat_trans. Da die an EROS7 übergebenen Tcl-Variablen bei jedem Verlassen in die C++-Variablen konvertiert werden, also gelesen werden, dürfen die Variablen nicht dynamisch allociert werden, sondern müssen statisch verfügbar sein, was durch die global-Deklaration erreicht wird. Übergebene Konstanten werden dagegen nicht gelinkt, sondern nur ein einziges Mal konvertiert.

Für die Manipulation und den Zugriff auf die Datenstruktur sind entsprechende Prozeduren vorhanden, die die übergebenen Werte konvertieren und anschließend die Elementfunktionen (Zugriffsfunktionen auf Objekte der Klasse) der Klasse rx_eifc aufrufen.

6.12.3. Zugriffe auf die chemische Datenstruktur RICOS

Der Zugriff auf die Datenstruktur RICOS erfolgt über Elementfunktionen der Klasse rx_eifc. In den Regeln werden die Atome, Elektronensysteme usw. über Indizes selektiert, damit es auch möglich ist, andere Sprachen wie Tcl zur Kodierung der Regeln verwenden zu können. Die chemische Datenstruktur RICOS arbeitet allerdings mit Zeigern auf die Bestandteile der Moleküle, weshalb bei jedem Zugriff zunächst die Indizes in die entsprechenden Zeiger umgewandelt werden müssen. Erst danach kann die eigentliche Aktion ausgeführt werden.

6.12.3.1. Indizes der Atome, Elektronensysteme usw.

Alle Zugriffe auf die chemische Datenstruktur RICOS erfolgen von den Regeln aus über Indizes der Bestandteile des Ensembles: Atome, Elektronensysteme usw.. Sowohl die Abfrage von Eigenschaften, wie auch die Reaktionsgenerierung, werden unter Verwendung dieser Indizes ausgeführt. Während der Reaktionen werden die Elektronen und damit meist auch die Elektronensysteme umgeordnet. Dies hat zur Folge, wenn zwei oder mehrere Elektronensysteme zu einem vereinigt werden, daß manche Elektronensysteme nach einer Reaktion nicht mehr existieren bzw. nach einem Bruch eines Elektronensystems neu gebildet werden. Neu gebildete Elektronensysteme erhalten neue höhere Nummern.

EROS7 ist in der Lage, auch mehrere Reaktionsteilschritte nacheinander durchzuführen. Um das Edukt bzw. Zwischenprodukt nicht zu verändern und damit weiterhin zugriffsbereit zu halten und dennoch die Reaktion an der Verbindung durchzuführen, kopiert EROS7 vor jedem Abschnitt von Reaktionsteilschritten das Reaktionsensemble und führt diese auf der Kopie durch. Zu welchem Abschnitt die gerade ausgeführte Aktion gehört, wird von EROS7 automatisch aus dem Wechsel zwischen der Abfrage von Eigenschaften und Reaktionsteilschritten erkannt. Um Eigenschaften des Reaktionszentrums im Produkt abfragen zu können und anschließend weitere Reaktionsteilschritte vorzunehmen, müssen die Atome, Elektronensysteme und Gruppen während der gesamten Reaktionsschritte ihre Nummern behalten. Da durch die Kombination von Elektronensystemen und das Löschen von Aggregaten Elektronensysteme und Atome gelöscht werden können und somit nach Reaktionen die Indizes nicht mehr konsekutiv durchnumeriert sind, die Datenstruktur RICOS für ihre Indizes aber darauf besteht, können diese nicht verwendet werden. Die Regelschnittstelle generiert deshalb eigene Indizes, über die von den Regeln aus auf die Datenstruktur zugegriffen wird. Für die Zuordnung der Atome, Elektronensysteme und Gruppen im Original und in der Kopie werden die beim Cleanup der Datenstruktur neu zugeteilten Indizes von RICOS eingesetzt. Danach werden die Indizes der Reaktionsschnittstelle so gesetzt, daß gleiche Atome usw. gleiche Nummern erhalten. Bei den meisten Reaktionen ändern sich die Zuordnungen von Atomen, Elektronensystemen und Gruppen zu Molekülen und Aggregaten. Da in einigen Fällen die Zuordnung der Moleküle im Eduktensemble zu denen im Produktensemble nicht eindeutig ist und oft nur interessant ist, zu welchem Molekül ein bestimmtes Atom gehört, werden Moleküle und Aggregate nach der Reaktion neu durchnumeriert. Aggregat- und Molekülnummern für die Produkte werden über die Atome, die sie enthalten, abgefragt.

Diese Abbildung und Aktualisierung der Indizes auf die richtigen Zeiger der Datenstruktur RICOS übernimmt die Klasse rx_idx2p. Während des Kopiervorgangs wird die Zuordnung der Indizes von RICOS auf die Indizes der Reaktionsschnittstelle in einem Objekt der Klasse namens rx_numbr gespeichert. Diese wird bis zum Abschluß aller Teilschritte aufbewahrt, damit es auch möglich ist, zu einem späteren Zeitpunkt auf ein früheres Zwischenprodukt oder das Edukt zugreifen zu können. Dies ist beispielsweise für die Ionisationsreaktionen in der Massenspektroskopie notwendig (siehe Erzeugung mehrerer Reaktionen aus einer Reaktionssubstruktur auf Seite 97).

6.12.3.2. Eigenschaften

Die Funktionen zur Abfrage von Eigenschaften bilden eine übersichtliche Schnittstelle, bei der leicht neue Eigenschaften hinzugefügt werden können. Sie wird deshalb auch für alle Zugriffe auf die Datenstruktur RICOS herangezogen. Bedingt durch die Umsetzung der Zeiger der Datenstruktur auf Indizes gliedern sich die Eigenschaften in zwei Gruppen: diejenigen Eigenschaften, die von der Regelschnittstelle erzeugt werden, und jene, die die Datenstruktur zur Verfügung stellt. Auf Seiten der Regeln ist von dieser Aufspaltung nichts festzustellen.

Zu den Eigenschaften der Schnittstelle gehören all diejenigen, die Indizes auf Teile der Struktur liefern. RICOS stellt die Nachbaratome eines Atoms beispielweise als Liste bereit, die die Zeiger auf die Nachbaratome beinhaltet. Die Eigenschaft A_NEIGHBORS holt sich die Zeiger auf die Nachbaratome aus der Liste, bestimmt die Indizes der Regelschnittstelle und gibt sie den Regeln als Vektor mit diesen Indizes zurück. Eigenschaften dieser Art gibt es eine ganze Reihe. Es gehören dazu die Nummern des Aggregates und Moleküls, zu dem ein Atom gehört, die Elektronensysteme, an denen ein Atom beteiligt ist, und umgekehrt die Atome, die sich an einem Elektronensystem beteiligen usw.. Daneben gibt es auch noch Eigenschaften des Ensembles, wie viele Atome, Elektronensysteme usw. in diesem Ensemble sind und welcher der höchste Index ist, sowie eine Eigenschaft, die sagt, ob das Elektronensystem mit diesem Index existiert oder nicht (siehe 6.12.3.1). Aber auch das Lesen und Setzen des Zentralatoms eines -Elektronensystems mit Zentrum ist als setzbare Eigenschaft implementiert. RICOS hat hierfür spezielle Funktionen, auf die diese Eigenschaft zugreift. Historisch bedingt, sind auch noch einige weitere Eigenschaften Teil der Regelschnittstelle (siehe Produktfunktion auf Seite 245).

Neben den Eigenschaften der Regelschnittstelle stellt RICOS den überwiegenden Teil der Eigenschaften bereit. Zu diesen gehören die physikochemischen Eigenschaften, topologische Deskriptoren und auch die setzbaren, genealogischen Variablen, die zur Steuerung des Aufbaus des Reaktionsnetzwerks verwendet werden können (siehe 5.1.7). RICOS kennt eine Vielzahl von verschiedenen Datentypen, die in der Regelschnittstelle zur Vereinfachung auf sechs Typen reduziert werden. So werden Fließkommazahlen mit hoher und niedriger Genauigkeit beide als Fließkommazahlen-Eigenschaften mit hoher Genauigkeit den Regeln bekannt gegeben und weitergereicht. Die sechs Datentypen, auf die alle RICOS-Datentypen abgebildet werden, sind: int, double, vector<int>, vector<double>, e_bit64 und const char*.

6.12.3.3. Umordnung der Elektronensysteme (Reaktionen)

Die Umordnung der Elektronensysteme, also die Durchführung der Reaktionen, ist eine Modifikation der chemischen Datenstruktur RICOS. Für einen Reaktionsteilschritt werden nicht immer alle Änderungen an der Datenstruktur durchgeführt, die mit dem Teilschritt einhergehen. Dies liegt einerseits an der Geschwindigkeit der Abarbeitung, aber auch daran, daß manchmal erst nach einem weiteren Teilschritt klar wird, was passieren soll. Man denke hierbei an einen einfachen Bruch eines aromatischen Rings. Erst durch die Spaltung des Rings an einer zweiten Stelle bzw. des darunterliegenden

-Systems wird klar, was gemacht wird. Deshalb erfolgen die Veränderungen von RICOS über eine eigene Klasse namens ds_modify, die sich die noch auszuführenden Aktionen auf der Datenstruktur gegebenenfalls merkt und dann bei der abschließenden Bereinigung durchführt. Dieses Cleanup wird vom Reaktionsgenerator aufgerufen, wenn ein Abschnitt von Reaktionsteilschritten beendet ist und Eigenschaften der Produkte abgefragt werden bzw. die Reaktion im ganzen beendet ist.

Was genau mit den intern gespeicherten Zeigern usw. in RICOS für die Kombination oder die Spaltung eines Elektronensystems geschehen muß, kennen die Elementfunktionen der Klasse ds_modify. Die Schnittstelle wurde in dieser Weise definiert, damit die Datenabstraktion gewahrt ist und der Reaktionsgenerator nichts darüber wissen muß, wie die Elektronensysteme in RICOS implementiert sind. Er kennt nur ihre Typen, was man mit ihnen machen kann, und kann die Zahl der Elektronen im System ermitteln, ändern sowie abfragen, welche Atome an ihm beteiligt sind. All dies geschieht mittels Zugriffsfunktionen.

Was mit welchem Elektronensystem zu geschehen hat, wird dagegen vom Reaktionsgenerator entschieden. Bei der MO-orientierten Reaktionsgenerierung gehören hierzu die Überprüfung der Situation und gegebenenfalls die vorherige Aufhebung von Konjugationen. Soll beispielsweise eine 2-Zentren-2-Elektronenbindung gebildet werden, benötigt man eigentlich zwei einzelne Orbitale (kodiert als -Systeme an nur einem Atom) mit zusammen zwei Elektronen. Hat man dem Reaktionsgenerator dagegen größere -Systeme angegeben, müssen diese zunächst gespalten werden. Daneben wird hier auch verhindert, daß verdrillte Strukturen oder unmögliche Elektronenkonfigurationen erzeugt werden, wie es in 6.6.1.3 beschrieben ist.

Für die eingebaute Valence-Bond-Emulation, also der Behandlung der Datenstruktur RICOS als würde es sich um eine Bindungsliste handeln, ist wesentlich mehr erforderlich. Zunächst müssen für einen Bindungsbruch alle Elektronensysteme zwischen den beiden Atomen gefunden werden. Danach wird entschieden, ob es sich bei einem -System nur um die Konjugation zweier Doppelbindungen bzw. einer Doppelbindung mit einem freien Elektronenpaar usw. handelt. In solche Fällen wird zunächst die Konjugation aufgehoben und dann wieder ein Elektronensystem zum Spalten gesucht. Für die Erhöhung der Bindungsordnung werden mögliche -Systeme gesucht, wobei bevorzugt kleine, radikalische verwendet werden. Eine besondere Behandlung erfahren aromatische Systeme, bei denen ein einfacher Bruch dennoch als Bindungsbruch angesehen wird. Würde dies nicht auf diese Weise durchgeführt, würde bei einer Erniedrigung der Bindungsordnung um eins im Ring eines Aromaten sowohl das cyclische -System als auch die darunterliegende -Bindung gespalten. Eine Reaktion am aromatischen System wäre also unmöglich, da ein Aromat grundsätzlich ganz aufgespalten würde.

All dies wird von den entsprechenden Elementfunktionen der Klasse rx_dsifc unter Zuhilfenahme der Klasse rx_dsvb durchgeführt. Der Name rx_dsvb stammt vom Zugriff auf die Datenstruktur für die Valence-Bond-Emulation (Bindungslisten). Inzwischen hilft die Klasse aber auch bei der MO-orientierten Reaktionsgenerierung.

robert(at)robert-hoellering.de