zurück  weiter

3.1.2 Was das Programm kann

zurück  weiter

3.1.3 Was das Programm nicht kann

zurück  weiter

3.1.4 "Programmphilosophie"

Im Rahmen des BMWi-geförderten Projekts HYDROS [3], [22] in dem ein hydrostatisch-hydrodynamisches Hybridlager entwickelt wurde, wurde das Programm SIRIUS grundlegend überarbeitet und erweitert. Bei dieser Überarbeitung wurden folgende Ziele angestrebt: Das Programm sollte kein Ein-Zweck-Programm werden, sondern auch nach dem Projekt weiterhin für andere Anwendungsfälle geeignet sein, sowohl für wissenschaftliche Untersuchungen als auch für ingenieurtechnische Anwendungen. Trotz seiner wachsenden Komplexität soll es anwenderfreundlich sein. Es soll weiterentwicklungsfähig und für die Integration spezieller Anwendungen offen sein. Dabei mussten Kompromisse gefunden werden zwischen einer maximalen Erfüllung der oben benannten Ziele und der begrenzten verfügbaren Entwicklungskapazität. Die gewonnenen und eingearbeiteten Erkenntnisse sollen der wissenschaftlich und technisch interessierten Öffentlichkeit zur Verfügung gestellt werden und so einen Betrag zum Fortschritt in der hydrodynamischen Schmiertheorie leisten.

Daraus ergibt sich eine Programmphilosophie, die in den nachfolgenden Unterabschnitten dargestellt ist.

zurück  weiter

3.1.4.1 Breites Anwendungsspektrum

Die realisierte Breite des Anwendungsspektrums ist im Abschnitt 3.1.2 bereits aufgelistet.

zurück  weiter

3.1.4.2 Anwenderfreundlichkeit

Zum einfachen ersten Einstieg in das Programm werden die Daten für ein einfaches Demonstrationsbeispiel mit dem Start des Programms automatisch aufgerufen, so dass der neue Nutzer ohne weitere Dateneingabe eine erste Berechnung ausführen kann und so einen ersten Einblick in die Arbeitsweise erhält (siehe Schnelleinstieg Abschnitt 1.4). Dabei werden mit dem Start des Programms auch alle anderen potentiellen Eingabedaten mit einem Anfangswert belegt. Dieser Anfangszustand des Programms kann jederzeit wieder hergestellt werden.

Der Nutzer wird in einer linearen Abfolge von Eingabemenüs durch das Programm geführt, so dass am Ende eine vollständige Dateneingabe gewährleistet ist. Dabei unterliegt die Reihenfolge der Dateneingabe einer gewissen Hierarchie. So bestimmen die ersten Eingaben, welche nachfolgenden Eingaben noch erforderlich sind. Diese Führung durch das Programm ist aber kein Zwangsweg in eine Richtung. Es kann von fast jedem Punkt zurückgesprungen werden, um vorhergehende Eingaben zu korrigieren.

Aus der Vielzahl der im Programm vorgehaltenen Eingabemöglichkeiten werden nur die abgefragt, die für den gewählten Fall relevant sind. Es werden Angaben zum Definitionsbereich der Eingabedaten gemacht. Während der Eingabe erfolgt eine Plausibilitätsprüfung der eingegebenen Daten. Bei Eingabefehlern erfolgt eine Fehlermeldung mit der Aufforderung zur erneuten Eingabe. An einigen Stellen werden Warnungen ausgegeben, wenn eine Fehleingabe vermutet werden kann, aber nicht zwingend ist. So lange die Eingabe eines Wertes nicht abgeschlossen ist, kann die Eingabe abgebrochen werden, ohne dass der bisherige Wert geändert wird.

Neben der Direkteingabe der Daten über die Tastatur kann die Eingabe großer Datenmengen, die in Feldern abgespeichert sind, auch über das Einlesen von Textdateien (ASCII-Dateien) organisiert werden. Damit ist eine Schnittstelle zu anderen Programmen gegeben. Diese Textdateien sind mit einfachen Editoren lesbar, so dass bei Fehlersuche der Datenfluss leicht kontrolliert werden kann.

Die primären Eingabe- und Ergebnisdaten werden gemeinsam in einer Textdatei gesichert und können zur späteren Auswertung oder erneuten Bearbeitung wieder eingelesen werden. Es können auch nur teilweise bearbeitete Eingabedatensätze oder nur teilweise erfolgte Berechnungen für eine spätere weitere Bearbeitung abgespeichert werden.

Für die Berechnung konkreter Lager und/oder für prinzipielle Untersuchungen kann zwischen einer dimensionsbehafteten und einer dimensionslosen Datenein- und -ausgabe gewählt werden. Die Definition der dimensionslosen Daten ist passend zur Definition der Sommerfeldzahl eingerichtet. Alle Daten werden mit den 5 Bezugsparametern Wellendurchmesser d, relative Lagerbreite B, relatives Lagerspiel S, dynamische Viskosität η und Bezugswinkelgeschwindigkeit ωb dimensionslos gemacht. Sofern die 5 Bezugsparameter eingegeben sind, kann während der Dateneingabe im PreProzessor und während der Auswertung der Ergebnisse im PostProzessor problemlos zwischen dimensionsloser und dimensionsbehafteter Darstellung gewechselt werden. Intern arbeitet das Programm ausschließlich mit den dimensionslosen Daten, was die Programmierung erleichtert.

Während des Projekts HYDROS wurden mit SIRIUS zur Lösung der eigentlichen Entwicklungsaufgabe des Projekts viele Berechnungen durch geführt und damit das Programm ausführlich getestet und praktische Erfahrungen für die Anwendung des Programms gesammelt. Aus diesen Erfahrungen resultiert eine große Anzahl kleiner Routinen im Hintergrund, die die Arbeit mit dem Programm erleichtern und beschleunigen.

Die alte Programmiersprache FORTRAN 77, mit ihrem überschaubaren Befehlssatz, wurde bei der Überarbeitung des Quelltextes beibehalten. Damit ist es möglich, kompakten schnellen Programmcode zu erzeugen. So kann das Programm weiterhin auf üblichen Personalcomputern ausgeführt werden und die Berechnungszeiten sind meist so kurz, dass im direkten Dialog eine Vielzahl von Varianten durchgerechnet werden können, so dass ein virtuelles Experimentieren bei der Suche nach optimalen Lösungen möglich ist.

Bei der Auslegung eines hydrodynamisch geschmierten Gleitlagers ist letztendlich für den Nachweis seiner Funktionsfähigkeit ausschlaggeben, wie groß die minimale Schmierspalthöhe im Vergleich zu den Rauhtiefen der Gleitflächen ist. Neben der Berechnung der Schmierspalthöhe wird im Programm SIRIUS aber Wert darauf gelegt, das möglichst viele weitere Daten ermittelt und sowohl numerisch als auch grafisch dargestellt werden können. Damit soll sowohl der wissenschaftlich als auch ingenieurmäßig arbeitende Nutzer des Programms umfassenden Einblick in das Geschehen im Lager erhalten, was ihm helfen soll, die Prozesse im Lager zu verstehen und so zu einer optimalen Lösung zu kommen. Für die Interpretation dieser Ergebnisse sollte der Anwender des Programms bereits einige grundlegende Kenntnisse der hydrodynamischen Schmiertheorie besitzen.

zurück  weiter

3.1.4.3 Entwicklungsfähigkeit

Das Programm wurde von Anfang an als ein Baukastensystem konzipiert, indem es konsequent nach funktionellen Gesichtspunkten in Routinen aufgeteilt ist. So konnten in der Vergangenheit von dem ursprünglichen Programm für verschiedene Aufgabenstellungen verschiedene Varianten abgeleitet werden. Im Rahmen der Programmüberarbeitung wurde ein Großteil dieser Varianten in der überarbeiteten Version vereinigt und weiterentwickelt, was die mögliche Variantenvielfalt weiter erhöht hat.

Zur Beherrschung der Variantenvielfalt wurde ein umfangreiches System von Steuerparametern entwickelt, durch welches die Beschreibung der jeweils gewählten Lagervariante codiert wird. Diese Steuerparameter steuern sowohl die Abfrage der relevanten Eingabedaten, die Konsistenzprüfung des Datensatzes als auch die eigentliche Berechnung. Dieses System ist erweiterbar, indem innerhalb der vorhandenen Steuerparameter weitere Varianten hinzugefügt werden können oder auch neue Steuerparameter für einen zusätzlichen Variantenblock ergänzt werden. Die Codierung dieser Steuerparameter ist in der Beschreibung des Hauptmenüs " Festlegungen zur Theorie, zum Berechnungsverlauf und zum Lagertyp " in der Bedienanleitung Abschnitt 4.4.2 dokumentiert.

Auch für die große Zahl von Daten, die die physikalisch-technischen Zustände im Lager abbilden, wurde ein umfangreiches Parametersystem entwickelt. Diese Parameter wurden nach funktionellen Gesichtspunkten auf mehrere Common-Blöcke aufgeteilt. Auf diese können die verschiedenen Routinen in der Regel direkt zugreifen. Die Nomenklatur dieser Parameter wird in allen Routinen einheitlich gehandhabt.

Die alte Programmiersprache FORTRAN 77, mit ihrem überschaubaren Befehlssatz, ist leicht erlernbar. Sie erfordert aber einen sauberen Programmierstil, da sie über relativ wenig Kontrollmechanismen verfügt.

zurück  weiter

3.1.4.4 Kompromiss

Aus den oben erwähnten Gründen wurde die Programmiersprache FORTRAN durchgängig für die gesamte Programmierung verwendet. FORTRAN kennt aber noch keine Befehle für grafische Ein- und Ausgaben. Deshalb musste auf eine grafische Programmoberfläche verzichtet werden. Die textbasierte Programmoberfläche erscheint in dem spröden Charme des altbekannten DOS-Fensters, was für die jüngeren Anwender sicher etwas gewöhnungsbedürftig ist. Damit fehlen zwar einige Gestaltungsmöglichkeiten für eine kontrastreiche Programmoberfläche mit diversen Eingabefenstern. Erstaunlicherweise sind aber auch mit FORTRAN alle wesentlichen Anforderungen für einen professionellen Dialog zwischen Anwender und Programm gegeben. Durch die Gestaltung der Textblöcke der verschiedenen Menüs konnten auch gewisse grafische Effekte erzeugt werden, die nach einer Einarbeitungszeit eine schnelle Orientierung auf der Programmoberfläche ermöglichen. Auf die grafische Darstellung der Ergebnisse braucht trotzdem nicht verzichtet werden. Das kann mit dem eigenständigen Programm GNUPLOT im Parallelbetrieb gut realisiert werden.

zurück  weiter

3.1.4.5 SIRIUS als wissenschaftliche Informationsquelle

Im Programm SIRIUS sind ein reicher Erfahrungsschatz zur Theorie der hydrodynamischen Schmierung und Methoden ihrer Berechnung eingeflossen. Damit dieser Erfahrungsschatz nicht verloren geht, soll auf eine Kommerzialisierung des Programms verzichtet werden. So entsteht nicht die Versuchung, fachliches und methodisches Know-how als kommerziell verwertbares Betriebsgeheimnis zurück zuhalten. Deshalb sollen mit dieser ausführlichen Dokumentation und der Veröffentlichung des gesamten kommentierten Quelltextes möglichst viele Details für die Nutzung und Weiterentwicklung der hydrodynamischen Schmiertheorie offengelegt werden. Die ausführliche Beschreibung der technisch-physikalischen Grundlagen im Abschnitt 2 der Dokumentation kann dementsprechend als umfangreiche Formelsammlung zur Problematik des hydrodynamischen Gleitlagers genutzt werden.

Indem das Programm nur kostenfreie Hilfsprogramme verwendet und das Programm selbst mit einer kostenlos nutzbaren GNU-Lizenz versehen ist, steht es auch allen Studierenden zur freien Verfügung, um sich anhand konkreter Beispiele mit der Schmiertheorie vertraut zu machen.

zurück  weiter

3.2 Übersicht über die Programmstruktur

zurück  weiter

3.2.1 Das Gesamtsystem der Berechnung, Datensicherung und -übertragung und der grafischen Ausgabe

Das eigentliche Programm SIRIUS besteht in seiner kompilierten Form lediglich aus der Datei "SIRIUS.exe", mit einer Dateigröße von ca. 1,5 MB. Das Programm ist in dieser Form ohne weitere Hilfsmittel auf einem Windows-Betriebssystem lauffähig und kann so, ohne sonstige weitere Vorbereitungen oder Installationen, getestet werden, um einen ersten Eindruck seiner Funktionsweise zu gewinnen.

Intern ist SIRIUS in die Funktionseinheiten PreProzessor, Solver und PostProzessor gegliedert. Der PreProzessor dient der Dateneingabe. Im Hintergrund erfolgt dabei eine Konsistenzprüfung der eingegebenen "primären" Eingabedaten und eine Komplettierung des Eingabedatensatzes durch weitere "sekundäre" Eingabedaten, die sich aus den primären Eingabedaten berechnen lassen. Im Solver erfolgt die zeitintensive Hauptrechnung, die die "primären" Ergebnisdaten liefert. Im PostProzessor erfolgt die Sicherung der primären Ergebnisdaten gemeinsam mit den primären Eingabedaten und die Berechnung weiterer "sekundärer" Ergebnisdaten zur numerischen und grafischen Anzeige und Auswertung der Ergebnisse.

Zur Nutzung seiner vollen Funktionalität benötigt SIRIUS noch einige Verzeichnisse, zur Sicherung der Berechnungsergebnisse und zur Kommunikation mit dem Grafikprogramm GNUPLOT und mit einem einfachen Filmschnittprogramm für die Erzeugung von Animationen. Als Filmschnittprogramm benutzte der Autor bisher das Programm Movie-Maker von Microsoft. In einigen weiteren Verzeichnissen sind diverse Hilfsdateien abgelegt, insbesondere zur Steuerung des Grafikprogramms GNUPLOT.

Falls auf den Quelltext zugegriffen werden soll, um das Programm an bestimmte Bedingungen anzupassen oder weiter zu entwickeln und anschließend zu kompilieren, wird ein FORTRAN-Compiler benötigt. Der Autor verwendet dafür den freien Compiler "GNU Fortran G77 for Win32" der aus dem Internet heruntergeladen und kostenlos genutzt werden kann.

Bild 3.01 zeigt die Grobstruktur des Programms SIRIUS und die erforderlichen Hilfsprogramme zur Erzeugung grafischer Darstellungen (graue Kästchen, schwarz umrandet). Die grün umrandeten gelben Kästchen zeigen die erforderlichen Verzeichnisse zur Datensicherung und zur Kommunikation der Programme untereinander. Die grünen Pfeile zeigen den Datenfluss. Die schwarzen Pfeile innerhalb des Programms SIRIUS zeigen die Möglichkeiten der Navigation innerhalb des Programms (Hauptdurchlaufrichtung: dicke Pfeile, Rücksprungmöglichkeiten: dünne Pfeile).

Bild 3.01: Grobstruktur des Programm SIRIUS einschließlich erforderlicher Umgebung

Das Programm GNUPLOT ist ein kostenlos nutzbares Programm und kann aus dem Internet geladen und installiert werden. Es muss mindestens die Version 4.6.3 geladen werden. Es ist nicht in das Programm SIRIUS integriert und muss als selbständiges Programm parallel dazu gestartet werden. Durch den automatisierten Zugriff beider Programme auf das Verzeichnis "Temp" ist eine zügige Datenübertragung gegeben, so dass man im Rahmen der Ergebnisauswertung mit beiden Programmen parallel arbeiten kann. Mit dem Filmschnittprogramm können dann aus einer Serie von Bildern, die GNUPLOT als PNG-Dateien im Verzeichnis Temp1 ablegt, Animationen erzeugt werden. Das verwendete Programm Movie-Maker ist bis Version Windows XP bereits im Betriebssystem enthalten. Für spätere Versionen des Windows-Betriebssystems kann es bei Microsoft kostenlos heruntergeladen werden. Es sind sicher auch einige andere einfache Filmschnittprogramme geeignet, da diese nur eine Reihe von Pixel-Grafiken zu einer fortlaufenden Animation zusammenfügen müssen.

Neben den im Bild 3.01 gezeigten Verzeichnissen zur Kommunikation der Programme untereinander und der Datensicherung sind weitere Verzeichnisse vorhanden mit diversen Dateien. Bild 3.02 zeigt die erforderliche Verzeichnisstruktur für die umfassende Nutzung des Programms.

Bild 3.02: Liste der Verzeichnisse für den Betrieb des Programms SIRIUS

In den Verzeichnissen "Animationen", "AnimationenDim", "Bilder" und "BilderDim" sind Dateien mit der Erweiterung ".plt" abgelegt, die Befehlssätze zur Steuerung des Programms GNUPLOT enthalten. Jede dieser Dateien steuert die Erzeugung einer speziellen grafischen Ausgabe. Aktuell stehen Dateien für ca. 100 verschiedene Grafiken und Animationen zur Verfügung.

Im Verzeichnis "Daten" speichert das Programm die Dateien zur Sicherung der Eingabe- und Ergebnisdaten und liest sie zur weiteren Bearbeitung, Auswertung oder Ableitung neuer Berechnungsvarianten auch wieder aus diesem Verzeichnis ein.

Das Verzeichnis "DatenDemo" enthält alle Eingabe- und Ergebnisdatensätze, die in der Dokumentation zur Demonstration der Arbeitsweise des Programms beschrieben werden. Diese Datensätze können dazu genutzt werden, die beschriebenen Beispiele selbst nachzurechnen bzw. die Auswertung der Ergebnisse zu üben. Um ein Demonstrationsbeispiel zu testen, ist die jeweiligen Datei in das Verzeichnis "Daten" zu kopieren.

Das Verzeichnis "Quellcode" enthält alle Dateien des Quellcodes des FORTRAN-Programms SIRIUS und die Batchdatei "1-Start-CompilerG77.bat" zum Aufruf des FORTRAN-Compilers. Jede Routine ist in einer eigenen Datei gleichen Namens abgelegt. Es sind außerdem einige Dateien enthalten, die aktuelle nicht im kompilierten Programm enthalten sind. Sie sind im Verzeichnis dadurch zu erkennen, dass sie die Erweiterung ".f_" haben und deshalb vom Compiler ignoriert werden. Siehe dazu auch Abschnitte 3.4.5.4, 4.9.3 und das Routinenverzeichnis 5.4.

Die Verzeichnisse "Temp", "Temp1" und "Temp2" dienen als Zwischenspeicher für die Kommunikation der drei beteiligten Programme untereinander, wie bereits in Bild 3.01 dargestellt.

Die Datei "SIRIUS.exe" enthält das komplette kompilierte ausführbare Programm SIRIUS. Die Datei "Skalierung.plt" enthält die Skalierungsparameter für die Erzeugung von grafischen Darstellungen mit GNUPLOT. Siehe dazu Abschnitt 4.7.1.

zurück  weiter

3.2.2 Prinzipielle Abläufe der Hauptrechnung

In diesem Abschnitt soll ein Überblick über die prinzipiellen Berechnungsabläufe der Hauptrechnung im Solver gegeben werden. Die gesamte Variantenvielfalt des Programms lässt sich mit 4 Berechnungsabläufen abdecken, die sich im Wesentlichen durch die Anzahl der zu durchlaufenden Iterationsschleifen unterscheiden.

zurück  weiter

3.2.2.1 Druckverlauf1: klassische Reynoldssche Differentialgleichung, vorgegebene Wellenverlagerung

Die klassische Reynoldssche Differentialgleichung ist eine lineare partielle Differentialgleichung 2.Ordnung. Die näherungsweise Berechnung der Druckverteilung im Schmierspalt lässt sich deshalb mit einem Differenzenverfahren realisieren. Das führt auf ein lineares Gleichungssystem, für das es verschiedene numerische Lösungsverfahren gibt. Die Routine "FilmDruck1" realisiert im Programm SIRIUS diese Aufgabe.

Bild 3.03: Iterationsschleifen innerhalb der Routine "Druckverlauf1"

Bild 3.03 zeigt ein Flussdiagramm mit einem stark vereinfacht dargestellten Berechnungsablauf der Routine "Druckverlauf1", in der die Routine "FilmDruck1" aufgerufen wird. In dieser wiederum ist die Routine "GMRES_ILU_pack" enthalten. Diese Routine enthält das Lösungsverfahren für das lineare Gleichungssystem. Die Rechenzeit für die Lösung des Gleichungssystems ist entscheidend für die Arbeitsgeschwindigkeit des gesamten Programms. Im Programm SIRIUS wird das GMRES-Verfahren (für Generalized minimal residual method) [11], [32] in Kombination mit einer Vorkonditionierung der Koeffizientenmatrix durch eine ILU-Zerlegung [10], [35] verwendet. Das GMRES-Verfahren arbeitet iterativ. Damit ist die innerste Iterationsschleife der Berechnung gegeben (magenta-farbene Schleife im Bild 3.03). Man könnte auch auf diese innerste Iterationsschleife verzichten, indem man ein direktes Verfahren verwendet, wie z.B. das Gaußsche Eliminationsverfahren, welches früher im Programm verwendet wurde. Bei einer Anzahl von ca. 10 000 Gleichungen, was für unsere Lagerberechnungen meist ausreichend ist, arbeitet das GMRES-Verfahren in Kombination mit der ILU-Zerlegung aber um den Faktor 1000 schneller. Hinzu kommt, dass hier mit einer gepackten Koeffizientenmatrix gearbeitet werden kann und so Speicherplatz gespart wird.

Sind die Betriebsbedingungen instationär, müssen die Druckverteilungen im Schmierspalt und die daraus resultierenden Lagerbelastungen über mehrere aufeinanderfolgende Zeitpunkte berechnet werden. Damit ist eine weitere äußere Schleife im Berechnungsablauf erforderlich (blaue Schleife im Bild 3.02). Im stationären Fall muss die äußere (blaue) Schleife nur einmal durchlaufen werden. Dieser Berechnungsablauf ist der einfachste und schnellste Ablauf der Hauptrechnung im Programm SIRIUS.

zurück  weiter

3.2.2.2 Druckverlauf2: erweiterte Reynoldssche Differentialgleichung, vorgegebene Wellenverlagerung

Die Berechnung der Druckverteilung im Schmierspalt und der Lagerbelastung aus einer vorgegebenen Wellenverlagerung, mit Hilfe der erweiterten Reynoldsschen Differentialgleichung, erfordert eine zusätzliche Iterationsschleife. Im Gegensatz zur klassischen Reynoldsschen Gleichung ist die erweiterte Reynoldssche Gleichung nicht mehr linear. Durch eine Linearisierung der Gleichung, mit Hilfe einer Anfangsnäherung, die über mehrere Berechnungszyklen iterativ verbessert wird, lässt sich diese Gleichung ebenfalls mit einem modifizierten Differenzenverfahren numerisch lösen. Damit kommt eine weitere Iterationsschleife in den Berechnungsablauf.

Bild 3.04: Iterationsschleifen innerhalb der Routine "Druckverlauf2"

Bild 3.04 zeigt ein Flussbild mit einem stark vereinfacht dargestellten Berechnungsablauf der Routine "Druckverlauf2" für die Berechnungen mit der erweiterten Reynoldsschen Gleichung. Die grüne Schleife ist die durch die Nichtlinearität der Gleichung zusätzlich hinzugekommene Iteration. Neben der Nichtlinearität kommt außerdem hinzu, dass die Druckverteilung im Schmierspalt nicht nur von der aktuellen Spaltgeometrie abhängt, sondern auch von der aktuellen Schmiermittelverteilung im nicht vollständig gefüllten Schmierspalt. Diese Verteilung hängt wiederum von den zeitlich vorausgehenden Verhältnissen im Schmierspalt ab. Deshalb ist hier immer eine Berechnung über mehrere Zeitschritte angesagt (blaue Schleife), selbst wenn nur die Druckverteilung eines stationär belasteten Lagers berechnet werden soll. Diese Berechnung über die Zeit stellt für den stationären Fall eine Anlaufrechnung dar, bei der sich die Lösung iterativ der stationären Endlösung nähert.

Auch für die Berechnung instationärer Lagerbelastungen, die meist als geschlossene Zyklen über eine oder mehrere Umdrehungen gegeben sind, ist zunächst eine Anlaufrechnung erforderlich, bevor der eigentliche in sich geschlossene Zyklus berechnet werden kann. Damit ist der äußere Berechnungszyklus (blaue Schleife) sowohl Iterationszyklus, als auch Simulation des eigentlichen physikalisch-technischen Verhaltens des Lagers. Bei kleinen Zeitschrittweiten sind die berechneten Druckverteilungen des vorhergehenden Zeitpunktes bzw. deren Extrapolation gute erste Näherungen für die iterative Berechnung des aktuellen Zeitpunktes. Das hat zur Folge, dass die inneren Iterationszyklen mit wenigen Durchläufen auskommen, so dass auch instationäre Betriebsbedingungen recht schnell berechnet werden können. Die Berechnung von beispielsweise 100 aufeinanderfolgenden Zeitpunkten eines instationären Lastfalles benötigt in der Regel wesentlich weniger Zeit als die Berechnung von 10 einzelnen stationären Lastfällen.

zurück  weiter

3.2.2.3 Verlagerungsbahn1: klassische Reynoldssche Differentialgleichung, vorgegebene Lagerbelastung

Das übliche ingenieurtechnische Problem der Lagerberechnung besteht darin, dass eine Lagerbelastung vorgegeben ist und daraus die Wellenverlagerung und die minimale Schmierspalthöhe zu ermitteln ist. Damit ist die Richtung von Ursache und Wirkung entgegengesetzt zu ihrer Darstellung in der Reynoldsschen Differentialgleichung. Ausgehend von dem prinzipiellen Ablauf der Berechnung in Bild 3.03 für die klassische Reynoldssche Differentialgleichung ist damit ein weiterer Iterationszyklus erforderlich.

Bild 3.05: Iterationsschleifen innerhalb der Routine "Verlagbahn1"

Bild 3.05 zeigt ein Flussbild mit einem stark vereinfacht dargestellten Berechnungsablauf der Routine "Verlagbahn1" für die Berechnung der Wellenverlagerung aus vorgegebenen Lagerbelastungen mit der klassischen Reynoldsschen Differentialgleichung. Die rote Schleife ist hier der neu hinzugekommene Iterationszyklus. Alternativ zur Routine "Verlagerung2" kann auch die Routine "Verlagerung1" zur Anwendung kommen. Ihre innere Struktur ist bezogen auf die Iterationsschleifen identisch zur Routine "Verlagerung2".

zurück  weiter

3.2.2.4 Verlagerungsbahn2: erweiterte Reynoldssche Differentialgleichung, vorgegebene Lagerbelastung

Für die Anwendung der erweiterten Reynoldsschen Differentialgleichung auf die Berechnung der Wellenverlagerung aus vorgegebenen Lagerbelastungen ergibt sich nun, in Kombination der Abläufe der Bilder 3.04 und 3.05, ein Berechnungsablauf mit 4 ineinander geschachtelten Iterationsschleifen gemäß Bild 3.06.

Bild 3.06: Iterationsschleifen innerhalb der Routine "Verlagbahn1"

Dieser Berechnungsablauf ist der aufwendigste. Er beschreibt aber die Verhältnisse im Lager am realistischsten und wird deshalb am häufigsten angewendet. Auch hier gilt für instationäre Lastfälle, wie bereits oben erwähnt, dass die Lösungen der vorher liegenden Zeitpunkte gute Näherungen für die aktuellen Zeitpunkte sind und so die 3 inneren Iterationszyklen nicht oft durchlaufen werden müssen, so dass sich in der Regel immer noch kurze Rechenzeiten ergeben. Alternativ zur Routine "Verlagerung2" kann auch die Routine "Verlagerung1" zur Anwendung kommen. Ihre innere Struktur ist bezogen auf die Iterationsschleifen identisch zur Routine "Verlagerung2".

zurück  weiter

3.2.3 Eine etwas detaillierte Übersicht über die Programmstruktur

Neben vielen recht komplexen Teilaufgaben, die innerhalb der Hauptrechnung ablaufen, befassen sich etwa 2/3 der Routinen mit der Dateneingabe im PreProzessor und der Ergebnisdarstellung und -sicherung im Postprozessor. Das konkrete Zusammenspiel dieser Routinen ist im Detail nur aus dem Quelltext und dem Routinenverzeichnis (siehe Anhang 5.4) herauszulesen, was unübersichtlich und beschwerlich ist. Um das Verständnis der Arbeitsweise des Programms auf anschauliche Art weiter zu vertiefen, wird die Struktur des Programms in den nachfolgenden Abschnitten durch wesentlich detaillierte Flussbilder dargestellt. Auch diese Darstellungen stellen noch nicht jedes Detail des Programmablaufs dar, um die Übersichtlichkeit zu bewahren. Ein Großteil der Unterroutinen wird auch hier nur als ein Kästchen dargestellt, in dem der Name der Routine und ihre Aufgabe angegeben wird.

zurück  weiter

3.2.3.1 Die Hauptroutine "SIRIUS"

Die Hauptroutine "SIRIUS" ist noch sehr übersichtlich, da sie nur die Titelzeilen des Programms auf dem Bildschirm anzeigt und als Rahmen für den Aufruf der 3 Routinen "PreProzessor", "Solver" und "PostProzessor" fungiert.

Bild 3.07: Flussbild der Hauptroutine "SIRIUS"

Bild 3.07 zeigt das Flussdiagramm der Hauptroutine. Die Routine operiert nur mit den zwei Steuerparametern "Status" und "Weiter". Die Variable "Status" wird hier auf den Startwert 1 gesetzt und wird in den untergeordneten Routinen weiter manipuliert und ausgewertet. Sie gibt Auskunft über Zustände des Programms und löst die Anzeige von Meldungen aus. Sie kann folgende Werte annahmen:

Status = 1 Das Programm wurde neu gestartet, die Standard-Eingabeparameter müssen initialisiert werden.
= 2 Die Eingabedaten sind in Bearbeitung. Die Bearbeitung ist noch nicht bis zum Ende durchlaufen. Die Eingabedaten können noch inkonsistent sein.
= 3 Es wurde ein Datensatz aus einer Datei eingelesen. Es kann direkt zur Berechnung übergegangen werden. Es ist aber nicht sicher, dass die Daten konsistent sind, weil sie evtl. außerhalb des Programms manipuliert wurden.
= 4 Bearbeitung der Eingabedaten wurde vollständig durchlaufen. Es liegt ein konsistenter Eingabedatensatz vor, mit dem die Berechnung durchgeführt werden kann.
= 5 Fortsetzung der Bearbeitung nach rechentechnischen Problemen.
= 6 Die Berechnung wurde abgebrochen. Das GMRES-Verfahren konvergiert nicht.
= 7 Die Berechnung der Verlagerung wurde abgebrochen, weil die Iteration über NJ Zyklen nicht konvergiert.
= 8 Die Berechnung wurde abgebrochen, weil eine Spalthöhe H≤0 auftrat.
= 9 Berechnung wurde nicht begonnen, weil die zulässige Anzahl NGleiMax von Gleichungen überschritten wurde oder der Gleichungslöser SIMQ hat einen Fehler gemeldet. (Kann nur auftreten, wenn mit ungepackter Matrix gearbeitet wird.)

Die Steuervariable "Weiter" wird durch Eingaben des Anwenders zur Art der gewünschten Fortsetzung des Programmablaufs gesetzt und dementsprechend vom Programm ausgewertet. Sie kann folgende Werte annehmen:

Weiter = 0 Gehe zum PreProzessor, zum Anfang der Eingabe
= 1 Gehe zurück zum vorhergehenden Menü
= 2 Gehe weiter zum nächsten Menü
= 3 Wechsel in die dimensionslose bzw. dimensionsbehaftete Darstellung
= 4 Gehe zum Solver
= 5 Gehe zum PostProzessor
zurück  weiter

3.2.3.2 PreProzessor

Die Routine "PreProzessor" umfasst die gesamte Dateneingabe und die weitere Datenaufbereitung für die Hauptrechnung.

Bild 3.08: Flussdiagramm der Routine "PreProzessor"

HINWEIS: Das Bild ist wegen seiner Länge hier zunächst stark verkleinert. Wer mehr Details erkennen möchte, kann sich durch klicken auf das Bild eine vergrößerte Version anzeigen lassen.

Bild 3.08 zeigt das Flussdiagramm der Routine. Der Ablauf spiegelt sich recht gut in der Abfolge der Eingabemenüs wieder, wie sie dem Anwender nacheinander am Bildschirm erscheinen. Siehe dazu auch Bild 4.009. Er bekommt aber nur die Menüs zu Gesicht, die für die aktuelle Variante relevant sind. Die meisten der hier dargestellten Unterroutinen repräsentieren ein Menü, das eine Gruppe von Eingabeparametern zur Auswahl und Bearbeitung zusammenfasst. Jede dieser Routinen ruft dann weitere Unterroutinen auf zur konkreten Bearbeitung einzelner Parameter. So verbergen sich hinter den schlichten Kästchen dieses Flussdiagramms weitere teils recht komplexe Strukturen des Programms.

Der Anwender braucht sich während der Eingabe nur mit den primären Eingabedaten zu befassen. Von ihm unbemerkt, werden vom Programm weitere sekundäre Eingabedaten berechnet bzw. ermittelt. Das erfolgt im Wesentlichen durch die Routinen "Muster", "AktualRegister" und "Komplettieren".

Die Routine "Muster" füllt das Feld KX, in dem die vom Anwender eingegebene Daten der Schmiertaschenverteilung bereits enthalten sind, mit weiteren sekundären Steuerdaten auf, die das Programm bei der Anwendung des Differenzenverfahrens zur Auswahl der richtigen Differenzengleichung benötigt. Diese sekundären Steuerdaten werden bei der Anzeige des Steuerfeldes KX jedoch unterdrückt, da der Anwender diese Information nicht wissen muss und dadurch die Übersichtlichkeit des Eingabemenüs besser ist. Außerdem füllt die Routine "Muster" die Felder KZ und NG mit sekundären Steuerdaten. Diese Steuerdaten habe eine analoge Aufgabe, wie die sekundären Steuerdaten in KX. Die Felder KZ und NG bleiben dem Anwender vollständig verborgen. Siehe dazu Abschnitt 3.4.1.6.

Die Routine "AktualRegister" ermittelt einen umfangreichen Satz von sekundären Steuerdaten, die für die Steuerung der Eingabe zeitvariabler Eingabedaten und für die Sicherung der primären Eingabe- und Ergebnisdaten in einer externen Datendatei benötigt werden.

Die Routine "Komplettieren" berechnet alle restlichen Eingabedaten, die das Programm für die Hauptrechnung benötigt und durch die eingegebenen primären Eingabedaten bereits feststehen.

Neben dem mittigen Hauptweg durch die Routine "PreProzessor" gibt es rechts im Bild 3.08 einen Nebenweg, der aus dem Startmenü direkt an das Ende der Routine führt. Falls im Startmenü aus einer externen Datei ein kompletter Datensatz von primären Eingabe- und Ergebnisdaten einer früheren Berechnung geladen wurde, kann man auf diesem Weg unter Umgehung der Eingaberoutinen direkt zum PostProzessor gelangen, um diese Daten auszuwerten. Auf diesem Weg werden lediglich die 3 oben erläuterten Routinen "Muster", "AktualRegister" und "Komplettieren" aufgerufen zur Ergänzung der zugehörigen sekundären Eingabedaten", da diese bei der Datensicherung nicht gespeichert wurden. Die sekundären Ergebnisdaten, die ebenfalls nicht abgespeichert wurden, brauchen hier nicht rekonstruiert werden. Der PostProzessor erledigt das auf entsprechende Anfrage selbst.

Dieser Bypass im Programm ist ein Kompromiss zu Gunsten der Flexibilität und zu Lasten der Zuverlässigkeit des Programms. Es könnte sein, dass die eingelesenen Daten extern unsachgemäß manipuliert wurden. Durch die Umgehung der Konsistenzprüfung in den Eingaberoutinen und einen möglichen Rücksprung aus dem PostProzessor in den Solver könnten Berechnungen erfolgen, die zu unerwarteten Ergebnissen oder auch zum Absturz des Programms führen. Der Nutzer muss sich dieser Gefahr bewusst sein. Das Programm gibt beim Beschreiten dieses Pfades im PostProzessor eine Warnung aus.

zurück  weiter

3.2.3.3 Solver

Die Routine "Solver" umfasst die gesamte Hauptrechnung. Hier werden die primären Ergebnisdaten berechnet. Das ist das Feld der Druckverteilungen P(NZ,NX,NT2) im Schmierspalt über das Zeitintervall von NT2 Zeitpunkten. Hinzu kommen die Drücke und Ölströme im peripheren Schmiermittel-Versorgungssystem, falls es vorhanden ist, und je nach Variante die resultierenden Lagerbelastungen So(NT2), XSo(NT2) bzw. die Verlagerungsbahn E1(NT2),E2(NT2) bzw. E(NT2),XE(NT2) und der Verlauf der minimalen Schmierspalthöhe HMin(NT2) über die NT2 Zeitpunkte.

Bild 3.09 zeigt das Flussdiagramm der Routine.

HINWEIS: Das Bild ist wegen seiner Größe hier zunächst stark verkleinert. Wer mehr Details erkennen möchte kann sich durch klicken auf das Bild eine vergrößerte Version anzeigen lassen.

Zu Beginn der Routine kann der Nutzer festlegen, ob eine komplette Berechnung über alle Zeitpunkte erfolgen soll oder nur über einige ausgewählte Zeitschritte. Dann muss er das Ende abwarten und erhält nur die kurze Informationen, welche Zeitpunkte das Programm bereits erledigt hat. Wenn eine Verlagerungsbahn berechnet wird, kommen noch einige Informationen zum Konvergenzverhalten der Berechnung dazu. Von dem ansonsten recht komplexen Berechnungsablauf, wie er aus dem Flussdiagramm auch nur teilweise zu erkennen ist, sieht der Anwender nichts.

Bild 3.09: Flussdiagramm der Routine "Solver"

Hier im Flussdiagramm sind wieder die 4 möglichen Berechnungsvarianten als 4 parallele Berechnungsabläufe zu erkennen, die im Abschnitt 3.2.2 bereits erläutert wurden. Entsprechend der gewählten Variante wird jeweils ein Strang durchlaufen. In den beiden rechten Strängen (Routinen "Verlagbahn1" und "Verlagbahn2") erfolgt eine weitere Aufteilung der Stränge in die Routinen "Verlagerung1" und "Verlagerung2". Hier werden die jeweils aktuellen Wellenverlagerungen iterativ berechnet. Die beiden Stränge unterscheiden sich lediglich dadurch, dasss im linken Zweig "Verlagerung1" die Iteration in kartesischen Koordinaten E1, E2 erfolgt, während im rechten Zweig "Verlagerung2" die Iteration in polaren Koordinaten E, XE erfolgt. Der linke Zweig wird bei kleiner Exzentrizität angewendet und der rechte Strang bei großer Exzentrizität. Weitere Erläuterungen dazu siehe Abschnitt 3.4.7. Die grau dargestellten Abschnitte des Flussdiagramms sind zukünftig erforderlich, wenn die elastische Verformung des Lagers berücksichtigt werden soll.

Bild 3.10: Flussdiagramme der Routinen "FilmDruck1" und "FilmDruck2"

Zwei wichtige Routinen, die im Bild 3.09 nur als kleine Kästchen mehrfach auftreten, sind "FilmDruck1" und "FilmDruck2". Diese enthalten den rechenintensiven Hauptteil, die Berechnung der Druckverteilung im Schmierfilm einschließlich der Drücke und Ölströme in der peripheren Schmiermittelversorgung. Die Routine "FilmDruck1" rechnet mit der klassischen Reynoldsschen Differentialgleichung und die Routine "FilmDruck2" mit der erweiterten Reynoldsschen Differentialgleichung.

zurück  weiter

3.2.3.4 PostProzessor


Bild 3.11: Flussdiagramm der Routine "PostProzessor"

HINWEIS: Das Bild ist wegen seiner Länge hier zunächst stark verkleinert. Wer mehr Details erkennen möchte, kann sich durch klicken auf das Bild eine vergrößerte Version anzeigen lassen.

Bild 3.11 zeigt das Flussdiagramm der Routine "PostProzessor". Hier sind alle Unterroutinen versammelt, die der Datensicherung sowie der grafischen und numerischen Darstellung der Ergebnisse dienen. Die Grundstruktur zeigt sich dem Anwender im Hauptmenü dieser Routine (siehe dazu auch Abschnitt 4.6). Hier kann man aus einer Reihe möglicher Operation eine auswählen und ausführen lassen. Nach Abschluss der Operation, die in der Regel noch durch einige Untermenüs führt, springt das Programm zurück in das Hauptmenü und ist bereit zur Ausführung weiterer Operationen.

Die Gesamtheit der möglichen Operationen umfasst 4 Blöcke:
1. Datenverwaltung
2. Bereitstellung von Daten für grafische Darstellungen mit GNUPLOT
4. Numerische Darstellung der Ergebnisse
9. Sonstige Operationen

Wenn bereits in Dateien gesicherte Berechnungsergebnisse existieren, kann die Routine "PostProzessor" auch selbständig operieren, ohne vorher den "PreProzessor" und den "Solver" zu durchlaufen. Dazu gibt es im Block der Datenverwaltung die Möglichkeit einzelne Datensätze einzulesen und anschließend auszuwerten. Jeder neu eingelesene Datensatz wird hier sofort nach dem Lesen durch die Routinen "Muster", "AktualRegister" und "Komplettieren" mit den notwendigen sekundären Eingabedaten vervollständigt, was sonst bereits im "PreProzessor" erfolgt ist.

zurück  weiter

3.2.4 Das Zusammenspiel der Routinen

Das Programm SIRIUS umfasst ca. 700 Seiten kommentierten Quelltext, der sich auf ca. 120 Routinen verteilt. Es wurde von Anfang an als Baukastensystem aufgebaut. Dadurch war eine kontinuierliche Weiterentwicklung möglich. Die Aufteilung der Routinen erfolgte hauptsächlich nach funktionellen Gesichtspunkten und zum Teil auch nach programmiertechnischen Erfordernissen.

Bild 3.12 gibt einen optischen Überblick über das Zusammenspiel der einzelnen Routinen. Jedes Kästchen symbolisiert genau eine Routine. Die Pfeile zwischen den Routinen symbolisieren den Zugriff der einzelnen Routinen auf die jeweiligen Subroutinen einer darunter liegenden Hierarchieebene. Die Pfeile zeigen von der aufrufenden Routine auf die aufgerufenen Routinen. Es hat sich inzwischen eine Tiefe der Strukturierung von maximal 7 Hierarchieebenen ergeben. Die grau hinterlegten Routinen gehören nicht zum Bestand des aktuellen Programms. Es sind zum Teil Routinen, die nur für Testzwecke vorgesehen sind und dazu gegebenen Falls erst aktiviert werden müssen. Außerdem sind es Routinen, die bereits eingebaut sind für die Berücksichtigung elastischer Verformungen der Lagerschale, die aber noch nicht genutzt werden können, weil das Berechnungsverfahren noch nicht ausgereift ist und weiterer Entwicklungsbedarf besteht.

Bild 3.12: Das Zusammenspiel der Routinen

Das Bild 3.12 ist geeignet für einen optischen Überblick. Als zuverlässige Programmierhilfe im Rahmen einer Erweiterung oder Modifizierung des Programms ist es nicht geeignet, weil seine Aktualisierung sehr umständlich ist und deshalb eine ständige Aktualität nicht gewährleistet werden kann. Dazu besser geeignet ist das Verzeichnis der Routinen (siehe Anhang 5.4). Das Bild 3.12 wurde aufgrund der Angaben dieses Verzeichnisses erstellt. Das Routinenverzeichnis enthält noch weitere hilfreiche Informationen, die für eine fehlerfreie Bearbeitung des Gesamtprogramms wichtig sind. Solltest Du Dich entschließen am Quellcode des Programms zu arbeiten, ist eine laufende penible Aktualisierung dieses Verzeichnisse dringen angeraten. Z.B. muss die rechte Spalte des Verzeichnisses unbedingt auf dem aktuellen Stand sein, wenn die Feldgrößen im Programm verändert werden sollen, um evtl. mit noch feineren Gitterteilungen ΔX und ΔZ oder mehr Zeitschritten NT arbeiten zu können. Siehe dazu Abschnitt 4.2.9.

zurück  weiter

3.3 Die Datenstruktur des Programms und ihre Verwaltung

Die Vielfalt der darstellbaren Lagervarianten erfordert eine große Anzahl von Eingabe- und Ergebnisparametern. Hinzukommen weitere Variablen zum Speichern von Zwischenergebnissen und Hilfswerten. Im Programm sind dafür mehr als 600 verschiedene Variablen definiert, von denen einige umfangreiche Felder mit vielen Werten repräsentieren. Von diesen Variablen können ca. 200 an der Programmoberfläche erscheinen. Um bei der Programmierung und der Anwendung des Programms nicht den Überblick zu verlieren, erfordert das eine systematische Datenstruktur, die nachfolgend beschrieben wird.

zurück  weiter

3.3.1 Ein einheitliches Bezeichnungssystem

Für die Parameter, die an der Programmoberfläche erscheinen, und die globalen Variablen, die in mehreren Routinen bearbeitet werden, wurde eine weitgehend einheitliche sprechende Nomenklatur erarbeitet: Jede Variable besteht aus einem Basissymbol, dass aus mehreren Zeichen bestehen kann. Beschreibt das Symbol einen dimensionslosen Parameter, beginnt es mit einem großen Buchstaben. Beschreibt es einen dimensionsbehafteten Parameter, beginnt es mit einem kleinen Buchstaben. Evtl. vorhandene weitere Zeichen des Basissymbols sind in der Regel kleine Buchstaben.

Jedes Basissymbol kann durch Bezeichnungszusätze ergänzt werden. Diese Zusätze können ebenfalls aus mehreren Zeichen bestehen, beginnend mit einem großen Buchstaben und evtl. gefolgt von weiteren kleinen Buchstaben. Es können auch Ziffern sein. Im Dokumentationstext werden die Bezeichnungszusätze als tiefer gestellte Zeichen dargestellt (Indexschreibweise). Im Quelltext und an der Programmoberfläche werden die Zusätze einfach an das Basissymbol angehängt, da die Programmiersprache FORTRAN die Indexschreibweise nicht zulässt. Ein Basissymbol kann auch durch mehrere Zusätze ergänzt werden. Indem die Bezeichnungszusätze mit einem großen Buchstaben beginnen, können in der einfachen Verkettung von Basissymbol und einem oder mehreren Zusätzen die Namensstruktur in der Regel leicht erkannt werden. Zur Verbesserung der Erkennbarkeit werden gelegentlich auch Unterstriche eingefügt.

Die Bezeichnungszusätze "..._0", "..._Ak" und "..._k" werden an eine größere Anzahl von Basisbezeichnungen angefügt. Zu ihrer Bedeutung siehe Tabelle 3.2. Da die Parameter mit diesen Bezeichnungszusätzen nur programmintern verwendet werden, sind sie nicht extra im Symbolverzeichnis aufgeführt.

Alle Parameter mit dem Bezeichnungszusatz "_0" sind im Common-Block "common/Datenregister/" abgelegt.

Alle Parameter mit dem Bezeichnungszusatz "_k" sind im Common-Block "common/konstVarParameter/" abgelegt.

Alle Parameter mit dem Bezeichnungszusatz "_Ak" sind in den Common-Blöcken "common/aktuelleVarParameter/" und "common/Druck/" abgelegt.

Echte Indizes zur Bezeichnung einer Komponente eines Datenfeldes werden in runde Klammern gesetzt und an die Bezeichnung der Feldvariablen angehängt.

Einige Bezeichnungsbeispiele:

UnWe bzw. UnWe Bezeichnet die dimensionslose Unrundheit der Welle.
kant2Amp bzw. kant2Amp Bezeichnet die dimensionsbehaftete Amplitude der Komponente in Richtung der Achse 2 des Koordinatensystems 1-2-3 einer zeitvariablen Verkantung der Welle in der Lagerschale.
Kant_k Bezeichnet den konstanten Eingabewert der in der Regel zeitabhängigen variablen Verkantung "Kant". Die Variable "Kant" ist im Programm ein Feld von NT Werten, während Kant_k eine skalare Größe ist. An der Programmoberfläche wird der Wert der internen variablen Kant_k aber auch einfach mit Kant bezeichnet, um die Zugehörigkeit zu der physikalischen Erscheinung "Verkantung der Welle" hervorzuheben. Im Symbolverzeichnis werden die Variablen mit dem Zusatz "..._k" nicht extra aufgeführt.
Kant_0 Bezeichnet die Steuervariable zum Parameter "Kant", die angibt, ob der Parameter "Kant" ein primärer oder sekundäre Eingabe- oder Ergebnisparameter ist. Im Symbolverzeichnis werden die Variablen mit dem Zusatz "..._0" nicht extra aufgeführt.
P(JZ,JX,JT) bzw. P(JZ,JX,JT) Bezeichnet den dimensionslosen Schmierfilmdruck an der Stelle JZ, JX, JT des dreidimensionalen Feldes aller berechneten Schmierspaltdrücke. Es ist der Druck am Punkt [JZ,JX] des über den Schmierspalt aufgespannten Gitternetzes zum Zeitpunkt JT.
P(NZ,NX,NT) bzw. P(NZ,NX,NT) Bezeichnet das gesamte Datenfeld der punktweise abgespeicherten Druckverteilungen über den Schmierspalt und über die Zeit für JZ=1 bis NZ, JX=1 bis NX und JT=1 bis NT.

Die Tabelle 5.2 im Anhang der Dokumentation enthält alle Parameterbezeichnungen der Dokumentation, der Programmoberfläche und der programminternen Variablen, die nach der erläuterten Nomenklatur im gesamten Programm einheitlich bezeichnet wurden. Die Tabelle 3.1 enthält die wesentlichen Basissymbole. Basissymbole, die grundsätzlich ohne Bezeichnungszusatz verwendet werden, sind in dieser Tabelle nicht aufgeführt. Ihre Bedeutung ist dem Symbolverzeichnis im Anhang zu entnehmen. Siehe Tabelle 5.2 im Anhang. Die Tabelle 3.2 enthält die verwendeten Bezeichnungszusätze. Die genaue Bedeutung der kompletten Symbolik ist dem Symbolverzeichnis (Tabelle 5.2 im Anhang) zu entnehmen.

Neben den Bezeichnungszusätzen, die üblicherweise an das Basissymbol angehängt werden, werden gelegentlich 4 Bezeichnungszusätze verwendet, die dem Basissymbol vorangestellt werden. Das sind die Bezeichnungszusätze Δ..., Delta... und D... . Sie stehen alle gleichbedeutend für die Differenz bzw. Schrittweite zweier Werte des nachfolgenden angegebenen Parameters. Diese verschiedenen Schreibweisen sind dem Umstand geschuldet, dass FORTRAN keine griechischen Buchstaben darstellen kann.

Im Quelltext der einzelnen Routinen sind weitere lokale Variable definiert. Ihre Bedeutung wird nur im Kopf der jeweiligen Routine erklärt. Ihre Schreibweise ist willkürlich und entspricht nicht der oben erläuterten Schreibweise. Die Bedeutung der globalen Variablen des einheitlichen Bezeichnungssystems wird in den einzelnen Routinen nicht noch einmal erklärt, da ihre Bedeutung zentral im Verzeichnis der Symbole (Anhang: 5.2 Symbolverzeichnis) erklärt ist.

Tabelle 3.1: Verzeichnis der Basissymbole, die in verschiedenen Kombinationen mit Bezeichnungszusätzen verwendet werden

Basissymbol Beschreibung
a A Spaltfläche
- A... Koeffizienten des linearen bzw. linearisierten Reynoldsschen Differentialgleichung
- a... sonstige Koeffizienten (Hilfsvariablen für Zwischenergebnisse)
b... B... Lagerbreite, Breite eines Lagerabschnitts
ba... Ba... Betrag der Balligkeit der Welle oder der Lagerschale
- Bez... Liste von Bezeichnungen ... zu den bisher einprogrammierten Gerätetypen
bieg... Bieg... Betrag der Biegung der Welle
c C Mischungskonstante
- C... Hilfsvariablen
d... - Durchmesser
e... E... Exzentrizität
f... (So...) Lagerbelastung
- F... Füllungsgrad
freq... Freq... Phasenfrequenz
h... H... Spalthöhe
- J... Laufindex
- K... Koeffizienten (Hilfsvariablen)
kant... Kant... Betrag der Wellenverkantung
ko... Ko... Konizität des Lagerschale
lei... Lei... Leistung
- mm... Platzhalter in COMMON-Blöcken für ganzzahlige Variablen, die in der entsprechenden Routine nicht benötigt werden
mo... Mo... Kippmoment an der Welle eines asymmetrischen Lagers
- N... Anzahl
- nn... Platzhalter in COMMON-Blöcken für ganzzahlige Variablen, die in der entsprechenden Routine nicht benötigt werden
p... P... Druck
- Pa... Feld der Parameter der Gerätevarianten
- Pn... vorläufiger Näherungswert für den Druck P
q... Q... Schmiermittelstrom
(f...) So... Sommerfeldzahl = dimensionslose Lagerbelastung (dimensionsbehaftete Lagerbelastung siehe f)
- Symb... Tabelle der Symbole der Parameter der bisher einprogrammierten Gerätevarianten
t... T... Zeit
- Tol... geforderte Genauigkeit bei der Lösung des linearen Gleichungssystems
un... Un... Betrag der Unrundheit der Welle bzw. Lagerschale
v... - Schmiermittelströmungsgeschwindigkeit
vol... Vol... Volumen
x... X... Umfangskoordinate des dimensionslosen X-Z-Koordinatensystems bzw. des dimensionsbehafteten x-y-z Koordinatensystems
- xx... Platzhalter in COMMON-Blöcken für reelle Variablen, die in der entsprechenden Routine nicht benötigt werden
y - radial zum Zentrum zeigende Koordinate des Lagerschalen-Koordinatensystem x-y-z
- yy... Platzhalter in COMMON-Blöcken für reelle Variablen, die in der entsprechenden Routine nicht benötigt werden
z... Z... axiale Koordinate des lagerschalenfesten Koordinatensystem x-y-z
- zz... Platzhalter in COMMON-Blöcken für reelle Variablen, die in der entsprechenden Routine nicht benötigt werden
η... eta... Eta... dynamische Viskosität der flüssigen Phase des Schmiermittels
φ... phi... Φ... Phi... Phasenwinkel
ω... omega... Ω... Omega... Winkelgeschwindigkeit der Welle bezogen auf das lagerschalenfeste Koordinatensystem x-y-z

Tabelle 3.2: Verzeichnis der Bezeichnungszusätze die in verschiedenen Kombinationen mit den Basissymbolen verwendet werden

Bezeichnungs­zusatz Beschreibung
..._0 Bezeichnungszusatz, der den sekundären Steuerparameter Xyz_0 zu einem Basisparameter Xyz bezeichnet. Dieser Steuerparameter Xyz_0 codiert die Information, ob der Basisparameter Xyz ein primärer, sekundärer oder irrelevanter Eingabe- oder Ergebnisparameter ist.
Xyz_0=-2   bedeutet:  Xyz ist ein sekundärer Ergebnisparameter
=-1Xyz ist ein sekundärer Eingabeparameter
= 0 Xyz ist ein irrelevanter Parameter
= 1 Xyz ist ein primärer Eingabeparameter
= 2 Xyz ist ein primärer Ergebnisparameter
...0 ...1 ...2 ... Nummerierungen
...1 ...2 ...3 Achsenbezeichnungen der Komponenten bezogen auf das Koordinatensystem 1-2-3
..._Ak aktueller skalarer Wert Xyz_Ak aus einem zeitlich variablen Parameterfeldes Xyz(NT). Xyz_Ak=Xyz(JT), wenn JT die Nummer des aktuellen Zeitpunktes ist.
...Amp Amplitude
...Anf Anfangswert
...Bieg Wellenbiegung
D... Delta... Differenz bzw. Schrittweite (steht im Programm stellvertretend für das Zeichen Δ)
...Dim dimensionsbehaftet
...E Exzentrizität
...End Endwert
...f Kraft
...Fl flüssige Phase des Schmiermittels
...Gas gasförmige Phase des Schmiermittels
...Ge Flüssigkeits-Gas-Gemisch
...geglättet geglätteter Funktionsverlauf
...Ges Gesamtwert, Summe
...Glei Gleichung
...Chp integrierte Elastizitätsmatrix
..._k Bezeichnungszusatz eines skalaren Eingabeparameter Xyz_k, der einen aktuell zeitlich konstanten Wert eines eigentlich zeitlich variablen Parameterfeldes Xyz(NT) enthält. An der Programmoberfläche wird dieser Bezeichnungszusatz nicht gezeigt.
..._k0 Kombination der Bezeichnungszusätze ..._k und ..._0
...Kant Wellenverkantung
...La Lagerschale
...Max Maximalwert
...Min Minimalwert
...Mit Mittelwert
...Mo Wellendrehmoment
...P Druck
...Pa Parameter der Gerätevarianten in den Verbindungsleitungen
...Pu Pumpe
...Rand Lagerrand bzw. Schmiertaschenrand
...Reib Reibung
...S Schnittpunkt
...So Sommerfeldzahl, dimensionslose Lagerbelastung
...Spalt Schmierspalt
...Sym Symmetrie
...T ...t Zeit, im Quellcode und an der Programmoberfläche auch die Ableitung nach der Zeit, z.B. PT=∂P/∂T bzw. pt=∂p/∂t
...Ta Schmiertasche
...tics Skalenteilung in der grafischen Darstellung mit GNUPLOT
...Typ Gerätetyp
...Um Umrechnungsfaktor eines dimensionslosen Parameters in den entsprechenden dimensionsbehafteten
...Var Gerätevarianten
...Ve Verbindungsleitung
...Ver Verlust
...Vers Versatz der Lagerabschnitte
...We Welle
...Wechsel Grenzwert zum Wechsel der Berechnungsmethode
...X ...x X-Richtung bzw. partielle Ableitung, z.B. PX=∂P/∂X bzw. px=∂p/∂x
...Y Y-Richtung
...Z ...z Z-Richtung bzw. partielle Ableitung, z.B. PZ=∂P/∂Z bzw. pz=∂p/∂z
Δ... Delta... D... Differenz bzw. Schrittweite z.B. ΔT(JT)=T(JT)-T(JT-1)
zurück  weiter

3.3.2 Das System der Steuerparameter

Mit dem Programm SIRIUS können qualitativ verschiedene Lagertypen, Betriebsbedingungen, theoretische Modelle und Berechnungsziele simuliert werden, zwischen denen der Anwender wählen kann und die zu einer großen Anzahl konkreter Varianten kombiniert werden können. Um das programmtechnisch zu organisieren, wurde neben den technischen Parametern, die die technischen Merkmale des Lagers quantifizieren, ein System von Steuerparametern implementiert, mit dem die jeweiligen qualitativen Merkmale der zu untersuchenden Variante codiert werden. Dementsprechend wurde für jedes qualitative Merkmal, für das es mindestens 2 Varianten gibt, ein Steuerparameter eingeführt. Die Steuerparameter sind generell als ganzzahlige Variablen vereinbart, auch wenn aktuell nur zwei Varianten vorgesehen sind. Damit können dem Programm relativ einfach weitere Varianten hinzugefügt werden. Anhand der aktuell geltenden Steuerparameter wird der Ablauf des gesamten Programms gesteuert. Das Programm ruft die erforderlichen Routinen auf und wählt die geeigneten Formeln aus. Eine für den Anwender besonders hilfreiche Funktion haben die Steuerparameter, indem mit ihrer Hilfe aus der großen Anzahl der möglichen technischen Eingabeparameter diejenigen ausgewählt werden, die für die aktuelle Variante relevant sind, so dass der Anwender nicht von einer großen Anzahl unsinniger Abfragen überhäuft wird.

Die Steuerparameter arbeiten im Wesentlichen unter der Programmoberfläche und der Anwender braucht sich um die Codierung keine Gedanken zu machen. Dort, wo qualitative Entscheidungen über die gewünschte Lagervariante zu treffen sind, kann in den entsprechenden Menüs zwischen den einzelnen verbal beschriebenen Varianten ausgewählt werden. Das Programm belegt dann den entsprechenden Steuerparameter mit dem zugehörigen Code. Die Codierung der Steuerparameter entspricht in der Regel den Aktionsnummern im Menü, mit denen die jeweilige Variante ausgewählt wird.

Die Steuerparameter zählen generell zu den Eingabedaten. Wenn sie zu den primären Eingabedaten gehören, wird der Anwender in einem entsprechenden Menü durch das Programm aufgefordert eine Variante auszuwählen. Es gibt aber auch eine große Anzahl sekundärer Steuerparameter, die aus der Eingabe der primären Steuerparameter abgeleitet werden. Diese sind in der Regel für den Anwender nicht sichtbar.

zurück  weiter

3.3.2.1 Die primären Steuerparameter des Hauptmenüs: "Festlegungen zur Theorie, zum Berechnungsverlauf und zum Lagertyp"

Die in der Eingabehierarchie ganz oben stehenden Steuerparameter sind die des 2.Hauptmenüs des PreProzessors "Festlegungen zur Theorie, zum Berechnungsverlauf und zum Lagertyp" (siehe dazu Bedienanleitung Abschnitt 4.4.2 und Unterabschnitte). Sie bestimmen im Wesentlichen die zu modellierende Lagervariante, die Betriebsbedingungen, das zu verwendende theoretische Modell und die daraus resultierenden weiteren erforderlichen Eingaben.

Die oben dargestellte Liste im Hauptmenü zeigt rechts die hier implementierten Steuerparameter und beispielhaft jeweils eine mögliche Belegung. Der Text in der jeweiligen Zeile beschreibt in Stichworten die Variante, die der aktuell dargestellten Code-Nummer entspricht. Die ausführliche Beschreibung der hiermit spezifizierbaren Varianten und ihre Codierung sind beschrieben in den Unterabschnitten 4.4.2.1 bis 4.4.2.19 der Bedienanleitung.

Programmintern sind diese Steuerparameter gemeinsam abgelegt im COMMON-Bock "common/Steuerparameter/", auf die alle Routinen bei Bedarf direktzugreifen können.

zurück  weiter

3.3.2.2 Die sekundären Steuerparameter des COMMON-Blocks "/Datenregister/"

Um die Eingabe der zeitlich variablen Parameter und die Sicherung der Eingabe- und Ergebnisdaten programmtechnisch effektiv und übersichtlich zu gestalten, wurde jedem Parameter, der in irgendeiner Variante ein primärer Eingabe- oder Ergebnisparameter sein kann, ein sekundärer Steuerparameter zugeordnet, in dem dieses Merkmal codiert werden kann. Alle diese sekundären Steuerparameter sind in dem COMMON-Block "common/Datenregister/" abgelegt. Dabei gilt folgende Nomenklatur: Einem Parameter Xyz wird der Steuerparameter Xyz_0 zugeordnet. Das entsprechende Merkmal des Parameter Xyz wird im Steuerparameter Xyz_0 durch folgende Werte codiert:

Xyz_0=-2   bedeutet:  Xyz ist ein sekundärer Ergebnisparameter
=-1Xyz ist ein sekundärer Eingabeparameter
= 0 Xyz ist ein irrelevanter Parameter
= 1 Xyz ist ein primärer Eingabeparameter
= 2 Xyz ist ein primärer Ergebnisparameter

All den Variablen, die ausschließlich nur sekundäre Parameter sein können oder auch nur programmintern genutzt werden, wurde kein entsprechender Steuerparameter zugeordnet.

Die Belegung der Steuerparameter Xyz_0 mit Werten erfolgt durch die Routine "AktualRegister", wenn die Codierung in Abhängigkeit von der gewählten Lagervariante variieren kann. Wenn die Belegung des entsprechenden Steuerparameters unveränderlich ist, erfolgt die Belegung einmalig in der Routine "Anfangsdaten".

Diese sekundären Steuerparameter werden verwendet in den Routinen "VarPara" und "AusgabePara5" zur effektiven Selektion der jeweiligen primären Eingabe- und/oder Ausgabeparameter entsprechend ihres aktuellen Merkmals. Siehe dazu auch die Abschnitte 3.3.3 und 3.3.5.

zurück  weiter

3.3.2.3 Die Steuerfelder KX, KZ und NG zur Darstellung der Schmiertaschen und der Codierung der erforderlichen Differenzengleichung und Gleichungsnummern

Mit SIRIUS ist es möglich beliebige Anordnungen von Schmiertaschen und Schmiernuten zu simulieren. Um diese Flexibilität des Programms zu realisieren, sind die drei Datenfelder KX(NZ,NX), KZ(NZ,NX) und NG(NZ,NX) erforderlich, die ausschließlich Steuerparameter enthalten. Von diesen 3 Feldern bekommt der Anwender nur das Feld KX zu Gesicht und zwar in dem Menü, wo er die Anordnung von Schmiertaschen eingibt. Programmintern füllt das Programm die Felder KX, KZ und NG mit weiteren sekundären Steuerparametern auf, die dem Anwender aber nicht angezeigt werden. Mit diesen Parametern steuert das Programm die Aufstellung der passenden Koeffizientenmatrix des linearen Gleichungssystems zur Berechnung des Schmierfilmdrucks. Die Aufgaben und die Arbeitsweise der Steuerfelder KX, KZ und NG sind ausführlich beschrieben in den Abschnitten 3.4.1.5 und 3.4.1.6 der Programmbeschreibung und die Arbeit mit dem Steuerfeld KX zur Eingabe von Schmiertaschen im Abschnitt 4.4.8 der Bedienanleitung.

zurück  weiter

3.3.2.4 Die Steuerfelder des Universal-Schmiermittel-Versorgungssystems

Auch die Gestaltung des peripheren Schmiermittel-Versorgungssystems, welches insbesondere für die Simulation hydrostatischer Lager benötigt wird, kann sehr komplex und variantenreich abgebildet werden. Dazu werden die 4 Felder mit Steuerparametern benötigt:

PuVar(NPu) Betriebszustände der Schmiermittelpumpen siehe Abschnitt 3.3.6.1
NPaTyp(NTyp) Anzahlen der physikalisch-technischen Parameter der Gerätetypen siehe Abschnitt 3.3.6.2
TypVar(NVar) Typnummern der Gerätevarianten siehe Abschnitt 3.3.6.3
Ve(3,NVe) Struktur des Wirkschaltplans des Schmiersystems siehe Abschnitt 3.3.6.4

Eine Schlüsselfunktion hat hier das Steuerfeld Ve(3,NVe). Mit ihm werden die Verbindungen zwischen den Schmiermittelpumpen und den Schmiertaschen über die Verbindungsleitungen dargestellt. Außerdem wird hiermit angegeben, mit welcher Gerätevariante zur Regelung der Schmiermittelströme die einzelnen Verbindungsleitungen ausgerüstet sind. Die ausführlichen Beschreibungen erfolgen in den angeführten Abschnitten.

zurück  weiter

3.3.3 Das System der primären und sekundären Eingabe- und Ergebnisparameter

Eine Variable im Programm kann je nach aktuell simulierter Lagervariante Eingabeparameter, Ergebnisparameter oder für die aktuelle Berechnung irrelevant sein. Außerdem kann diese Variable ein primärer oder ein sekundärer Eingabe- bzw. Ergebnisparameter sein. Es gelten hier folgende Definitionen:

Ein primärer Eingabeparameter ist ein Parameter, der vom Anwender vorgegeben werden muss.

Ein sekundärer Eingabeparameter ist ein Parameter, der vom Programm für die Hauptrechnung als Eingabewert benötigt wird, aber nicht mehr vom Anwender eingegeben werden muss, weil er durch die Eingabe der primären Eingabeparameter bereits eindeutig bestimmt ist.

Ein irrelevanter Parameter ist eine im Programm implementierte Variable, deren Wert für die aktuell simulierte Lagervariante keinerlei Bedeutung hat, weder als Eingabe noch als Ergebnisparameter.

Primäre Ergebnisparameter sind alle die Daten, die durch die Hauptrechnung im Solver berechnet werden und aus denen sich dann alle anderen evtl. interessierenden Ergebnisse relativ einfach berechnen lassen.

Sekundäre Ergebnisparameter sind alle die Daten, die sich aus den Eingabeparametern und den primären Ergebnisparametern mit relativ geringem Aufwand ohne erneute Hauptrechnung berechnen lassen.

Die Unterscheidung der implementierten Variablen des Programms nach diesen Klassifizierungskriterien ist deswegen erforderlich, weil die Daten je nach Zugehörigkeit zu einer dieser Klassifizierungen an verschiedenen Stellen des Programms unterschiedlich behandelt werden. Dazu hier die wesentlichen Beispiele:

In den Menüs des PreProzessors werden ausschließlich primäre Eingabeparameter abgefragt.

Alle sekundären Eingabeparameter werden im PreProzessor nach der Eingabe der primären Eingabeparameter berechnet. Für die "technischen" Parameter wird das erledigt durch die Routine "Komplettieren" für die sekundären Steuerparameter erledigen das die Routinen "AktualRegister" und "Muster".

Bei der Eingabe der möglicherweise zeitlich variablen Eingabeparameter werden nur die abgefragt, die auch wirklich zeitlich variable sind und deshalb in Form einer Tabelle für jeden einzelnen Zeitpunkt manuell eingegeben oder aus einer Datei eingelesen werden müssen.

Bei der Sicherung der Eingabe- und Ergebnisdaten in einer Datei zur späteren Weiterbearbeitung, zur späteren Auswertung oder zur Archivierung werden nur die primären Eingabe- und Ergebnisparameter gespeichert, weil alle anderen Daten daraus leicht reproduziert werden können und so Speicherplatz gespart wird.

Alle sekundären Ergebnisparameter werden im PostProzessor erst dann erzeugt, wenn sie durch den Anwender im Rahmen der Auswertung der Ergebnisse über ein Untermenü abgefragt werden oder für eine grafische Darstellung eines Teilergebnisses angefordert werden. Diese sekundären Ergebnisse können dann evtl. zur Dokumentation oder zur sonstigen Weiterverarbeitung in externen Dateien gespeichert werden. Programmintern werden diese Daten jedoch nicht gespeichert, sondern bei jeder Anforderung neu berechnet.

Die Merkmale der Parameter, primärer Eingabe- oder Ausgabeparameter oder irrelevant zu sein, wird in einem Satz sekundärer Steuerparameter verwaltet, die in dem Common-Block "common/Datenregister/" abgelegt sind. Siehe dazu Abschnitt 3.3.2.2.

Einige Beispiele für Eingabe- bzw. Ergebnisparameter und die Codierung ihres Merkmals im zugehörigen Steuerparameter:

Der primäre Steuerparameter Theo gibt an, nach welcher Theorie gerechnet werden soll und wird immer vom Programm abgefragt. Deshalb ist der zugeordnete sekundäre Steuerparameter immer mit dem Wert Theo_0 = 1 belegt. Die Belegung des Parameters Theo_0 erfolgt in der Routine "Anfangsdaten".

Der skalare Parameter PRand1 enthält den Wert für den dimensionslosen Druck am Lagerrand. Dieser Parameter wird immer vom Programm abgefragt und ist deshalb immer ein primärer Eingabewert. Deshalb ist auch dieser zugeordnete Steuerparameter immer mit dem Wert PRand1_0 = 1 belegt. Die Belegung des Parameters PRand1_0 erfolgt in der Routine "Anfangsdaten".

Das Datenfeld P(NZ,NX,NT) enthält die Werte für die Druckverteilung im Schmierspalt über die Zeit. Diese Daten sind immer das Ergebnis der Hauptrechnung im Solver und sind deshalb auch immer primäre Ausgabeparameter. Deshalb ist der zugeordnete Steuerparameter permanent mit dem Wert P_0 = 2 belegt. Die Belegung des Parameters P_0 erfolgt in der Routine "Anfangsdaten".

Der skalare Parameter UnLa enthält den dimensionslosen Betrag der Unrundheit der Lagerschale über den Umfang. Wenn eine Unrundheit angenommen wird (Bedingung: Schale=2), dann ist der Parameter UnLa ein primärer Eingabeparameter und der zugeordnete Steuerparameter nimmt den Wert UnLa_0 = 1 an. Wenn eine ideal zylindrische Lagerschale angenommen wird (Bedingung: Schale=1), dann wird keine Angabe für den Betrag der Unrundheit benötigt und der Parameter ist irrelevant. Dann nimmt der zugeordnete Steuerparameter den Wert UnLa_0 = 0 an. Die Belegung des Parameters UnLa_0 erfolgt in der Routine "AktualRegister".

ERLÄUTERUNG: Wenn im Hauptmenü " Festlegungen zur Theorie, zum Berechnungsverlauf und zum Lagertyp" die Bedingung "Lagerschale ideal zylindrisch und starr" (Schale=1) festgelegt wurde, wird grundsätzlich angenommen, dass die Lagerschale einen ideal zylindrischen Querschnitt aufweist. Die Variable UnLa ist dann irrelevant und kann mit jedem beliebigen Wert belegt sein. Dieser Wert wird vom Programm nicht zur Kenntnis genommen. Diese Variable erscheint dann auch nicht an der Programmoberfläche und kann auch nicht bearbeitet werden.

Wenn im selben Hauptmenü die Bedingung "Lagerschale nur mit Formabweichungsfunktionen" (Schale=2) festgelegt wurde, wird grundsätzlich angenommen, dass die Lagerschale von der ideal zylindrischen Form abweicht und der Betrag der Abweichung wird durch den Parameter UnLa festgelegt. Die Lagerschale kann in diesem Fall aber trotzdem einen ideal zylindrischen Querschnitt aufweisen, nämlich dann, wenn UnLa=0 gesetzt wird.

Beide Festlegungen führen zu dem gleichen Ergebnis, auch wenn sie aus verschiedenen Eingabedatensätzen hervor gehen.

Das Datenfeld So(NT) enthält die Beträge der dimensionslosen Lagerbelastung über die Zeit. Wenn aus einer vorgegebenen Wellenverlagerung die Druckverteilung im Lager und daraus die resultierende Lagerbelastung berechnet wird (Bedingung: Last=1), ist der Parameter So ein primärer Ergebnisparameter und der zugeordnete Steuerparameter nimmt den Wert So_0 = 2 an. Wenn aber aus einem vorgegebenen zeitlich variablen Kraftverlauf So(NT) die Verlagerungsbahn berechnet werden soll (Bedingung: Last=2 und Dynamic=2 und LastVar=2 oder =3), ist das Datenfeld So(NT) ein primärer Eingabeparameter und der zugeordnete Steuerparameter nimmt den Wert So_0 = 1 an. Dann ist das Feld der Lagerbelastungen für jeden Zeitpunkt einzugeben. Wenn der Betrag der Lagerbelastung als zeitlich konstanter Wert vorgegeben werden soll (Bedingung: (Last=2 und Dynamic=1), fragt das Programm im Menü konstante Parameter den Wert für die konstante Lagerbelastung ab und speichert diesen zunächst in der Variablen So_k. Da der Solver intern eine vorgegebene Lagerbelastung immer aus dem Feld So(NT) abfragt, füllt der PreProzessor programmintern das Feld So(NT) mit dem Wert So_k. So wird das Feld So(NT) zu einem sekundären Eingabeparameter und der zugeordnete Steuerparameter nimmt den Wert So_0 = -1 an. Die Belegung des Parameters So_0 erfolgt in der Routine "AktualRegister".

zurück  weiter

3.3.4 Arbeiten mit dimensionslosen und dimensionsbehafteten Parametern

In der hydrodynamischen Schmiertheorie hat es sich bewährt, mit dimensionslosen Größen zu arbeiten, basierend auf dem Ähnlichkeitsgesetz, das durch die Sommerfeldzahl So gegeben ist. Sie ist definiert durch

Die Sommerfeldzahl stellt die dimensionslos gemachte Lagerbelastung eines hydrodynamisch geschmierten Gleitlagers dar. Analog der Lagerbelastung können auch alle anderen Lagerparameter, die nicht Bezugsparameter sind, in geeigneter Weise dimensionslos gemacht werden. Die Definitionen aller dimensionslosen Parameter und die sich daraus ergebenden dimensionslosen Gleichungen für die Parameter untereinander sind angegeben im Abschnitt 2.2 "Dimensionslose Darstellung des Lagers".

Ein Vorteil der Arbeit mit dimensionslosen Parametern und Gleichungen für die Programmierung besteht unter anderem darin, dass man mit reinen Zahlengleichungen im Programm operieren kann und sich dabei zunächst in keiner Weise um die später verwendeten Maßeinheiten der dimensionsbehafteten physikalischen Parameter kümmern muss.

Außer mit den 3 dimensionsbehafteten Bezugsparametern Wellendurchmesser d, dynamische Viskosität η und Bezugswinkelgeschwindigkeit ωb arbeitet das Programm intern ausschließlich mit dimensionslosen Werten. Der Anwender kann neben den dimensionslosen Daten aber auch mit den dimensionsbehafteten Daten an der Programmoberfläche arbeiten. Wird ein dimensionsbehafteter Wert an der Programmoberfläche eingegeben, wird er sofort in den entsprechenden dimensionslosen Wert umgerechnet und als solcher gespeichert. Analog werden alle angezeigten oder anderweitig ausgegebenen dimensionsbehafteten Daten erst zum Zeitpunkt ihrer Anzeige bzw. Ausgabe aus dem entsprechenden dimensionslosen Wert berechnet.

Mit welchen Daten an der Programmoberfläche gearbeitet wird, wird durch den primären Steuerparameter Dim festgelegt. Siehe dazu ausführlich in der Bedienanleitung Abschnitt 4.4.2.19.

zurück  weiter

3.3.5 Arbeiten mit zeitlich variablen Parametern

Zur Simulation eines Lagers berechnet das Programm SIRIUS die Verteilung des Schmierfilmdrucks und weiterer Lagerparameter immer über mehrere Zeitpunkte (mindestens 2 Zeitpunkte). Das tut es auch, wenn nur ein stationärer (zeitlich unveränderlicher) Zustand des Lagers simuliert werden soll.

Neben der größeren Anzahl zeitlich konstanter Parameter gibt es im Programm SIRIUS ca. 40 zeitlich variablen Parametern. Alle Parameter, die im Programm zeitlich variabel sein können, werden programmintern als Felder abgespeichert, in denen die Eingabe- bzw. Ergebnisdaten für jeden einzelnen Zeitpunkt der Berechnung abgespeichert werden.

Von den möglicherweise zeitlich variablen primären Eingabeparametern werden im konkreten Fall aber meist nur einige wenige tatsächlich auch als variabel angenommen und müssen für jeden einzelnen Zeitpunkt eingegeben werden. Um nicht auch noch die aktuell zeitlich konstanten Parameter für jeden Zeitpunkt eingeben zu müssen, wurde zu jedem zeitlich variablen Parameter Xyz, der evtl. primärer Eingabeparameter sein kann, ein entsprechender konstanter Parameter mit der Bezeichnung Xyz_k definiert. In Abhängigkeit von der Festlegung der primären Steuerparameter Dynamic, SchrittVar, OmegaVar, VerlagVar, LastVar, KantVar und BiegVar fragt dann das Programm im Hauptmenü "Eingeben bzw. ändern der konstanten Parameter" den Parameter Xyz_k bzw. im Hauptmenü "Eingeben bzw. ändern der zeitabhängigen (variablen) Parameter" das Feld des Parameters Xyz ab. Auf diese Weise kann der Aufwand der Dateneingabe oft erheblich reduziert werden. Falls ein potentiell variabler Parameter zunächst als konstanter Parameter Xyz_k eingegeben wurde, füllt das Programm anschließend das Feld Xyz mit diesem Wert auf. Während der Hauptrechnung betrachtet das Programm alle potentiell zeitlich variablen Parameter als tatsächlich zeitlich variabel und greift ausschließlich auf die Felder der zeitlich variablen Parameter zu.

Die Felder der zeitlich variablen Parameter sind im COMMON-Block "common/variableParameter/" abgelegt. Die entsprechenden aktuell zeitlich konstanten Parameter sind im COMMON-Block "common/konstVarParameter/" als skalare Variablen abgelegt. Welcher dieser Parameter dann im entsprechenden Eingabemenü abgefragt und später im Ergebnisdatensatz ausgegeben wird, steuern die zugehörigen sekundären Steuerparameter des Common-Blocks /common/Datenregister/". Siehe dazu Abschnitt 3.3.2.2.

HINWEIS: Ist ein potentiell zeitlich variables Parameterfeld, z.B. Kant(NT), in der aktuellen Lagervariante zeitlich konstant, wird der entsprechende konstante Eingabeparameter Kant_k zum primären Eingabeparameter und im PreProzessor abgefragt. Dieses Merkmal ist codiert in dem zugehörigen sekundären Steuerparameter mit Kant_k0=1. Das Parameterfeld Kant(NT) wird dann zum sekundären Eingabeparameter. Dieses Merkmal ist codiert in dem zugehörigen sekundären Steuerparameter mit Kant_0=-1.

Ist das variable Parameterfeld, z.B. Kant(NT) aktuell tatsächlich ein zeitlich variabler Parameter, wird dieser Parameter zum primären Eingabeparameter und im PreProzessor abgefragt. Dieses Merkmal ist codiert im zugehörigen sekundären Steuerparameter mit Kant_0=1. Der entsprechende konstante Parameter Kant_k wird dann irrelevant. Dieses Merkmal ist codiert im zugehörigen sekundären Steuerparameter Kant_K0=0.

Es gibt noch einen weiteren COMMON-Block "common/aktuelleVarParameter/" zum Zwischenspeichern einzelner Werte zeitlich variabler Parameter. Hier werden die Werte der variablen Parameter zwischengespeichert, die für den aktuell bearbeiteten Zeitpunkt JT gelten. Der aktuelle Wert des zeitlich variablen Parameters Xyz(JT) wird mit Xyz_Ak bezeichnet.

Es gibt noch weitere Felder zeitlich variabler Parameter. Das sind die Felder P(NZ,NX,NT) für die Verteilung des Schmierfilmdrucks, PPu(NTa,NT) für die Schmiertaschendrücke, QPu(NPu,NT) für die Pumpenölströme, PTa(NTa,NT) für die Schmiertaschendrücke und QVe(NVe,NT) für Ölströme in den Verbindungsleitungen. Diese sind im COMMON-Block "common/DruckZeit/" abgelegt. Da diese Parameter immer Ergebnisparameter sind und damit immer zeitlich variabel, sind im Programm für diese Parameter keine zeitlich konstanten Variablen vereinbart.

zurück  weiter

3.3.6 Die Parameter zur Beschreibung des peripheren Universal-Schmiermittel-Versorgungssystems

Neben den Parametern, die das eigentliche Lager beschreiben, gibt es einen komplexen Datensatz aus Steuerparametern und technischen Parametern, die das periphere Universal-Schmiermittel-Versorgungssystem abbilden. Diese Parameter sind abgelegt in den Common-Blöcken "common/Schmierung/", "/common/Geraetevarianten/" und zum Teil in "common/DruckZeit/". Dem normalen Programmbenutzer bleibt das Studium dieser Datenstruktur im Wesentlichen erspart. Ihm präsentiert sich die Programmoberfläche in einer hoffentlich wesentlich leichter verständlichen Form:

Das sind die primären Eingabedaten für das Schmiermittel-Versorgungssystem des Demonstrationsbeispiels "Demo21", dessen bereits recht komplexe Struktur grafisch im Bild 4.025 dargestellt ist.

Bild 4.025: Prinzipskizze einer möglichen Variante des externen Schmiermittel-Versorgungssystems

Die Aktionen zur Eingabe werden ausführlich im Abschnitt 4.4.9 "Hauptmenu "Universal-Schmiermittel-Versorgungssystem" beschrieben. Wer aber evtl. das Programm erweitern will, z.B. durch einen weiteren Gerätetyp, der muss sich eingehend mit der Systematik dieser Datenstruktur vertraut machen, denn sie besitzt einige Besonderheiten. Deshalb wird das Datensystem in den nachfolgenden Unterabschnitten 3.3.6.1 bis 3.3.6.4 ausführlich erläutert.

zurück  weiter

3.3.6.1 Die Beschreibung der Schmiermittelpumpen

Die NPu Schmiermittelpumpen sind Konstantpumpen mit Druckbegrenzung (siehe Abschnitt 2.1.6.1). Um ihre idealisierten Betriebskennlinien darzustellen, werden lediglich die 2 Felder der maximalen Pumpendrücke PPuMax(NPu) und der maximalen Pumpenölströme QPuMax(NPu) als primäre Eingabeparameter benötigt. Diese Parameter werden als zeitlich konstante Parameter angenommen. Die tatsächlichen Pumpendrücke und -ölströme sind zeitlich variable primäre Ergebnisparameter und werden in den Feldern PPu(NPu,NT) und QPu(NPu,NT) abgelegt.

Programmintern gibt es dann noch das Feld von Steuerparametern PuVar(NPu). In ihm ist codiert, auf welchem Ast der Kennlinie der aktuelle Betriebspunkt der jeweilige Pumpe gerade liegt (siehe Bild 3.14).

Bild 3.14: Betriebskennlinie einer Schmiermittelpumpe

Fördert die Pumpe JPu aktuell den maximalen Ölstrom in das Lager QPu(JPu,JT)=QPuMax(JPu), dann wird dieser Betriebszustand mit PuVar(JPu)=1 codiert. Arbeitet die Pumpe aktuell als druckgeregelte Pumpe PPu(JPu,JT)=PPuMax(JPu), dann wird dieser Betriebszustand mit PuVar(JPu)=2 codiert. Mit Hilfe dieses Steuerparameters kann das Programm die geeignete Gleichung in die Koeffizientenmatrix für die Hauptrechnung schreiben.

zurück  weiter

3.3.6.2 Die verfügbaren Gerätetypen

Als Geräte werden hier die hydraulischen Bauteile bezeichnet, die in den Verbindungsleitungen zwischen den Pumpen und den Schmiertaschen angeordnet sind und den Schmiermittelstrom beeinflussen. Jeder Gerätetyp benötigt seine eigene Anzahl unterschiedlicher physikalisch-technischer Parameter zur Beschreibung seiner Wirkungsweise. Um nicht bei jeder Erweiterung einen neuen Satz von Variablen in das Programm einführen zu müssen, werden hier die Daten mit verschiedenster Bedeutung in einigen wenigen Datenfeldern gemeinsam abgelegt. Durch entsprechende Steuerfelder kann dann das Programm die Bedeutung der einzelnen Werte in den Feldern entschlüsseln und so die richtigen Gleichungen aufstellen.

Aktuell sind NTyp=6 verschiedene Gerätetypen im Programm implementiert und es könnten noch weitere ergänzt werden. Die Namenbezeichnungen der Gerätetypen sind als Zeichenketten in dem Feld BezTyp(NTyp) fest abgelegt und die Anzahl der erforderlichen physikalisch-technischen Parameter zur Beschreibung des Geräteverhaltens in einem weiteren Feld NPaTyp(NTyp):

Die Reihenfolge der abgelegten Bezeichnungen ist gleichzeitig die Nummerierung der Gerätetypen. Entsprechend dazu sind in 4 weiteren 2-dimensionalen Feldern die Zeichenketten zur Beschreibungen der einzelnen Parameter abgelegt:

Das Feld BezPa(NTyp,NPaTyp) enthält alle Kurzbeschreibungen der einzelnen Parameter.

Das Feld SymbPa(NTyp,NPaTyp) enthält alle Symbole zur Bezeichnung der einzelnen Parameter in dimensionsloser Form.

Das Feld SymbPaDim(NTyp,NPaTyp) enthält alle Symbole zur Bezeichnung der einzelnen Parameter in dimensionsbehafteter Form.

Das Feld DimPa(NTyp,NPaTyp) enthält alle Maßeinheiten der einzelnen dimensionsbehafteten Parameter.

Z.B. hat das Feld SymbPa folgenden fest vorgegebenen Inhalt:

Diese 6 Felder zur Beschreibung der aktuell implementierten Gerätetypen sind im Programm fest vorgegeben und können vom Anwender nur durch Zugriff auf den Quelltext verändert werden. Sie werden in der Routine "Anfangsdaten" definiert.

WARNUNG: Es wird dringend davon abgeraten, die Reihenfolge der Gerätetypen zu verändern, weil sonst ältere Datensätze fehlinterpretiert werden. Auf diese Reihenfolge wird in verschiedenen Routinen aufgebaut, so dass eine Änderung dieser Reihenfolge leicht zu schwerwiegenden Programmfehlern führen kann.

Tipp: Sollte ein bereits implementierter Gerätetyp in einer verbesserten Version neu implementiert werden, ist es möglicherweise besser, diesen als einen neuen Typ hinten anzufügen. Die alte Version könnte dann wahlweise stillgelegt werden, indem sie aus den Eingabemenüs gestrichen wird, oder zur weiteren Nutzung mit alten Datensätzen weiterhin aktiv bleiben.

Soll ein weiterer Gerätetyp in das Programm implementiert werden, brauchen nur diese Datenfelder und die Parameter NTyp und evtl. NPaMax erweitert werden und dem Programm stehen an der Nutzeroberfläche alle diese Daten zur Verfügung. Die eigentliche und wesentlich schwierigere Arbeit besteht dann allerdings darin, in die Routinen "KoMa4" bzw. "KoMa4_pack" die entsprechenden Befehle einzufügen, die anhand dieser Daten und der daraus abgeleiteten Gerätevarianten die richtigen Gleichungen in die Koeffizienten Matrix zur Hauptrechnung einfügen.

zurück  weiter

3.3.6.3 Die Beschreibung der Gerätevarianten

Als Gerätevarianten werden hier konkrete Gerät bezeichnet, die beschrieben werden durch einen Gerätetyp und einen dazu passenden Satz physikalisch-technischer Parameter. Es können maximal NTaMax verschiedene Gerätevarianten vereinbart werden. In einem Schmiersystem können Gerätevarianten verschiedenen Typs, aber auch mehrere Gerätevarianten gleichen Typs mit verschiedenen Werten der zugehörigen physikalischen Parameter vereinbart werden. Eine Gerätevariante kann in mehreren Verbindungsleitungen angeordnet werden. Die Nummerierung der Gerätevarianten bleibt dem Anwender überlassen. Sie ergibt sich aus der Reihenfolge der Eingabe, kann aber auch umsortiert werden. Siehe dazu Abschnitt 4.4.9.2.

Die Felder TypVar(NTaMax) und PaVar(NTaMax,NPaMax) zur Definition von NVar=6 Gerätevarianten haben für das hier gezeigte Demonstrationsbeispiel "Demo21" folgenden Inhalt:

HINWEIS: Die nicht benötigten Koeffizienten der Felder sind undefiniert, d.h. hier können beliebige Werte stehen, die vom Programm ignoriert werden.

In dem Feld PaVar werden grundsätzlich nur die dimensionslosen Werte abgespeichert, deshalb unterscheiden sich diese Werte von den oben im Menü dargestellten Werten, die vor ihrer Anzeige in dimensionsbehaftete Werte umgerechnet wurden.

Die hier dargestellten Werte sind stark gerundet, um die Tabelle nicht zu groß werden zulassen.

zurück  weiter

3.3.6.4 Die Abbildung der Struktur des Wirkschaltplans des Schmiersystems

Die Gestaltung des peripheren Schmiermittel-Versorgungssystems kann sehr komplex und variantenreich abgebildet werden. Eine Schlüsselfunktion hat hier das Steuerfeld Ve(3,NVe). Mit ihm werden die Verbindungen zwischen den Schmiermittelpumpen und den Schmiertaschen über die Verbindungsleitungen dargestellt. Außerdem wird hier angegeben, mit welcher Gerätevariante zur Regelung der Schmiermittelströme die einzelnen Verbindungsleitungen ausgerüstet sind.

Der Anwender bekommt dieses Feld im Hauptmenü "Universal-Schmiermittel-Versorgungssystem" des PreProzessors in einer leichter verständlichen Form zu Gesicht. Der folgende Menüausschnitt zeigt die Daten dieses Feldes für das Demonstrationsbeispiel "Demo21":

Die Spalte JPu im Menü bildet die 1.Zeile des Feldes Ve, die Spalte JTa bildet die 2.Zeile und die Spalte JVar die 3.Zeile. So hat das Steuerfeld Ve(3,NVe) für dieses Beispiel folgendes Aussehen:

Mit Hilfe dieser Matrix kann im Programm gezielt auf bestimmte Werte in Feldern zugegriffen werden, deren Index nicht explizit bekannt ist. So haben im Programmcode z.B. folgende Ausdrücke folgende Bedeutungen:

x = PPu(Ve(1,7)) bedeutet: x ist der Druck der Pumpe, die mit der 7.Verbindungsleitung verbunden ist. Das Programm ruft in diesem Beispiel den Druck der Pumpe Nr. 3 auf. D.h. x=PPu(JPu=3)
x = PTa(Ve(2,7)) bedeutet: x ist der Druck in der Schmiertasche, die ebenfalls mit der 7.Verbindungsleitung verbunden ist, welche in diesem Beispiel die Schmiertasche 6 ist. Damit sind also die Pumpe Nr.3 mit der Schmiertasche Nr.6 über die Leitung Nr. 7 miteinander verbunden.
j = TypVar(Ve(3,7)) bedeutet: In der Verbindungsleitung Nr. 7 ist ein Stromregelgerät des Typs Nr. 3 angeordnet. Das sind nach der programminternen Nummerierung der Gerätetypen eine Blende und eine Kapillare in Reihenschaltung. Das Programm ermittelt also die Nummer des Gerätetyps der Gerätevariante, die in die Leitung Nr. 7 eingebaut ist und speichert sie in j. Die Nummer der Gerätevariante JVe=Ve(3,7) wird dabei explizit nicht ermittelt.

So beschreibt das oben gezeigte Beispiel des Steuerfeldes Ve in maschinenlesbarer Form ein peripheres Schmiermittel-Versorgungssystem, das eine Struktur gemäß Bild 4.025 aufweist.

Bild 4.025: Prinzipskizze einer möglichen Variante des peripheren Universal-Schmiersystems

Der normale Anwender braucht sich auch um dieses Steuerfeld keine Gedanken zu machen. Die Kenntnis dieses Codierungsinstruments wird erst interessant, wenn man einen weiteren Gerätetyp in das Programm implementieren möchte.

zurück  weiter

3.3.7 Zusammenfassung der globalen Programmparameter in Common-Blöcken

Um den Überblick über alle im Programm SIRIUS verwendeten Variablen zu behalten, wurden grundsätzlich alle verwendeten Variablen am Anfang jeder Routine durch eine Format-Anweisung spezifiziert, obwohl die Programmiersprache FORTRAN das nicht zwingend vorschreibt. Außerdem wurden alle globalen Variablen in COMMON-Blöcke zusammengefasst abgelegt. Globale Variablen sind hier Daten, die in mehreren Routinen benötigt werden. In SIRIUS werden sie in den verschiedenen Routinen auch gleichlautend bezeichnet. Auch das wird nicht von der Programmiersprache gefordert. Es erleichtert aber erheblich die Lesbarkeit des Quellcodes.

COMMON-Blöcke sind eine spezielle Art der Vereinbarung von Speicherbereichen in FORTRAN, auf die verschiedene Routinen direkt zugreifen können. Ursprünglich stammt diese Idee aus der Zeit, als Speicherplatz noch sehr knapp war und so der gleiche Speicherplatz in verschiedenen Routinen mehrfach genutzt werden konnte. Hier werden die COMMON-Blöcke dazu genutzt, auf eine gemeinsame Datenbasis durch die verschiedenen Routinen direkt zuzugreifen. Dadurch brauchen globale Variablen, die in einer mehrfach untergeordneten Routine benötigt werden, nicht durch alle übergeordneten Routinen geschleust werden. Dabei wurden Datenblöcke nach funktionalen Kriterien zusammengefasst, so dass die Daten der einzelnen Blöcke in etwa in den gleichen Routinen benötigt werden, was natürlich nicht generell der Fall ist.

In den einzelnen Routinen werden nur die COMMON-Blöcke spezifiziert, die auch benötigt werden und hier wiederum nur die Variablen mit ihrer einheitlichen Bezeichnung, auf die die Routine zugreift. Da alle Variablen eines Common-Blocks immer in der gleichen Reihenfolge lückenlos aufgeführt werden müssen, werden aktuell nicht benötigte Variablen mit Dummy-Namen aufgeführt in der Art xx1,xx2,...yy1,yy2,...,nn1,nn2,...,mm1,mm2,..., so dass in jeder Routine sofort zu erkennen ist, welche Daten des jeweiligen COMMON-Blocks in der aktuellen Routine benötigt werden.

Beispiel:

Vollständige Belegung des Common-Bocks "Steuerparameter"

      common/Steuerparameter/
     * Status,Theo,Last,Vollum,Sym,Welle,Schale,Kante,Biege
     *,Dynamic,SchrittVar,OmegaVar,VerlagVar,LastVar,KantVar,BiegVar
     *,Dim,Versatz,Sym3,NSym3

Aktuelle Belegung in der Routine "FilmDruck1"

      common/Steuerparameter/
     * Status,Theo,mm3,Vollum,Sym,Welle,Schale,Kante,Biege
     *,mm11,mm12,mm13,mm14,mm15,mm16,mm17
     *,mm18,Versatz

Zur Arbeit mit COMMON-Blöcken siehe [8, Kapitel 6.1]. Um einen Überblick über alle in SIRIUS vereinbarten COMMON-Blöcke und die Reihenfolge der darin enthaltenen Parameter zu erhalten, sind alle Blöcke mit ihrem vollständigen Inhalt im Hauptprogramm "SIRIUS" aufgelistet.

Folgende COMMON-Blöcke wurden vereinbart:

common/Text/
Enthält die 3 Textvariablen "Datum", "Titel" und "Version".

common/Steuerparameter/
Enthält alle primären Steuerparameter, die im PreProzessor im Hauptmenü "Festlegungen zur Theorie, zum Berechnungsverlauf und zum Lagertyp" festgelegt werden. Außerdem ist hier der sekundäre Steuerparameter "Status" abgelegt.

common/Steuerfelder/
Enthält die Steuerfelder "KX", "KZ" und "NG". Im Feld KX ist die Anordnung der Schmiertaschen codiert. In den Feldern KX, KZ sind außerdem die Nummern der zu verwendenden Differenzengleichungen codiert, die zur Aufstellung des linearen Gleichungssystems zur Berechnung der Druckverteilung im Lager benötigt werden. Im Feld NG sind die Nummerierung der Gleichungen des Gleichungssystems abgelegt. Mit NGlei ist hier außerdem die Anzahl der Gleichungen des Gleichungssystems angegeben.

common/Datenregister/
Enthält alle sekundären Steuerparameter vom Typ Xyz_0, die die zugehörigen Parameter Xyz als primäre oder sekundäre Eingabe- oder Ergebnisparameter oder als irrelevante Parameter klassifizieren. Siehe dazu Abschnitt 3.3.3.

common/Anzeigeauswahl/
Enthält nur das Steuerfeld "Anzeigen", mit dem auch die Auswahl der anzuzeigenden variablen Parameter gesteuert wird. Die manuelle Auswahl erfolgt mit der Aktion -92- im Hauptmenü des PostProzessors und wird durch die Routine "AuswahlAnzeige" ausgeführt.

common/interneParameter/
Enthält die internen Hilfswerte, die die nummerische Rechnung beeinflussen und vom Anwender möglichst nicht verändert werden sollen, aber trotzdem im Untermenü "Bearbeiten der programminternen Parameter" ohne Änderung des Quelltextes verändert werden können.

common/konstanteParameter/
Enthält zeitlich konstante Eingabe- und Ergebnisparameter.

common/VersatzLager/
Enthält die technischen Parameter, die für die Sondervariante "Versetzte Lagerabschnitte" (Steuerparameter: Versatz=2 oder =3) benötigt werden. Siehe dazu die Abschnitte 2.1.2.16 bzw. 2.2.2.16 und 4.4.2.7 und 4.4.4.11.

common/Belastungsfunktionen/
Enthält die Parameter, die benötigt werden, um einige zeitabhängige Eingabeparameter nicht punktweise eingeben zu müssen, sondern sie mit wenigen Daten als analytisch gegebene Funktionen zu definieren, um so die Eingabe zu erleichtern. Das betrifft die Funktionen der Verlagerungsbahn, des zeitlichen Verlaufs der Lagerbelastung, der Wellenverkantung, der Wellenbiegung und einer pendelnden Drehbewegung der Welle.

common/SpaGeo/
Enthält die Ergebnisse der Berechnung der Spaltgeometrie für den aktuellen Zeitpunkt JT.

common/ElastVerform/
Enthält die erforderlichen Eingabe- und Ergebnisparameter für die Berücksichtigung elastischer Verformung der Lagerschale infolge des Schmierfilmdrucks.

HINWEIS: Für diese Variante ist zwar inzwischen die erforderliche Datenstruktur im Programm SIRIUS implementiert. Die Berechnung ist aber noch nicht freigegeben, da bisher noch kein zuverlässiger und stabiler Berechnungsalgorithmus gefunden wurde.

common/Schmierung/
Enthält Parameter zur Definition des peripheren Schmiermittel-Versorgungssystems.

common/Gerätevarianten/
Enthält ebenfalls Parameter zur Definition des peripheren Schmiermittel-Versorgungssystems, speziell die Parameter zur Beschreibung der stromregelnden Geräte in den Verbindungsleitungen.

common/variableParameter/
Enthält zeitlich variable Lagerparameter.

common/konstVarParameter/
Enthält analog zu den Feldern Xyz(NT) des COMMON-Blocks "common/variableParameter/" die skalaren Variablen Xyz_k, in denen bei Bedarf die entsprechenden konstanten Werte eingegeben werden können. Ausführlich dazu siehe Abschnitt 3.3.5.

common/aktuelleVarParameter/
Dient als Zwischenspeicher für die variablen Parameter Xyz_Ak= Xyz(JT) des aktuellen in der Berechnung befindlichen Zeitpunktes JT.

common/Druck/
Dient als Zwischenspeicher für die aktuellen variablen Ergebnisparameter P_Ak(NZ,NX)=P(NZ,NX,JT), H_Ak(NZ,NX), FH_Ak(NZ,NX) und PT_Ak(NZ,NX) des aktuellen in der Berechnung befindlichen Zeitpunktes JT.

common/DruckZeit/
Enthält die kompletten Felder der primären, zeitlich variablen Ergebnisparameter P(NZ,NX,NT), PPu(NPu,NT), QPu(NPu,NT), PTa(NTa,NT) und QVe(NVe,NT).

common/Bezugsparameter/
Enthält die 4 Bezugsparameter Durchmesser d, relatives Lagerspiel S, dynamische Viskosität η und Bezugswinkelgeschwindigkeit ωb, mit denen die dimensionslosen Parameter in dimensionsbehaftete umgerechnet werden können und umgekehrt. Außerdem sind die daraus berechneten, aktuellen Umrechnungsfaktoren für die jeweiligen Parameter enthalten.

HINWEIS: Der 5.Bezugsparameter "relative Lagerbreite" B ist im COMMON-Block "common/konstanteParameter/" abgelegt.

zurück   weiter

.

.

.