Entwicklung des Model Interchange Formats

Kapitel 2: Die MIFoGenese

Die Entwicklung es Model Interchange Formats (MIF) begann im April 1994. Schon damals war die Idealvorstellung von einem Austauschformat, daß es vom Verwalten der Substanzdatenparameter bis zur Risikoabschätzung verwendbar sein sollte (Beim Projektvortrag wurde an dieser Stelle eine Orginalzeichnung von Herrn Matthies präsentiert.).

2.1: [Phase 1] Planung

2.1.1: Entwicklung der Anforderungen

Erste Anforderungen an das MIF:

Rechnersystem unabhängig, les- und editierbar -> also ASCII Format
erweiterbar
mehrsprachig
einfach umformatierbar
objektorientiert weiterverarbeitbar

Neben diesen recht allgemeinen Anforderungen, muß sich das MIF speziell für die zu lösenden Aufgaben eignen.

Welche Aufgaben sind eigentlich im Bereich von Implementationen von Expositionsmodellen von einem Austauschformat zu übernehmen?

Die nächste Abbildung zeigt, welche Daten fließen, wenn ein Datensatz zu einer Substanz mit Hilfe einer Abschätzfunktion ergänzt wird. Zum Beispiel könnte das Molgewicht der Substanz aus der schon bekannten Summenformel, unter zu Hilfenahme eines Periodensystems, errechnet werden. Nach Einsatz eines Programms, welches die Abschätzung durchführt, werden die ursprünglichen Daten an verschiedenen Stellen ergänzt.

Falls Eingabe und Ausgabe über Dateien erfolgt, ist es eine gute Idee, wenn die Resultatdatei wieder dem gleichen Format entspricht. Verschiedene Abschätzungen können so hintereinander durchgeführt werden.

Kommen wir nun zu dem Durchführen einer Modellrechnung. Eingangsdaten sind eine oder mehrere Substanzen und die Modellparameter.

Das Ergebnis enthält ebenfalls alle Eingangsdaten, sowie die Modellergebnisse. Dabei kann es sein, daß wiederum interne Abschätzfunktionen verwendet wurden.

Schwierig ist an dieser Stelle natürlich die Abgrenzung zwischen Modellparametern und Eigenschaften der Substanzen. Auch eine genaue Trennung von Modellen und Abschätzfunktionen ist so nicht möglich (Das Vorgehen bei CemoS wird kurz in der dortigen MIFDOK.TXT erklärt. ).

Die Resultatdaten eines Modellaufes gehören in natürlicher Weise zu den jeweiligen Parametern. Es ist ja durchaus möglich, mehrere Modelle oder mehrmals Modelle mit anderen Parametern laufen zu lassen. Dies kann auch für ein Ergebnis wichtig sein, wie zum Beispiel bei einer Sensitivitätsanalyse.

Die letzte Grafik stellt dar, wie verschiedene Eingangsdaten genutzt werden, um ein Gesamtergebnis zu erstellen. Als Beispiel dient eine Risikoabschätzung.

Das Endergebnis mit allen Zwischenergebnissen sollte anhand einer Resultatdatei nachvollziehbar sein.

Unser Austauschformat muß also die jeweiligen Eingangs- und Ausgangsdaten speichern können. Bei der obigen Darstellung sind schon einige Schwerpunkte gesetzt. Die Gruppierung der Daten erfolgt nach bestimmten Abschnitten, die Zusammengehörigkeit anzeigen. Weiterhin führt der Wunsch nach einem transparentem Resultat dazu, daß alle Eingangsdaten behalten werden müssen.

Der Einsatz verschiedener Programme führt uns zu weiteren Anforderungen:

Das Format sollte so erweiterbar sein, daß andere Programme mit der Erweiterung zurecht kommen.
Unempfindlichkeit gegenüber verschiedenen Rechengenauigkeiten, Zahlen- und Zeichenkodierungen
Die Abhängigkeiten der Ergebnisse von Eingangsdaten und verschiedenen Erzeugungsprogrammen sollten gespeichert werden.

2.1.2: Design des Formats

Wie sollte ein neues Format also aussehen?

Schon die Forderung nach Lesbarkeit brachte mich auf die Idee ein Textformat zu wählen. Technischen Inkompatibilitäten verschiedener Rechner und Programme bei binären Formaten wurde auf diese Weise gleich ausgewichen. Textdateien lassen sich für jedes Computersystem zumindest umwandeln und bei Zahlen, die als String gespeichert werden, gibt es erstmal keine Beschränkungen.

Um das Format leicht weiterverarbeiten zu können und es für einen Menschen leicht lesbar zu lassen, enthält jede Zeile eine Einrückung und ein Schlüsselwort. Als Trennzeichen zwischen Teilen einer Zeile wählte ich das Semikolon. In der selben Tiefe eingerückte Zeilen beziehen sich jeweils auf die letzte, um eine Stufe weniger eingerückte Zeile.

Gemäß den Anforderungen ergaben sich drei verschiedene Abschnittypen für das MIF, für die Schlüsselworte erfunden wurden:

Substanz:
Eingeleitet durch eine Zeile mit dem Schlüsselwort substdat enthält ein solcher Abschnitt die Eigenschaften einer Substanz. Solche Zeilen beginnen mit substdatchar.
Modellauf:
Enthalten sind hier die Modellparameter, Ergebnisse und Hinweise des Modellaufes eines Modells, mit einem Zeitstempel versehen Zugehörige Schlüsselworte sind modelpara, modelinputtable, modelresult und modelhint.
Projekt:
Hierunter sind eigentlich verschiedene Abschnitte zu verstehen, die bis auf projectresult jedoch nur einmal auftauchen dürfen. Die entsprechenden Schlüsselworte sind project, projectresult , projecthint und projectconclusion.

Nach den Schlüsselworten folgen auf der Zeile die verschiedenen Daten. Beispielsweise bei substdat ist das der Substanzname und bei substdatchar die Bezeichnung der Eigenschaft, der Status, der Wert und die Einheit.

Die bis jetzt genannten Schlüsselworte kommen alle ohne Einrückung aus. So wird ermöglicht, auch nur einzelne Daten, wie z.B. nur eine Eigenschaft einer Substanz, via MIF auszutauschen.

Die eingrückten Zeilen sollen die gewünschte Funktionalität erbringen. Kommentare und Abhängigkeiten an fast jeder Stelle. Weiterhin Tabellen, Bilanzen und Texte.

Betrachen wir ein paar Beispiele:

Hier ein einfaches Beispiel für eine MIF-Datei, die nur aus einem Substanzdatenabschnitt besteht. Es wird die Substanz Formaldehyde mit drei Eigenschaften gezeigt. Diese sind jeweils bekannt (=^ known). Die Summenformel besteht aus einem Stringwert ohne Einheit und der Schmelzpunkt(mp, von melting point) sowie der Siedepunkt(bp, von boiling point) sind Zahlen in der Einheit Kelvin. substdat;Formaldehyde substdatchar;sumformular;known;CH2O;- substdatchar;mp;known;181.15;K substdatchar;bp;known;253.15;K
Nun ein paar Kommentar- und Abhängigkeitszeilen. Wir nehmen an, daß Schelz- und Siedepunkt aus der Summenformel bestimmt wurden. (z.B. mit Hilfe eines Programmes mit Namen bestimme.) Zu den Abhängigkeiten ist ebenfalls erklärender Text möglich. substdat;Formaldehyde c;wird im Deutschen auch Formalin genannt c; -- B. Reiter 8.9.1995 substdatchar;sumformular;known;CH2O;- c; (hier könnte ein Kommentar zur Summenformel stehen) c; (natürlich mehrere Zeilen lang und mit Semikolons ; ) c; (ist alles Freitext nach dem >>c;<<) substdatchar;mp;known;181.15;K c;entnommen der Datenbank >xy.dat< d;sumformular c; bestimmt mit Hilfe von >>bestimme<< v1.3 substdatchar;bp;known;253.15;K c; bei 20 Grad Celsius gasförmig c;entnommen der Datenbank >xy.dat< d;sumformular c; bestimmt mit Hilfe von >>bestimme<< v1.3
Als letztes ein Beispiel mit einem Modellabschnitt. Es stammt aus den Lösungen der Übungen aus dem Lehrbuch zu CemoS. Der Substanzdatenabschnitt ist gekürzt.
substdat;Benzene c;Trapp 7/96 substdatchar;CAS;unknown;;- substdatchar;sumformular;known;C6H6;- substdatchar;MW;known; 7.81136400000000E+0001;g/mol c;estimated Trapp 9/93 d;sumformular c;estmolar_mass substdatchar;K_AW;known; 2.30000000000000E-0001;- c;measured at 25 degree C; from Rippen 1993 c;Trapp 9/93 [...] model;Air;07-17-1996;11:23:21 c;Default data. d;;Benzene modelpara;inhal_rate;known; 2.00000000000000E+0001;m^3/d modelpara;input;known; 5.12300000000000E-0001;kg/d c;[kg/d] ~= 187 [kg/a] / 365 [d/a] modelpara;f_p_plant;known; 2.52475246887315E-0009;- d;VP;Benzene c;estf_p modelpara;rain;known; 2.10000000000000E+0000;mm/d modelpara;v_Wind;known; 0.00000000000000E+0000;m/s modelpara;v_dep_dry_gas;known; 9.79867139963729E-0003;m/s d;MW;Benzene c;estV_d_gas modelpara;v_dep_dry_par;known; 1.00000000000000E-0002;m/s modelpara;x_0;known; 1.00000000000000E+0003;m modelpara;y_0;known; 1.00000000000000E+0003;m modelpara;z_0;known; 5.00000000000000E+0002;m modelresult;GenResults value;C_0_air;known; 5.88604077833300E-0010;kg/m^3 value;dep_total_air;known; 1.81887038400283E-0004;kg/m^2a value;inhalDose_air;known; 4.29680976818309E-0006;kg/a cake;Massbalance;kg/a cakeseq;mass_dry_part_air; 4.68650062245536E-0007 cakeseq;mass_wet_part_air; 2.27816002480469E-0007 cakeseq;mass_dry_gas_air; 1.81885076116753E+0002 cakeseq;mass_wet_gas_air; 1.96158706313106E-0003 cakeseq;mass_reduction_air; 5.10246159971742E+0000 cakeseq;mass_advection_air; 0.00000000000000E+0000

Dies letzte Beispiel soll einen Eindruck von der Syntax des Formates geben. Für eine genauere Beschreibung, siehe ebenfalls die Datei MIFDOK.TXT in der CemoS Distribution. An dieser Stelle ist nicht genug Raum für die Vorstellung der Feinheiten.

Anhand des letzten Beispiels ist nochmals zu erkennen, daß mensch sich meist nicht für alle Daten, die einem Programm bekannt sind in voller Genauigkeit interessiert. Später, wenn ein Wert unklar ist und genau nachvollzogen werden soll, ist dies aber von größter Bedeutung.

Im nächsten Kapitel wird die Implemtation eine Compilers beschrieben, mit dem die Daten einer MIF-Datei so extrahiert werden können wie gerade nötig.

Was tut mensch nach dem Erstellen einer Formatspezifikation?

Er entwickelt die Formatdefinition. Dazu wurden mehrmals Ausgabedateien im MIF "per Hand" geschrieben und ein Referenzerkenner entwickelt. Dies ist ein iterativer Prozeß; die Formatdefinition und der Referenzerkenner verbessern sich dabei gegenseitig. Die oben präsentierten Beispiele entsprechen schon dem Ergebnis (Neben der offensichtlich didaktischen Schwäche, wäre es für mich sowieso nicht möglich die Entwicklung von der Rohform des MIF an zu beschreiben.).

2.2: [Phase 2] Implementation des Compilers

Ein Referenzcompiler zum MIF mußte her. Einmal, um die Syntax (und einen Teil der Semantik) automatisch überprüfen zu können. Aber am wichtigsten ist es den Inhalt einer MIF-Datei in verschiedene Formen zu bringen. Zum Beispiel zum Ausdrucken und Lesen durch Menschen oder für das Plotten von Wertetabellen. Dabei werden die ursprünglich vollständigen Informationen in der MIF-Datei meist reduziert.

Also begann ich mit der Implementation dieses Compilers in der vorlesungsfreien Zeit des Sommersemesters 1994.

Aus folgenden Überlegungen heraus entschied ich mich die Programmiersprache AWK zu verwenden.

Die Umwandelungen der Daten in einer MIF-Datei erfordern oft Rechnungen (Beispiel: Das Umwandeln von Werten in andere Einheiten). In meiner Vorstellung sollte sich die Ausgabe in AWK realisieren lassen, nachdem ein vorgefertigter AWK-Teil das Einlesen und Prüfen der Daten übernimmt.
In AWK lassen sich String relativ leicht manipulieren. Sehr genaue Zahlen können notfalls als Strings verarbeitet werden. AWK kennt nur assoziative Felder, die als Indizes Strings verwenden. Dies sollte zu einem einfachen Abrufschema der eingelesenen Daten führen.
Die Programmiersprache AWK ist eine Interpretersprache, die in freien Implementationen auf praktisch allen Rechnerplattformen gleich funktioniert. Zudem ist für die Entwicklung eines AWK-Programmes nur der Interpreter nötig und keine Bibliotheken, Hilfsprogramme, usw.

Ich begab mich auf die Suche nach einer AWK Implemenation, um einer frühen Designentscheidung in der CemoS Entwicklung Rechnung zu tragen. CemoS sollte ohne erweiterten Speicher selbst auf einem XT laufen. Fündig wurde ich mit Mike Brennans AWK (Der mawk erwies sich sogar als schneller als die damaligen gawks.), genannt MAWK, Version 1.14. Er mußte mehrmals recompiliert werden, um die Datensektion an die Größe des MIF Compilers anzupassen.

Entwickelt habe ich unter UN*X. Der original MIF-Compiler erhielt den Namen scan.awk. Der Quellcode wurde mit Hilfe des Revision Control Systems(RCS) verwaltet. Dieses System speichert alle vorgenommenen Änderungen und ermöglicht es alte Versionen wiederherzustellen. Bei Softwareentwicklungen im Team empfehle ich ein solches Werkzeug dringenst.

Hier nun ein Ausschnitt aus dem Log, anhand welchem sich die Entwicklung ablesen läßt:

Mit Erreichen von Version 1.23 am 6.2.1995 war scan.awk recht stabil. Version 1.25 vom 4.19.1995 wurde mit CemoS 1.0 "released".

Im Laufe der Zeit entwickelte ich eine Anzahl von Testskripten, die nach einer Änderung an scan.awk einige Standardfunktionalitäten überprüfen.

Als der Parser implementiert war, gab es nur eine rudimentäre Ausgabe. Diese war zwar vollständig, aber recht schlecht zu programmieren. Entgegen meiner Zielvorstellung, daß das Speichern in einem assoziativen Feld die Dinge einfach zu Programmieren mache, mußten jetzt zusätzlich Ausgabefunktionen implementiert werden. Später erkannte ich einen weiteren Nachteil. Wenn in einem assoziativen Feld Strings als Indizies verwendet werden, dann bedeutet Abrufen eines Wertes und Durchgehen des Feldes jedesmal das Suchen nach einem String, was intern wohl mit einer Hashtabelle realisiert wird. Dies ist selbstverständlich ein arger Anschlag auf Ablaufgeschwindigkeit bei großen Eingabedateien (bevor die Abarbeitung aber zu langsam wird, stößt mensch bei kleinen PCs zuerst an die Grenzen des geringen Hauptspeichers von 640KByte).

Mit Hilfe der Ausgabefunktionen ist es, gemessen an der Komplexität, relativ komfortabel eine neue Ausgabe der Daten im MIF-Format zu programmieren. Dabei wird der Standardausgabeteil von scan.awk einfach durch einen neuen ersetzt.

Hier ein schon etwas komplizierteres Beispiel, welches alle Substanzdatenabschnitte durchgeht. Jeweils alle Eigenschaften ansieht und die mit Namen mp, für Schmelzpunkt, umrechnet. Wenn also eine Zeile für eine Substanz einen Schmelzpunkt mit Einheit Kelvin hat, wird dieser in Grad Celsius umgerechnet und ausgegeben. Neben den Substanznamen und den umgerechneten Werten wird sonst nichts ausgeben.

Anzahl_der_Substanzabschnitte = allsections( Art, Substanz, SUBSTDAT_I ); for ( t=1 ; t<=Anzahl_der_Substanzabschnitte; t++ ) { print "Substanz: " Substanz[t]; setactivesubstdat( Substanz[t] ); Anzahl_Eigenschaften=allsubstdatchars( Eigenschaft ); for( i=1; i<=Anzahl_Eigenschaften; i++) { # (nicht elegant, aber einfach) if ( Eigenschaft[i] == "mp" ) { getsubstdatchar(Datum, Anzahl, Kommentar, Abhaengigkeit, "mp" ); # nur ausgeben und umrechnen, falls Schmelzpunkt # auch einen Wert hat also "known" ist # und in Kelvin ("K") angegeben ist if( Datum[I_STATUS] == "known" && Datum[I_UNIT] == "K") { print "Schmelzpunkt: " Datum[I_VALUE]-273.15 " Grad Celsius " } } } } Durch die Schleifen und Abfragen werden die gesamten Möglichkeiten des MIF verfügbar. Für das Schreiben eines neuen Ausgabeabschnittes sind auch Funktionsdefinitionen und damit eine flexible Programmierung möglich. In den Ausgabeteilen zu CemoS werden zum Beispiel Tabellen relativ aufwendig für eine Ausgabe auf einem Textbildschirm aufbereitet.

Vor der letztendlichen Fertigstellung des Compilers begann schon die Verbindung von MIF und CemoS, welche im nächsten Kapitel beschrieben wird.

2.3: [Phase 3] Anpassung an CemoS

Dieser Abschnitt beschreibt die Konzepte und Implementationen der Anpassung des MIF an CemoS. Ich werde hierbei nicht chronologisch aus der Sicht des MIF vorgehen.

Das Importieren und Exportieren in CemoS wurde hauptsächlich von Jan-Oliver Wagner und Guido Baumgarten implementiert. Es wurde auch ein Konvertierungsprogramm für Substanzdatendateien von CemoS und MIF Dateien programmiert.

2.3.1: Mehrsprachigkeit und Standardnamen

Damit eine MIF Datei über Sprachbarrieren hinaus verständlich bleibt, wurde ein Konzept für die verschiedenen Bezeichner eingeführt. Jeder Name der automatisch verarbeitet werden soll, wird sozusagen normiert. Das heißt er ist eine feststehende Abkürzung, ein Standardname.

Durch Nachsehen in einer Tabelle, kann eine textuelle Beschreibung jedes Standardnamen gefunden und angezeigt werden. Wenn die Tabelle verschiedene Sprachen enthält, sogar mehrsprachig. Für die Verarbeitungsskripte bleibt die Bezeichnung konstant.

Die Tabelle, in der die Standardnamen definiert werden, nennt sich Standardnamendatei (stdnames.sn). Das Format dieser Datei wurde von Jan-Oliver Wagner definiert und mit einem Referezscanner versehen(siehe 3.0.1.2).

Hier ein kurzer Ausschnitt, aus stdnames.sn welche mit CemoS(v1.04) erhältlich ist:

Format CemoS english deutsch mp vaSubstanceMP,sbs Melting Point Schmelzpunkt estBCF_Isnard_ws vaBCF_Isnard_ws,mod Estimation by Isnard from water solubility Abschätzung nach Isnard aus Wasserlöslichkeit Der Format Abschnitt beschreibt, die Bedeutung der Zeilen. Die erste wird für interne Zwecke von CemoS verwendet, die anderen beiden sind die deutsche und englische Übersetzung (Für die spätere Funkionalität ist die erste Zeile ohne Bedeutung und könnte weggelassen werden). Zu sehen ist ein Standardname f"ur den Schmelzpunkt und für eine Abschätzfunktion. Die Standardnamen, sollten allgemein in Absprache mit dem CemoS-Team gewählt werden, damit eine Kompatibilität zwischen sehr unterschiedlichen Programmen erhalten bleibt.

Die AWK-Scripte für die Ausgabe, welche auf dem Compiler scan.awk aufbauen, lesen also eine Standardnamendatei.

2.3.2: Ausgabeteile

Wie werden denn nun die verschiedenen Bearbeitungen mit Hilfe des Compilers durchgeführt?

Das AWK-Programm scan.awk, enthält Markierungen an Stellen, wo Teile vom Benutzer ausgetauscht werden können. Dies jeweils von Hand zu machen ist etwas zu mühsam; doinsert.bat übernimmt speziell unter M$DOS diese Aufgabe und erstellt eine Datei mit den neuen Teilen eingepflanzt scan.awk.

Anhand der folgenden Skizze läßt sich nun die Steuerung der MIF-Verarbeitung nachvollziehen:

Für die verschiedenen Aufgaben bei CemoS entwickelte ich also Ausgabeteile. Die eine Art der Ausgabeteile, enthält eine Tabelle der Standardnamen, die CemoS pro Modell ausgeben wird. Mit diesem Wissen wird die Ausgabe nach Reihenfolge der Bildschirmausgabe von CemoS formatiert. Die zweite Art glaubt an MIF-Dateien, die denen von CemoS ähnlich sind, versucht jedoch alle Standardnamen die zu finden sind auszugeben. Weiterhin gibt es einen Ausgabenteil, der sich mit der Tabellenformatierung befaßt.

cemos.awk, cemos_u.awk und c_tables.awk sind die wichtigsten AWK-Skripte für CemoS MIF-Verarbeitung und werden bereits fertig mitgeliefert. Diese Verstehen eine umfangreiche Menge von Optionen. Es waren mehrere Möglichkeiten im Gespräch die Bedienung hier freundlicher zu machen. Ein Aufruf der AWK-Skripte aus CemoS heraus scheiterte an Schwierigkeiten mit dem Betriebssytem M$DOS. Ein zusätzliches grafisches Benutzerinterface ist mit einem hohen Aufwand verbunden. Also wurden Kommandozeilenskripte geschrieben.

2.3.3: DOS-Batch Dateien

Die Möglichkeiten der DOS-Batch Sprache sind begrenzt. Mit etwas Aufwand wurden circa dreizehn Batch-Dateien für die Bedienung der MIF-Verarbeitung für CemoS implementiert.

Schwierigkeiten mit dem Kommandointerpreter COMMAND.COM, die es zu Überwinden galt:

Das Umleiten der Ausgabe von Batch-Dateien ist nicht möglich.
Lösung:Zwei Varianten: eine für Ausgabe in more, die andere für Umleitung in eine Datei.
Kommandozeilen sind in der Länge begrenzt, weswegen nicht genug Informationen an das Skript weitergegeben werden können.
Lösung:Wo nötig den Umgebungsspeicher verwenden.
Der Benutzer kann nicht ausreichend interaktiv befragt werden.
Lösung:Mehr Kommandoparameter schaffen.

Hier eine knappe Tabelle der Batch-Dateien, welche as dem CemoS-Handbuch stammt:

Aufstellung der Weiterverarbeitungs-Skripte =========================================== Kommando Beschreibung LIST mif Zeigt die in der MIF-Datei mif enthaltenen Tabellen an. LISTF mif ausgabe Schreibt das Ergebnis von LIST in die Datei ausgabe. L_SELECT [def] sprache Setzt die angegebene Sprache; entweder als aktuelle, oder (mit def) als Standardsprache. PLOT mif [X Y1 [...]] Die in der MIF-Datei mif zuerst gefundene Tabelle wird über gnuplot auf dem Bildschirm dargestellt. gnuplot muß also installiert sein. X bezeichnet die Nummer der Spalte für die X-Achse, Y1 bis maximal Y6 bezeichnen die auf die Y-Achse aufzutragenden Spalten. Werden X und Y nicht definiert, so ist X=1 und alle übrigen Spalten entsprechen Y1, Y2 usw. PLOTF mif [X Y1 [...]] ausgabe Schreibt das Bild, welches über PLOT erzeugt wurde, im Postscript-Format in die Datei ausgabe. TABLE [tab] mif Zeigt die Tabelle mit der Bezeichnung tab mit allen Kommentaren und mit einem Leerzeichen als Spaltentrenner an. Den Kommentaren ist ein Lattenzaun (#) vorangestellt. Wird tab nicht angegeben, so wird die erste gefundene ausgegeben. TABLEF [tab] mif ausgabe Schreibt die Ausgabe von TABLE in die Datei ausgabe. RAW [tab] mif Arbeitet wie TABLE, nur das alle Kommentar weggelassen werden. RAWF [tab] mif ausgabe Schreibt die Ausgabe von RAW in die Datei ausgabe. REPORT mif Erstellt einen vollständigen, deutschen Report der in der MIF-Datei mif beschriebenen Modellrechnung. REPORTF mif ausgabe Schreibt die Ausgabe von REPORT in die Datei ausgabe. UREPORT mif Erstellt ähnlich wie REPORT einen Report der in der MIF-Datei mif vorliegenden Daten. Allerdings ist hier keine bestimmte inhaltliche Zusammensetzung, wie z.B. die von CemoS, vorausgesetzt. Es können also Reports beliebiger, das MIF einhaltende, Dateien erstellt werden. UREPORTF mif ausgabe Schreibt die Ausgabe von UREPORT in die Datei ausgabe.

Die Sprache wird mit Hilfe einer Umgebungsvariable und einer Konfigurationsdatei eingestellt. Die Texte sind in Deutsch und Englisch in jeder Batch-Datei vorhanden.

Zum Abschluß dieses Kapitels ein Bild, welches mit plotf.bat und gnuplot erzeugt wurde, da mir die im Projektkolloqium gezeigten Textausgaben an dieser Stelle zu umfangreich erscheinen. Die Grafik wurde mit dem Befehl plotf ex8_2.mif 1 2 3 plot.eps direkt als Postscriptdatei erzeugt.