zurück   weiter

4.9 Problembehandlung

Der Autor des Programms hat sich schon im eigenen Interesse intensiv darum bemüht, das Programm so anwenderfreundlich wie möglich zu gestalten. Zur Anwenderfreundlichkeit gehört auch die Vermeidung von Programmierfehlern und dem Anwender dabei zu helfen, bei der Arbeit mit dem Programm, eigene Fehler zu vermeiden. Jeder, der schon mal selbst ein umfangreiches Programm geschrieben hat, weiß aber auch, dass es 100% fehlerfreie Programme eigentlich nicht gibt und dass es auch zu viel verlangt ist, vom Anwender zu erwarten, dass er 100% fehlerfrei arbeitet. Deshalb soll mit diesem Kapitel dem Anwender geholfen werden, die Ursachen auftretender Fehler möglichst leicht zu ermitteln und abzustellen.

Es gibt folgende verschiedene Fehlermöglichkeiten im Programm, zu denen hier etwas gesagt werden soll:

1. Kommunikationsfehler des Anwenders mit dem Programm: Es werden falsche Eingaben getätigt, die dazu führen, dass eine Lagervariante beschrieben wird, die technisch nicht möglich ist. Es werden Eingaben getätigt, die gegen programmtechnische Restriktionen verstoßen. Siehe Abschnitt 4.9.1.

2. Überforderung der Lösungsverfahren des Programms: Es werden Datensätze eingegeben, die eine technisch widerspruchsfreie und sinnvolle Lagervariante beschreiben, mit der das Programm aber überfordert ist, eine ausreichend genaue und stabile Lösung zu ermitteln. Siehe Abschnitt 4.9.2.

3. Programmierfehler. Siehe Abschnitt 4.9.3.

4. Fehler, die das Programm nicht erkennt, deren mögliches Auftreten dem Autor aber bekannt ist. Siehe Abschnitt 4.9.4.

Über Fehler, die bei der Arbeit mit GNUPLOT auftreten, wird hier nicht informiert. Das Programm GNUPLOT besitzt eine eigene Dokumentation, in der die Behandlung auftretender Fehlermeldungen nachgelesen werden kann. Das Programmfenster des Programms GNUPLOT (Bild 4.006 Abschnitt 4.2.5) informiert den Anwender über auftretende Fehler.

zurück   weiter

4.9.1 Fehlerquellen bei der Kommunikation des Anwenders mit dem Programm

Es wurde ein recht hoher Aufwand bei der Programmierung betrieben, diese Fehler, so sie auftreten, abzufangen und dem Anwender Hinweise zu liefern, welcher Art der Fehler ist und wie er beseitigt werden kann. Das ist am erfolgreichsten bei den Kommunikationsfehlern möglich.

Die Kommunikationsfehler kann man wieder in 3 Gruppen unterteilen:

1. Einfache Eingabefehler bei der Auswahl einer Aktion oder der direkten Eingabe eines Wertes in einem Menü der Programmoberfläche. Die einfachen Eingabefehler sind in der Regel leicht erkennbar. Das Programm gibt an der Bedienoberfläche bereits die Restriktionen an, die für den jeweiligen Eingabeparameter gelten. Deshalb benötigen diese Fehlermeldungen kaum eine Kommentierung in dieser Bedienanleitung.

Die Fehlermeldungen dieser Kategorie sind im Programm und im Fehlerverzeichnis nummeriert mit den Nummern 001 bis 003.

2. Fehler bei der Ein-oder Ausgabe von Daten in oder aus Textdateien. Die Datenein- und -ausgabe einschließlich Datensicherung kann effektiv über Dateien erfolgen, weil hier schnell eine große Menge Daten übertragen werden kann. Außerdem kann darüber auch ein Datentransfer zu externen Programmen realisiert werden. Insbesondere das Einlesen von Daten, die extern erzeugt wurden, ist eine fehleranfällige Angelegenheit, da das Programm SIRIUS zur fehlerfreien Interpretation der eingegebenen Daten eine bestimmte Struktur des zu lesenden Textes benötigt. Hier können bei Dateien, die extern erzeugt oder auch nur manipuliert wurden, leicht Fehler gemacht werden. Deshalb wurden in die Aktionen des Datentransfers mittels Dateien eine Reihe von Kontrollen eingebaut, die mögliche Fehler frühzeitig abfangen sollen. Die verwendeten Dateien sind generell Textdateien (ASCII-Dateien), die mit einem einfachen Texteditor gelesen und bearbeitet werden können. Das erleichtert die Fehlersuche, weil man z.B. bei einem Lesefehler jederzeit in der Datei nachsehen kann, welche Angaben zu dem Fehler geführt haben. Allerdings kann eine unsachgemäße Manipulation der Dateien mit so einem Editor auch leicht zu Fehlern führen.

Die Fehlermeldungen dieser Kategorie sind im Programm und im Fehlerverzeichnis nummeriert mit den Nummern 101 bis 122.

TIPP: Zu jeder Aktion mit der man eine Datei einlesen kann, gibt es auch eine Aktion, die eine entsprechende Datei ausgeben kann. Falls man also extern erzeugte Daten mittels einer Textdatei einlesen will, ist es sinnvoll, zunächst eine Datei dieses Typs auszugeben, um dann in dieses Muster die entsprechenden Daten einzutragen, z.B. mit einem Excel-Programm, oder man kann anhand dieser Datei die erforderliche Datenstruktur analysieren und eine entsprechende Eingabedatei manuell oder mit Hilfe eines eigens dafür geschriebenen Programms erzeugen.

HINWEIS: Wenn eine Datei mit SIRIUS ausgegeben wurde und anschließend ohne jegliche Änderung mit der komplementären Aktion wieder eingelesen wird, dann sollte beim Einlesen keine Fehlermeldung erscheinen. Erscheint trotzdem eine Fehlermeldung, dann liegt vermutlich ein Programmierfehler im Programm SIRIUS vor.

3. Verzögert erkennbare Eingabefehler: Das sind Fehler, die sich aus einer unzulässigen Kombination von mehreren Eingabedaten ergeben und deshalb erst zu einem späteren Zeitpunkt vom Programm erkannt werden. Sie werden evtl. erst bei einer abschließenden Kontrolle oder auch erst während der bereits laufenden Berechnung festgestellt. Wenn das Programm einen solchen Fehler feststellt, wird die aktuell laufende Berechnung gestoppt und der Anwender mit einer entsprechenden Meldung über den Fehler informiert. Da diese Fehler meist nicht von einer einzelnen Eingabe abhängen, muss der Anwender selbst entscheiden, mit welcher Änderung der Eingabedaten er diesen Fehler behebt. Einen kurzen Hinweis, wie dieser Fehler behoben werden kann, gibt dabei bereits die Fehlermeldung. Ausführlichere Informationen dazu sind dann der Bedienanleitung zu entnehmen im Abschnitt 4.9.5 unter der jeweiligen Fehlernummer. Die Fehlermeldungen dieser Kategorie sind im Programm und im Fehlerverzeichnis nummeriert mit den Nummern 201 bis 222.

zurück   weiter

4.9.2 Probleme der Überforderung der Lösungsalgorithmen

Die anspruchsvollsten Fehlermeldungen sind die, wo durch den Anwender eine an sich physikalisch und technisch sinnvolle und widerspruchsfreie Lagervariante eingegeben wurde, aber mindestens eines der implementierten numerischen Lösungsverfahren überfordert ist, d.h. die Iteration hat nicht zu einer stabilen ausreichend genauen Näherungslösung geführt.

Das heißt nicht, dass damit dieses Problem unlösbar ist. Es gibt in der Regel eine Reihe möglicher Maßnahmen, mit denen das Problem doch noch befriedigend lösbar ist. Das können z.B. sein:

Die folgenden Abschnitte 4.9.2.1 bis 4.9.2.3 beschreiben die bekannten Ursachen, die zur Überforderung der Lösungsverfahren führen, und geben heuristische Hinweise, wie das Problem evtl. gelöst werden kann.

Angezeigt werden diese Probleme durch die Fehlermeldungen 301 und 302.

zurück   weiter

4.9.2.1 Erscheinungen am Druckberganfang, an der Grenze zwischen Kavitation und hydrodynamischem Druckberg im Schmierspalt

Die erweiterte Reynoldssche Differentialgleichung (Theo=2) bildet die Schmiermittelströmung im Schmierspalt sowohl im Druckberg als auch im Kavitationsgebiet ab. Bei den Übergängen zwischen dem Gebiet des Druckbergs und dem Kavitationsgebiet sind 2 verschiedene Erscheinungen zu beobachten, die sinnvoll durch die Begriffe "Druckberganfang" und "Druckbergende" unterschieden werden können. Von einem Druckberganfang spricht man dann, wenn das Schmiermittel aus dem Kavitationsgebiet in den Druckberg strömt. Von einem Druckbergende spricht man dann, wenn das Schmiermittel aus dem Druckberg in das Kavitationsgebiet abfließt. Am Druckbergende gilt die "Bedingung des glatten Abflusses", d.h. die Funktion des Druckverlaufs p(x) ist eine glatte Funktionen, von der mindestens die 1.Ableitung existiert, was günstig für eine numerische Approximation dieser Funktionen ist. Anders verhält es sich am Druckberganfang, wie in Bild 4.137 zu erkennen ist.

Bild 4.137: Druckberganfang und -ende im Schmierspalt

Hier gibt es einen abrupten Übergang, indem sich der Schmierspalt schlagartig fast vollständig mit Schmiermittel füllt. Diese Erscheinung ist vergleichbar mit der Erscheinung, die jeder Autofahrer kennt, wenn er durch ein Pfütze fährt: Es bildet sich vor dem Rad ein Stau der Flüssigkeit, der dann zum Aquaplaning (ein Synonym für hydrodynamische Schmierung) führen kann. Explizit erklärt wird dieses Phänomen durch das Modell der idealen Kavitation [12] (siehe auch [20, Abschnitte 5.5 und 9.3]), welches die Strömungen in den beiden Gebieten mit verschiedenen Gleichungen beschreibt. Derartige Diskontinuitäten in Funktionsverläufen können bei der iterativen numerischen Berechnung leicht zu Problemen führen, was auch im Programm SIRIUS gelegentlich der Fall ist.

Das Modell der erweiterten Reynoldsschen Gleichung (Theo=2) beschreibt sowohl Druckberg als auch Kavitationsgebiet mit einer einzigen im gesamten Schmierspalt differenzierbaren Funktion und kennt explizit weder Druckberganfang noch -ende. Wie in Bild 4.137 aber leicht zu erkennen ist, bildet es trotzdem dieses Phänomen am Druckberganfang recht gut ab, was für die Qualität des Modells spricht, rechentechnisch aber zum Problem werden kann. Je kleiner man für die Berechnung die Mischungskonstante C wählt, umso plötzlicher wird der Übergang vom Kavitationsgebiet zum Druckberg und um so größer wird die Tendenz zur numerischen Instabilität. Je größer man die Mischungskonstante wählt, um so abgerundeter wird der berechnete Funktionsverlauf, um so unschärfer werden die Übergänge zwischen Kavitationsgebiet und Druckberg und die Tendenz zur numerischen Instabilität verringert sich.

Der nachfolgende Abschnitt 4.9.2.2 beschreibt die daraus resultierenden rechentechnischen Konsequenzen und wie man den damit verbundenen Problemen begegnen kann.

zurück   weiter

4.9.2.2 Das numerische Problem am Druckberganfang und Strategien, diese zu vermeiden bzw. zu mindern

HINWEIS: Siehe dazu auch Abschnitt 3.4.6 "Korrekturen zur Dämpfung von Instabilitäten der Druckberechnung" in der Programmbeschreibung.

Das Differenzenverfahren ist anwendbar auf lineare partielle Differentialgleichungen unbeschränkter Funktionen. Die erweiterte Reynoldssche Differentialgleichung (Theo=2) ist nicht linear. Die Funktion des Druckverlaufs P ist außerdem nach unten beschränkt durch die Bedingung P>0. Auf die klassische Reynoldssche Differentialgleichung (Theo=1) ist das Differenzenverfahren direkt anwendbar, während das für die erweiterte Gleichung nicht der Fall ist. Durch die Linearisierung der erweiterten Gleichung (siehe Abschnitt 3.4.1.3) und eine iterative Berechnung des Druckverlaufs aus einer geschätzten Näherung ist es gelungen, dieses effektive Verfahren trotzdem anzuwenden. Das liegt daran, dass sich die erweiterte Reynoldssche Gleichung sowohl im Gebiet des Druckberges als auch im Kavitationsgebiet annähernd wie eine lineare Gleichunge verhält. Lediglich im Grenzbereich zwischen Kavitationsgebiet und Druckberg kommt der nichtlineare Charakter zum Vorschein und verhindert gelegentlich die Konvergenz des iterativen Lösungsverfahrens.

Die Bilder 4.138 bis 4.139 zeigen zunächst ein Beispiel eines stationär belasteten Lagers ohne Schmiernut, bei dem die Berechnung noch stabil ist.

Es wurde hier unter anderem eine Gitterteilung in Umfangsrichtung von NX=120 und eine Mischungskonstante von c=0,04 MPa gewählt. Der vollständige Datensatz ist enthalten in der Datei "Demo25-1.txt" und kann so nachgerechnet werden.

Das Bild 4.138 zeigt in dimensionsloser Form die Druckverteilung P im Schmierspalt (blau) und darunter die Spaltgeometrie H (grün) und die Verteilung der Schmierflüssigkeit HF=H·F (rot).

Bild 4.138: Dimensionslose Druckverteilung P, Spalthöhe H und Flüssigkeitsverteilung HF=H F im Schmierspalt einer stabilen Lösung (Bilddatei: Demo25-1-3d-Abw-P-H-HF-JT=21.png) (Animation: Demo25-1-3d-Abw-P-H-HF.wmv)

Im Bild 4.139 ist zum gleichen Beispiel noch einmal nur die Spalthöhe und die Schmiermittelverteilung dargestellt, weil anhand der Schmiermittelverteilung eine evtl. auftretende Instabilität besser zu erkennen ist, was hier noch nicht der Fall ist.

Bild 4.139: Dimensionslose Spalthöhe H und Flüssigkeitsverteilung HF=H&iddot;F im Schmierspalt einer stabilen Lösung (Bilddatei: Demo25-1-3d-Abw-H-HF-JT=21.png) (Animation: Demo25-1-3d-Abw-H-HF.wmv)

Die Bilder 4.140 und 4.141 zeigen das gleiche Lager mit den gleichen Betriebsbedingungen, außer dass die Mischungskonstante auf den Wert c=0,02 MPa halbiert wurde. Damit ist das Lösungsverfahren überfordert und die Lösung wird instabil. Der vollständige Datensatz ist enthalten in der Datei "Demo25-2.txt" und kann so nachgerechnet werden.



Bild 4.140: Dimensionslose Druckverteilung P, Spalthöhe H und Flüssigkeitsverteilung HF=H·:F im Schmierspalt einer instabilen Lösung (Bilddatei: Demo25-2-3d-Abw-P-H-HF-JT=38.png) (Animation: Demo25-2-3d-Abw-P-H-HF.wmv)



Bild 4.141: Dimensionslose Spalthöhe H und Flüssigkeitsverteilung HF=H·F im Schmierspalt einer instabilen Lösung (Bilddatei: Demo25-2-3d-Abw-H-HF-JT=38.png) (Animation: Demo25-2-3d-Abw-H-HF.wmv)

HINWEIS: Die hier gezeigte Instabilität tritt trotz der im Abschnitt 3.4.6 beschriebenen Korrekturroutinen auf, die die Instabilität vermeiden oder mindestens dämpfen sollen. Ohne diese Routinen würde die hier gezeigte Instabilität früher einsetzen und sich dann auch schneller aufschaukeln.

Anschaulicher als die statischen Bilder sind hier die zugehörigen Animationen des Berechnungsablaufs über 41 Zeitschritte. Nach einer zunächst stabilen Anlaufrechnung sieht man, wie die Instabilität am Druckberganfang ihren Ausgangspunkt hat und dann nicht mehr zur Ruhe kommt. In diesem gezeigten Beispiel ist die Instabilität der Berechnung so gering, dass das numerische Lösungsverfahren noch die internen Genauigkeitskriterien erfüllen kann und deshalb die Berechnungen nicht abbricht und das Programm deshalb auch keine Fehlermeldung ausgibt. Die Animation zum Bild 4.140 zeigt auch, dass hier der Einfluss der Instabilität auf den Druckberg gering ist. Das bedeutet, wenn nur die Tragfähigkeit des Lagers von Interesse ist, kann man eine gewisse Instabilität des Berechnungsverfahrens tolerieren. Stärker wirkt sich diese Instabilität auf die Berechnung der Ölströme aus, die durch den Schmierspalt fließen.

Wenn man aber die Mischungskonstante weiter verkleinert, z.B. auf den Wert c=0.002 MPa, dann schaukelt sich die Iteration dermaßen auf, dass das GMRES-Verfahren zur Lösung des Gleichungssystems nach 300 Iterationsschritten immer noch nicht die geforderten Genauigkeitskriterien erfüllt und die Berechnung mit der Fehlermeldung 301 abbricht:

Die Anzeige des Berechnungsablaufs zeigt hier z.B., dass das Programm im 25.Zeitpunkt die Berechnung wegen ungenügender Konvergenz abbricht und es zeigt die geforderte Genauigkeit das Residuums "normr" und die erreichte Genauigkeit des Residuums "tolb". Hier kannst Du noch einmal entscheiden, ob Du trotzdem weiter rechnen willst, durch Eingabe von j, oder den Abbruch bestätigen durch ENTER. Das Weiterrechnen kann aus verschiedenen Gründen sinnvoll sein:

Speziell während der Anlaufrechnung kann wegen schlechter Anfangswerte, die Berechnung zunächst instabil sein, nach Erreichen des stationären Zustandes sich aber wieder stabilisieren. So kann man evtl. doch noch ein brauchbares Ergebnis erzielen.

Ein weiterer Grund kann sein, dass durch das Weiterrechnen das Programm die zum Zeitpunkt des Abbruchs erzielte Lösung als brauchbare Lösung akzeptiert und abspeichert. So kann man sich nach der Rechnung auch das erzielte Ergebnis des Abbruchzeitpunktes anschauen und evtl. daraus seine Schlüsse ziehen.

In unserem Beispiel hat sich die Berechnung wieder etwas gefangen und konnte so noch einige Zeitpunkte weiterrechnen. Beim Zeitpunkt JT=28 erfolgte aber ein erneuter Abbruch, so dass man diese Berechnung wie erwartet endgültig als gescheitert ansehen kann.


Nicht nur eine große Mischungskonstante sichert eine stabile Lösung. Auch durch eine feinere Gitterteilung in Umfangsrichtung, natürlich zu Lasten einer längeren Rechenzeit, steigt die Leistungsfähigkeit des Berechnungsverfahrens und es können stabile Ergebnisse erzielt werden. Mit dem Demonstrationsbeispiel "Demo25-3" wurde gegenüber dem Beispiel Demo25-2" bei gleichbleibender Mischungskonstante die Gitterteilung von NX=120 auf NX=360 erhöht. Die Bilder 4.142 und 4.143 zeigen die nun wieder stabilen Ergebnisse.

Bild 4.142: Dimensionslose Druckverteilung P, Spalthöhe H und Flüssigkeitsverteilung HF=H·F im Schmierspalt einer stabilen Lösung (Bilddatei: Demo25-3-3d-Abw-P-H-HF-JT=41.png)



Bild 4.143: Dimensionslose Spalthöhe H und Flüssigkeitsverteilung HF=H·F im Schmierspalt einer stabilen Lösung (Bilddatei: Demo25-3-3d-Abw-H-HF-JT=41.png) (Animation: Demo25-3-3d-Abw-H-HF.wmv)

Das Problem möglicher Instabilitäten am Druckberganfang wurde hier zunächst am Beispiel eines Lagers ohne Schmiertaschen erläutert. Üblicher Weise hat ein Gleitlager auch Schmiertaschen und einige liegen in dem Gebiet des Schmierspalts, wo sonst Kavitation herrschen würde. Da der Schmiermittelzufuhrdruck in der Regel höher ist als der Druck im angrenzenden Kavitationsgebiet, stellt eine Schmiertasche auch einen von außen erzeugten Druckberg dar. So bildet sich auch vor jeder Schmiertasche im Kavitationsgebiet ein Druckberganfang, an dem die gleichen Probleme auftreten können, wie oben gezeigt. Es hat sich außerdem gezeigt, dass die Anfälligkeit der Schmiertaschen für numerische Instabilität wächst, je dichter sie hinter der Stelle der minimalen Spalthöhe liegen. Die Maßnahmen zur Vermeidung von numerischen Instabilitäten vor den Schmiertaschen sind die gleichen, wie bereits oben erläutert. Wenn nur die Tragfähigkeit des Druckberges interessiert, kann man Instabilitäten an Schmiertaschen im Kavitationsgebiet tolerieren, solange sie sich nicht in der Weise aufschaukeln, dass sie zum Abbruch der Berechnung führen, weil sie den Druck im Druckberg kaum beeinflussen. Sofern das Lager nur stationär belastet ist, kann man eine Schmiertasche im Kavitationsgebiet auch aus der Berechnung entfernen und so für eine stabile Lösung sorgen. Falls man aber die genauen Ölströme durch das Lager ermitteln möchte, dann ist das nicht sinnvoll. Dann muss man wohl mit einer ausreichend feinen Gitterteilung NX arbeiten.

Die hier beschriebenen Probleme numerischer Instabilitäten treten nur bei Anwendung der erweiterten Reynoldsschen Gleichung (Theo=2) auf. Da die klassische Reynoldssche Differentialgleichung (Theo=1) linear ist, führt das Differenzenverfahren eigentlich immer zu einer Lösung. Die Lösung kann hier nur in Ausnahmefällen auch instabil werden im Zusammenspiel mit den Elementen eines peripheren Schmiermittel-Versorgungssystems, denn auch hier gibt es einige nicht lineare Elemente, die einen instabilen Berechnungsverlauf auslösen können, insbesondere bei instationären Betriebsbedingungen. Dann ist in der Regel eine Verkleinerung der Zeitschrittweiten ΔT angesagt.

zurück   weiter

4.9.2.3 Die iterative Berechnung der Verlagerungsbahn und damit zusammenhängende numerische Probleme

Die Berechnung einer Wellenverlagerung aus einer vorgegebenen Lagerbelastung ist ein iterativer Prozess, der ausführlich im Abschnitt 3.4.7 beschrieben ist. Diese Iteration kann versagen. Dazu ein Beispiel: Das Demonstrationsbeispiel Demo05 (siehe Abschnitt 4.8.5) simuliert ein instationär belastetes hydrodynamisches Lager. Dabei sind alle Eingabedaten so gewählt, dass das Programm über eine Einlaufphase eine stabile Verlagerungsbahn ermitteln konnte. Im Demonstrationsbeispiel Demo05-1 wurde nun die Zeitschrittweite t verdoppelt. Der folgende Auszug aus der Programmanzeige des Ablaufs der Hauptrechnung zeigt nun eine Stelle, wo die Berechnung der Verlagerungsbahn nicht mehr konvergiert und vom Programm abgebrochen wird. Zu den Zeitpunkten JT=45 und 46 kommt die Berechnung noch mit einer Extrapolation und einer Iteration aus bis die Genauigkeitskriterien erfüllt sind. Zu den Zeitpunkten JT= 47 bis 49 steigerte sich die Anzahl der erforderlichen Iterationszyklen auf 2 bis 4, was bereits andeutet, dass in dieser Phase der Berechnung die Lösung des Problems schwieriger wurde. Zum Zeitpunkt JT=50 wird die Berechnung nach einer Extrapolation und 9 Iterationszyklen abgebrochen, weil die programmintern festgelegten Genauigkeitskriterien immer noch nicht erfüllt wurden. Es erscheint die Fehlermeldung 302.

Anhand der Differenzen ΔE, ΔXE, ΔF1 und ΔF2 kann man sich auch leicht ein Bild machen, in welcher Weise die Iteration verlaufen ist. Das Programm gibt dem Anwender auch wieder die Möglichkeit, das noch ungenaue aber evtl. auch völlig falsche Ergebnis zu akzeptieren und trotzdem zum nächsten Zeitpunkt überzugehen und weiter zu rechnen. Das kann sinnvoll sein insbesondere in der Phase der Anlaufrechnung, weil sich manchmal die Rechnung wieder stabilisiert. Außerdem wird dadurch auch das instabile Ergebnis vom Programm gespeichert und man kann das Ergebnis zur Fehlersuche analysieren. Oft reicht es aber auch schon, die vorhergehenden Zeitschritte zu analysieren. Wie hier im Beispiel kündigt sich das Problem durch die Verschlechterung der Konvergenz durch die größer werdende Zahl der erforderlichen Iterationszyklen an. Nach Bestätigung des Abbruchs geht das Programm in den PostProzessor und es kann anhand der bisher berechneten Ergebnisse nach der Ursache gesucht werden. Bild 4.144 zeigt nun die bisher berechnete Verlagerungsbahn.



Bild 4.144: Belastungsverlauf und Verlagerungsbahn über 59 Zeitschritte bis zum Abbruch der Berechnung (Bilddatei: Demo05-1-2d-Pol-So-E-Punkte-JT=50-59.png)

Am Verlauf der Verlagerungsbahn sind bei diesem Beispiel zum Zeitpunkt JT=50, bei dem der 1.Abbruch auftrat, (durch blauen bzw. roten Balken hervorgehobener Zeitpunkt) noch keine Auffälligkeiten zu erkennen. Zwingt man das Programm jedoch weiter zu rechnen, zeigen die nachfolgenden Zeitpunkte der Verlagerungsbahn, dass die Berechnung aus dem Tritt geraten ist und sich nicht wieder fängt. Daraus ist aber noch nicht die Ursache zu erkennen.

Aufschlussreicher ist hier die Anzeige des örtlichen Füllungsgrades F für den Zeitpunkt JT=50 (Bild 4.145). In dieser Darstellung ist zu erkennen, dass die Berechnung der Druckverteilung und damit auch die Schmiermittelverteilung im Schmierspalt instabil geworden ist.

Bild 4.145: Darstellung des örtlichen Füllungsgrades F über die Schmierspaltfläche für den Zeitpunkt JT=50 für das Demonstrationsbeispiel (Bilddatei: Demo05-1-3d-Abw-F-JT=50.png)

Hier zeigt sich, dass offenbar durch die Vergrößerung der Zeitschrittweiten die Berechnung der Druckverteilung im Schmierspalt instabil geworden ist. Durch die damit verbundenen stochastischen Streuungen der berechneten Lagerbelastungen versagt dann die Suchstrategie nach einem gleichgewichtigen Verlagerungspunkt.

Für unser konkretes Beispiel kennen wir schon die Lösung des Problems, nämlich die Verkleinerung der Zeitschrittweite, wie sie im Demonstrationsbeispiel Demo05 angewendet wurde. Übrigens bedeutet eine Verdopplung der Anzahl der Zeitschritte in der Regel keine Verdoppelung der Rechenzeit. Eine Verkleinerung der Zeitschrittweiten hat zur Folge, dass die Ergebnisse aus dem vorhergehenden Zeitpunkt eine wesentlich bessere Anfangsnäherung für den nächsten Zeitpunkt darstellen und sich so die Dauer der Iteration je Zeitpunkt verkürzt.

Oft weisen Verlagerungsbahnen auch nur wenige kritische Stellen auf, an denen mit kürzeren Zeitschrittweiten gerechnet werden muss, so dass es nicht erforderlich ist, die Zeitschrittweite generell zu verkürzen. Um nur an wenigen Stellen die Zeitschrittweite zu verkürzen, kennt das Programm eine speziell dafür eingerichtete Funktionalität. Dazu muss im 2.Hauptmenü des PreProzessors mit der Aktion -21- zunächst eine variable Zeitschrittweite ΔT vereinbart werden. Anschließend können im Hauptmenü "Eingeben bzw. ändern der zeitabhängigen (variablen) Parameter" mit der Aktion -7- einige Zeitschritte geteilt werden. Für die neu hinzugekommenen Zeitpunkte berechnet dann das Programm die anderen erforderlichen zeitabhängigen Eingabewerte durch lineare Interpolation.

Das Teilen einer Zeitschrittweite kann auch leicht im Rahmen einer laufenden Berechnung erfolgen. Wenn z.B., wie oben gezeigt, eine Berechnung durch das Programm abgebrochen wurde, kannst Du zurück in den ProProzessor gehen und an geeigneter Stelle einen oder mehrere Zeitschritte teilen. Dann gehst Du wieder in den Solver und setzt die Berechnung zum Zeitpunkt vor der ersten Teilung fort. Diese Prozedur kannst Du während der Berechnung einer Verlagerungsbahn mehrfach wiederholen.

Nicht immer ist eine zu große Zeitschrittweite die Ursache für die Fehlermeldung 302. Es kann auch vorkommen, dass die Gitterteilung NX zu großmaschig oder die Mischungskonstante C zu klein gewählt wurde, so dass die Berechnung aus diesem Grunde instabil wurde.

Zusammenfassend kann gesagt werden, dass bei einem Versagen der Iteration keine feste Regel zur Abhilfe angegeben werden kann, sondern dass zunächst das Problem zu analysieren ist und in den meisten Fällen sich auch eine geeignete Lösung des Problems findet. Zur Ursachenforschung sind dabei die grafischen Darstellungen der bisher berechneten Ergebnisse hilfreich.

zurück   weiter

4.9.3 Programmierfehler

Zu den vielen bisher erkannten Programmfehlern braucht es hier keiner weiteren Bemerkungen, denn sie wurden beseitigt. Zu den noch nicht erkannten Programmfehlern kann hier nichts gesagt werden, denn sie sind ja noch nicht bekannt. Solltest Du solche Fehler entdecken, würde sich der Autor freuen, wenn Du sie mitteilst, damit sie abgestellt werden können.

Die GNU-Lizenz erlaubt nicht nur die freie Anwendung des Programms, sondern auch die Bearbeitung des Quelltextes. Falls Du Dich entscheidest, das Programm SIRIUS weiter zu entwickeln oder Deinen speziellen Anforderungen anzupassen und Du dazu den Quellcode bearbeitest, wird die Frage der Vermeidung von Programmierfehlern wieder aktuell.

Im Rahmen der Bearbeitung des Programms wurden neben den sichtbaren Anzeigen und Ausgaben eine Reihe weiterer Kontrollanzeigen programmiert, die Zwischenergebnisse zeigen können und so beim Testen des Programms und der Fehlersuche hilfreich waren. Da sie für den Programmbenutzer normalerweise nicht von Interesse sind, wurden diese Anzeige- und Ausgabemöglichkeiten teilweise wieder gelöscht. Ein Teil der Kontrollanzeigen wurde nur deaktiviert, indem die Befehlszeilen in der ersten Spalte mit einem "c" versehen wurden. Sie können leicht wieder aktiviert werden, indem dieses Zeichen gelöscht und das Programm neu kompiliert wird. Bei den nicht gelöschten Kontrollanzeigen handelt es sich generell um die Anzeige kompletter Datenfelder. In folgenden Routinen befinden sich noch deaktivierte Kontrollanzeigen:
      AbleiDeltaHP
      FilmDruck1
      FilmDruck2
      Fuell1
      GeoSchale
      KleiDru4
      Komplettieren
      SpaGeo4
      Verformung
Es existieren in den Routinen auch noch einige wenige deaktivierte Fehlerkontrollen, die Programmierfehler anzeigen würden, die aber nach dem erfolgreichen Testen eigentlich nicht mehr von Bedeutung sind, weil diese Fehler nicht mehr auftreten dürften. Diese Fehlermeldungen sind in der Regel mit einer 400-er Nummer gekennzeichnet und könnten auch leicht wieder aktiviert werden. Sie sind aber nicht im Fehlerverzeichnis des Abschnitts 4.9.5 verzeichnet und kommentiert. Es wird hier darauf hingewiesen, dass diese Fehlerkontrollen bei einer weiteren Bearbeitung des Programms sicher nicht ausreichend sind und der Bearbeiter für eine umfassende Fehlerkontrolle bzw. -suche mindestens zeitweilig weitere Tests einbauen muss.

zurück   weiter

4.9.4 Fehler, die das Programm nicht erkennt

Es gibt im Programm auch Möglichkeiten fehlerhafte Ergebnisse zu erzielen, die das Programm nicht erkennen kann, die aber dem Autor bekannt sind und aus verschiedenen Gründen nicht durch eine entsprechende Programmierung ausgeschlossen wurden bzw. nicht ausgeschlossen werden konnten. Das kann aus folgenden Gründen der Fall sein:

  1. Die Beseitigung der Fehlerquelle steht im Konflikt mit anderen angestrebten Eigenschaften des Programms, z.B. seiner Flexibilität, so dass diese Fehlerquelle unter Abwägung der Vor- und Nachteile in Kauf genommen wird.
  2. Es ist programmtechnisch zu aufwendig, diese Fehlerquelle auszuschließen.
  3. Es ist prinzipiell unmöglich, diese Fehlerquelle auszuschließen.
Um dem Anwender einen verantwortungsbewussten Umgang mit diesen bekannten Fehlerquelle zu ermöglichen, sollen sie hier beschrieben und Tipps zum Umgang mit diesen Problemen gegeben werden:

1. Numerische Instabilitäten: Es soll hier noch einmal darauf hingewiesen werden, dass numerische Instabilitäten, wie sie im Abschnitt 4.9.2 beschrieben wurden, nicht zwangsläufig zu einer Fehlermeldung führen. Solange die Iterationsroutinen die implementierten Genauigkeitskriterien erfüllen können, rechnet das Programm weiter. Deshalb ist es sinnvoll, sich anhand der Ergebnisse von der Stabilität der Berechnung zu überzeugen. Das lässt sich am besten erkennen an der grafischen Darstellung des örtlichen Füllungsgrades F(Z,X) oder der Flüssigkeitsverteilung HF(Z,X) im Schmierspalt.

2. Umgehung der Konsistenzprüfung der Eingabedaten: Beim normalen Ablauf einer Dateneingabe werden die Eingabemenüs im PreProzessor vom Anfang bis zum Ende der Reihe nach durchlaufen. Dabei erfolgt gleichzeitig die Konsistenzprüfung der primären Eingabedaten. Damit wird eine weitgehende Widerspruchsfreiheit der Eingabedaten erreicht. Im Interesse einer ungehinderten Bewegung durch das Programm kann aber aus den Eingabemenüs auch zurück gesprungen werden und anschließend über den direkten Sprung in den PostProzessor und weiter zum Solver die vollständige Konsistenzprüfung umgangen werden. Das kann in der Hauptrechnung zu merkwürdigen Ergebnissen, zum Abbruch der Berechnung und auch zum Absturz des Programms führen. Das Programm kann zwar keine dadurch entstehenden Fehler vorhersehen, es gibt aber im Solver folgende Warnung aus, wenn diese Gefahr besteht:

3. Rücksprünge im PreProzessor: Die Eingabemenüs im PreProzessor sind in einer Reihenfolge angeordnet, so dass die zuerst angezeigten und eingegebenen Parameter auch entscheiden, welche nachfolgenden Daten relevant sind und dementsprechend in den nachfolgenden Menüs zur Bearbeitung angezeigt werden. D.h., dass in der Reihenfolge weiter hinten stehende Eingabedaten die Relevanz und die Konsistenz weiter vorn stehender Eingabedaten nicht beeinflussen. Umgekehrt ist das nicht der Fall. Da aber im PreProzessor zurückgesprungen werden kann und vorhergehende Parameter erneut verändert werden können, können nachfolgende bereits bearbeitete Parameter irrelevant oder auch ungültig werden. Es können auch bisher irrelevante Parameter relevant werden und mit irgendwelchen ungültigen Werten aus vorhergehenden Berechnungen an der Programmoberfläche erscheinen. Deshalb sind nach einem Rücksprung in den nachfolgenden Menüs stets alle Angaben erneut auf ihre Aktualität zu kontrollieren.

4. Verschiebung der Schmiertaschen durch Änderung der Gitterteilung: Auf eine spezielle Fehlerquelle durch einen Rücksprung soll hier gesondert hingewiesen werden, nämlich wenn im Menü "Anordnung der Schmiertaschen festlegen" bereits die Anordnung von Schmiertaschen eingegeben wurde und anschließend noch einmal zurückgesprungen wird und die Gitterfeinheit mit NX bzw. NZ verändert wird. Dann verschiebt sich die Anordnung der Schmiertaschen auf unkontrollierte Weise und muss regelmäßig erneut eingegeben werden.

5. Parameter NT2 wird nicht zurückgesetzt: Der Parameter NT2 gibt an, wie viele Zeitpunkte von den zu berechnenden NT Zeitpunkten bereits berechnet wurden. Gemäß der Bedeutung des Parameters NT2 gelten alle Zeitpunkte nach NT2 als nicht berechnet und evtl. bereits vorhandene Werte in den entsprechenden Ergebnisfeldern als ungültig. Nach einer teilweisen oder vollständigen Berechnung kann in den PreProzessor zurückgesprungen werden und es können Eingabedaten verändert werden. Streng genommen müsste nach jeder Änderung der Eingabedaten NT2 automatisch zurückgesetzt werden. Darauf hat der Autor aber bis auf wenige eindeutige Fälle verzichtet, weil dadurch die Flexibilität des Programms erhöht wird und mit guter Programmkenntnis und Geschick einige technisch sinnvolle Betriebsbedingungen simuliert werden können, die explizit noch gar nicht vorgesehen sind. Das Fehlerpotential in dieser Programmgestaltung entsteht dadurch, dass hier ältere Ergebnisse und neuere Eingabedaten als Datensatz gemeinsam abgespeichert werden können und so der irreführende Eindruck entstehen kann, dass diese Daten zusammengehören, was bei einer Nachrechnung dieses Datensatzes zu arger Irritation führen kann. Deshalb liegt es in der Verantwortung des Anwenders mit dieser Freiheit verantwortungsvoll umzugehen. Dazu gibt es im Hauptmenü "Ende der Eingabe erreicht" mit der Aktion -2- die Möglichkeit NT2 manuell vollständig oder nur teilweise zurück zu setzen.

6. Nachrechnen eingelesener Datensätze ohne Konsistenzprüfung: Bereits abgespeicherte Lagerberechnungen können zur Auswertung im PostProzessor wieder eingelesen werden. Da man vom PostProzessor direkt zum Solver zurückspringen kann, kann dieser Datensatz ohne erneute Konsistenzprüfung erneut berechnet werden. Das ist in der Regel unproblematisch, weil ja vor der ursprünglichen Berechnung diese Konsistenzprüfung bereits erfolgte. Das Fehlerpotential besteht hier darin, dass diese Datensätze als Textdateien vorliegen und mit jedem einfachen Texteditor absichtlich oder auch aus Versehen beim Anschauen unsachgemäß manipuliert werden können. Hier hat das Programm nur eine Chance, Eingabefehler zu ermitteln, wenn vor der erneuten Berechnung die Eingabemenüs des PreProzessors noch einmal vollständig durchlaufen werden. Bekommt das Programm diese Chance nicht, gibt es folgende Warnung aus:

Es wird empfohlen, die Eingabedaten nicht extern mit einem Editor außerhalb des Programms SIRIUS zu editieren. Die einzigen Eintragungen, die an einem Datensatz relativ problemlos erfolgen können, sind die Eingabe oder Änderung des Titels der Berechnungsvariante.

7. Fehlende Parameter in einem eingelesenen Datensatz: Beim Einlesen eines primären Eingabe- und Ergebnisdatensatzes aus einer Datei übernimmt das Programm alle Parameter, deren Bezeichnungen ihm bekannt sind und in der richtigen Reihenfolge stehen. Es ist nicht in der Lage zu überprüfen, ob es alle für diese Variante erforderlichen relevanten primären Eingabeparameter auch gelesen hat und kann diesbezüglich auch keine Fehlermeldung ausgeben. Für alle nichtgelesenen relevanten Parameter werden jeweils die derzeit unter der entsprechenden Variablen bereits gespeicherten Werte übernommen. Das kann ein Anfangswert für diesen Parameter sein. Es kann aber auch ein zufälliger Wert aus einer vorhergehenden Berechnung dieser Sitzung sein.

Dieses Problem sollte nicht auftreten, wenn an den Datensätzen extern nicht manipuliert wird, da die Routine "AusgabePara5" für die Eingabe- und Ergebnisdatensicherung und die Routine "LesenPara5" für das Wiedereinlesen exakt auf einander abgestimmt sind. Auf diese Abstimmung ist deshalb auch unbedingt bei Weiterentwicklungen oder Anpassungen des Programms mit zusätzlichen Ein- und Ausgabedaten zu achten. Dabei ist auch an eine anzustrebende Abwärtskompatibilität zu denken, um auch ältere archivierte Datensätze weiter verwenden zu können.

8. Fehlerhafte Parameterbezeichnung in einem eingelesenen Datensatz: Trifft das Programm beim Lesen eines Datensatzes auf eine ihm unbekannte Parameterbezeichnung, so blockiert diese falsche Bezeichnung das Einlesen aller nachfolgenden an sich bekannten weiteren Parameter, weil es davon ausgeht, dass dieser Name korrekt ist und bis zum Schluss versucht wird, die Bezeichnung als bekannt zu identifizieren. Diese Blockade wird vom Programm nicht bemerkt und so gibt es auch keine Fehlermeldung. Die gleiche Blockade entsteht, wenn zwei Parameter nicht in der richtigen Reihenfolge stehen. Einen Hinweis auf eine derartige Blockade liefert das Protokoll der Leseaktion, wenn offensichtlich benötigte Eingabeparameter nicht aufgeführt sind:

Einen eindeutigen Hinweis auf einen unvollständig gelesenen Datensatz liefert das Fehlen der Zeile

denn mindestens eine Anfangsdruckverteilung P(NZ,NX) gehört zu jedem Datensatz.

Zur Vermeidung dieses Problems gelten die gleichen Hinweise, wie zum Punkt 7. In diesem Sinne wird dringend geraten, bei Programmänderungen möglichst keine Namensänderungen bei den primären Parametern vorzunehmen. Sollte ausnahmsweise eine Namensänderung dringend geboten sein, so sollte auch die alte Bezeichnung weiterhin als bekannter Parameter in der Leseroutine verfügbar sein. Sollte ein Parameter in Zukunft nicht mehr benötigt werden, sollte er auch in der Leseroutine weiterhin präsent sein. So kann die Abwärtskompatibilität erhalten werden und auch älter Datensätze können gelesen werden, ohne eine Leseblockade zu erzeugen.

9. Nicht implementierte physikalisch-technische Sachverhalte: Abschließend soll noch an die eigentlich selbstverständliche Tatsache erinnert werden, das natürlich nur die physikalisch-technischen Sachverhalte von den Simulationen abgebildet werden, die durch das mathematische Modell auch im wesentlichen richtig erfasst wurden. Abweichungen von der Wirklichkeit, aufgrund der Idealisierungen des im Programm realisierten mathematischen Modells, müssen immer in Betracht gezogen werden. Hier wird der Anwender auf die ausführlich dargestellten physikalischen, geometrischen und technischen Grundlagen des Abschnitts 2 der Dokumentation verwiesen, die ihm helfen sollen, die Ergebnisse richtig zu deuten. In diesem Sinne ist in diesem Programm auch keine explizite Aussage zu finden, dass eine berechnete Lagervariante für einen bestimmten Zweck geeignet ist. Dieses Urteil muss jeder Anwender eigenverantwortlich treffen.

zurück   weiter

4.9.5 Erläuterungen zu den einzelnen Fehlermeldungen

zurück   weiter

FEHLERMELDUNG 001: Fehler bei der Auswahl einer Aktion

Fehlerbeschreibung:

Es erscheint z.B. folgende Meldung:

Diese Fehlermeldung kann auftreten bei der Auswahl einer Aktion aus einem Menü.

Das Programm erwartet die Eingabe eines einzelnen bis maximal 3 Zeichen. Ziffern werden hier auch nur als alphanumerische Zeichen interpretiert. Die Fehlermeldung wird ausgegeben, wenn ein anderes Zeichen oder eine andere Zeichenkette, als die im Menü angegebenen, eingegeben wird. Wie viel Zeichen das Menü maximal erwartet, ist daran zu erkennen, aus wie viel Zeichen die aufgeführte längste Zeichenkette der auswählbaren Aktionen im aktuellen Menü besteht.

Fehlerbehebung:

Der Fehler ist leicht zu beheben durch erneute Auswahl, diesmal einer verfügbaren Aktion.

Fehleingaben, die das Programm nicht erkennt:

Werden mehr als die erwarteten 1 bis maximal 3 Zeichen eingegeben und die ersten Zeichen entsprechen einer der im Menü aufgeführten Zeichenketten, wird keine Fehlermeldung ausgegeben und die Aktion, die den ersten 1 bis 3 Zeichen zugeordnet werden kann, wird ausgeführt.

In einigen Menüs, z.B. im Hauptmenü "Eingeben bzw. ändern der konstanten Parameter" kann es vorkommen, dass eine Zeichenkette eingegeben wird, die nicht im aktuellen Menü aufgeführt ist, und trotzdem bietet das Programm eine Aktion an, z.B. die Änderung eines Eingabeparameters. Das kann passieren, wenn sich hinter diesem Aufruf ein Parameter verbirgt, der aktuell gerade als Eingabeparameter irrelevant ist und deshalb aktuell nicht zur Bearbeitung vorgesehen ist. Falls dieser Parameter dann bearbeitet wird, hat das für die anschließende Berechnung keine Bedeutung, weil dieser Parameter ja irrelevant ist und deshalb bei der folgenden Berechnung nicht zur Kenntnis genommen wird. Durch die Eingabe von "z" kann der Aufruf, wie üblich, auch ohne Bearbeitung abgebrochen werden.

HINWEIS: Für eine korrekte Eingabe sind die Zeichen ohne die einrahmenden Zeichen "-", "<" und ">" einzugeben und die Eingabe ist mit der ENTER-Taste abzuschließen, damit das Programm mit der Auswertung der Eingabe beginnt. Vorher wird das Ergebnis weder akzeptiert, noch eine Fehlermeldung ausgegeben.

zurück   weiter

FEHLERMELDUNG 002: Fehler bei der Eingabe einer ganzen Zahl

Fehlerbeschreibung:

Es erscheint z.B. folgende Meldung:

oder

Diese Fehlermeldung kann auftreten, wenn das Programm die Eingabe einer ganzen Zahl (Variablentyp: integer) erwartet und die angegebenen Beschränkungen des Definitionsbereichs nicht eingehalten werden.

Fehlerbehebung:

Der Fehler kann leicht behoben werden durch erneute Eingabe unter Einhaltung der angegebenen Beschränkungen.

Durch Eingabe des Zeichens z+ENTER-Taste kann die Aktion auch wie üblich ohne Änderung abgebrochen werden.

Fehleingaben, die das Programm nicht erkennt:

Wird eine beliebige alphanumerische Zeichenfolge (außer einer ganzen Zahl) eingegeben, evtl. auch eine Zeichenfolge, die als Gleitkommazahl zu interpretieren ist, dann macht das Programm keine Fehlermeldung, sondern deutet die Eingabe genauso wie die Eingabe des Zeichens z als Aufforderung, die Eingabe abzubrechen und geht zurück zum übergeordneten Menü. In diesem Fall ist die Aktion im übergeordneten Menü evtl. erneut aufzurufen und danach eine erneute Eingabe zu starten.

Wird nur die ENTER-Taste betätigt und vorher kein Zeichen eingegeben, geht der Cursor in die nächste Zeile und wartet weiter auf die Eingabe einer ganzen Zahl. Zur Fortsetzung des Programms muss mindestens ein Zeichen eingegeben werden und die Eingabe mit der ENTER-Taste abgeschlossen werden.

zurück   weiter

FEHLERMELDUNG 003: Fehler bei der Eingabe einer Gleitkommazahl

Fehlerbeschreibung:

Es erscheint z.B. folgende Meldung:

Diese Fehlermeldung kann auftreten, wenn das Programm die Eingabe einer Gleitkommazahl (Variablentyp: real) erwartet und die angegebenen Beschränkungen des Definitionsbereichs nicht eingehalten werden.

Fehlerbehebung:

Der Fehler kann leicht behoben werden durch erneute Eingabe unter Einhaltung der angegebenen Beschränkungen.

Durch Eingabe des Zeichens z+ENTER-Taste kann die Aktion auch wie üblich ohne Änderung abgebrochen werden.

Fehleingaben, die das Programm nicht erkennt:

Wird eine beliebige alphanumerische Zeichenfolge eingegeben, die das Programm nicht als Gleitkommazahl interpretieren kann, dann macht das Programm keine Fehlermeldung, sondern deutet die Eingabe genauso wie die Eingabe des Zeichens z als Aufforderung, die Eingabe abzubrechen und geht zurück zum übergeordneten Menü. In diesem Fall ist die Aktion im übergeordneten Menü evtl. erneut aufzurufen und danach ein erneuter Eingabeversuch zu machen. Ganze Zahlen werden bei der Abfrage einer Gleitkommazahl erkannt und intern als Gleitkommazahlen abgespeichert.

Wird die ENTER-Taste betätigt und vorher kein Zeichen eingegeben, geht der Cursor in die nächste Zeile und wartet weiter auf die Eingabe einer ganzen Zahl. Zur Fortsetzung des Programms muss mindestens ein Zeichen eingegeben werden und die Eingabe mit der ENTER-Taste abgeschlossen werden.

zurück   weiter

FEHLERMELDUNG 101: Ausgewählte Eingabe-Datei wird nicht gefunden

Fehlerbeschreibung:

Es erscheint folgende Meldung:

Diese Fehlermeldung kann erscheinen, wenn eine Datei aufgerufen und geöffnet werden soll, um daraus Daten in das Programm einzulesen. Die Fehlermeldung kann folgende Ursachen haben:

HINWEIS: Das Verzeichnis "/Daten" muss ein direktes Unterverzeichnis des Verzeichnisses sein, aus dem die Programmdatei SIRIUS.exe gestartet wurde.

Die Fehlermeldung ist enthalten in der Routine "DateiAufruf2".

Fehlerbehebung:

Die Datei muss evtl. erst erzeugt werden.

Verschieben der gesuchten Datei in das Verzeichnis "./Daten".

Evtl. vorher auch Einrichten des Verzeichnisse "/Daten" oder verschieben des Verzeichnisses an die richtige Position.

Evtl. schließen, der geöffneten Datei. Es kann auch passieren, dass in der aktuellen Sitzung ein aufrufendes Programm durch einen Programmfehler selbst abgebrochen wurde, ohne vorher die geöffnete Datei wieder zu schließen, so dass der Zugriff blockiert ist. Dieses Problem kann behoben werden, indem die aktuelle Sitzung am Computer beendet und die Sitzung neu gestartet wird.

Aufruf einer anderen Datei oder Abbruch der Aktion.

HINWEIS: Der Dateiname muss vollständig einschließlich Dateierweiterung z.B. ".txt" eingegeben werden. Es ist auch möglich, Dateien mit anderen Erweiterungen oder auch ohne Dateierweiterung einzulesen. Sie werden vom Programm immer als einfache Textdateien interpretiert.

zurück   weiter

FEHLERMELDUNG 102: Ausgewählte Eingabe-Datei mit falschen Kennwort

Fehlerbeschreibung:

Es erscheint z.B. folgende Meldung:

Diese Fehlermeldung kann erscheinen, wenn eine Datei aufgerufen und geöffnet wird, um daraus Daten in das Programm einzulesen. Alle Dateien, mit denen das Programm SIRIUS Eingabe- und Ergebnisdaten in das Verzeichnis "./Daten" ausgibt und die es evtl. auch wieder einlesen kann, sind zur Identifikation des Dateninhalts in der ersten Zeile mit einem Kennwort von maximal 13 Zeichen versehen. Das wird bei jedem erfolgreichen Aufruf einer dieser Dateien zunächst ausgelesen und ausgewertet. Damit soll u.a. verhindert werden, Daten aus einer Datei zu lesen, die darin nicht enthalten sind, weil das regelmäßig schief geht. Stimmt das in der Datei gelesene Kennwort nicht mit dem Kennwort überein, welches die Dateien mit dem entsprechenden Dateninhalt aufweisen sollten, lehnt das Programm die Leseaktion ab und es erscheint die Fehlermeldung. Bei den Kennwörtern wird auch zwischen Groß- und Kleinschreibung unterschieden.

Die Tabelle 4.15 listet alle Arten von Datendateien auf, die zur Dateneingabe oder -ausgabe oder zur Datensicherung erzeugt und zum Teil auch wieder gelesen werden. Es werden das zugehörige Kennwort und der Standarddateiname für diese Dateiart zum schnellen Zwischenspeichern der Daten angegeben. Nicht dazu gehören die temporären Ausgabedateien zur Erzeugung von Grafiken und Animationen, die in das Temp-Verzeichnis ausgegeben werden.

Tabelle 4.15: Übersicht der Eingabe- Ausgabedateien
Standard-DateinameKennwortInhaltEingabe /Ausgabe
datensatz.txtdatensatz5Sicherung der primären Eingabe- und ErgebnisdatenE/A
protokoll.txtProtokollAusgabe der primären Eingabe- und Ergebnisdaten in gut lesbarer Formnur Ausgabe
Schmierdaten.txtSchmierdatenAusgabe der Daten der Schmiermittelströmung im Schmierspalt und im peripheren Schmiersystem für einen ausgewählten Zeitpunkt in gut lesbarer Formnur Ausgabe
DruckP.txtDruckPDruckverteilung im Schmierspalt für einen Zeitpunkt zur externen Weiterverwendung oder Übertragung als Anfangsdruckverteilung für eine andere BerechnungE/A
KX00.txtSteuerfeldKXSicherung einer Variante der Anordnung Schmiertaschen im SchmierspaltE/A
Schale.txtschalenformFeld von punktweise gegebenen Formabweichungen der Lagerschale von der ideal zylindrischen FormE/A
Welle.txtwellenformFeld von punktweise gegebenen Formabweichungen der Welle von der ideal zylindrischen FormE/A
Varpara.txtVariableDatenAktuell zeitlich variable primäre Eingabedaten für eine LagervarianteE/A
Chp.txtMatrixChpVerformungsmatrix einer elastischen LagerschaleE/A

Die Fehlermeldung ist enthalten in der Routine "DateiAufruf2".

Fehlerbehebung:

Es ist eine andere geeignete Datei auszuwählen.

Falls die Datei extern erzeugt oder bearbeitet wurde und es handelt sich nur um einen Formfehler, ist dieser mit einem Texteditor zu korrigieren und ein erneuter Leseversuch zu starten.

TIPP: Um die erforderliche Textstruktur bei externer Erzeugung einer Datei zur Dateneingabe einzuhalten, wird empfohlen, zunächst eine entsprechende Datei als Muster auszugeben.

Fehleingaben, die das Programm nicht erkennt:

Das Kennwort in der ersten Zeile der Dateien dient lediglich der Vermeidung eines versehentlichen Überschreibens anderer Dateien oder dem versehentlichen Lesen aus einer ungeeigneten Datei und ist nicht gedacht als Schutz vor böswilligen Manipulationen. Es kann daher leicht gefälscht werden, was das Programm natürlich nicht erkennen kann.

zurück   weiter

FEHLERMELDUNG 103: Unzulässiger Dateiname, Verzeichnis existiert nicht

Fehlerbeschreibung:

Es erscheint folgende Meldung:

Diese Fehlermeldung kann erscheinen, wenn eine neue Datei erzeugt oder eine vorhandene Datei geöffnet werden soll, um in diese Datei Daten auszugeben. Die Fehlermeldung kann folgende Ursachen haben:

Die Fehlermeldung ist enthalten in der Routine "DateiAufruf1".

Fehlerbehebung:

Evtl. ist vorher das Verzeichnis "/Daten" einzurichten oder das Verzeichnis "/Daten" ist an die richtige Position zu verschieben.

HINWEIS: Das Verzeichnis "/Daten" muss ein direktes Unterverzeichnis des Verzeichnisses sein, aus dem die Programmdatei SIRIUS.exe gestartet wurde.

Evtl. schließen der geöffneten Datei. Es kann auch passieren, dass in der aktuellen Sitzung ein aufrufendes Programm durch einen Programmfehler selbst abgebrochen wurde, ohne vorher die geöffnete Datei wieder zu schließen, so dass der Zugriff blockiert ist. Das Problem kann behoben werden, indem die aktuelle Sitzung am Computer beendet und die Sitzung neu gestartet wird.

Es ist ein zulässiger Dateiname einzugeben. Welche Dateinamen zulässig sind, ist vom Betriebssystem abhängig.

HINWEIS: Der Dateiname muss vollständig einschließlich Dateierweiterung z.B. ".txt" eingegeben werden. Es ist auch möglich Dateien mit anderen Erweiterungen oder auch ohne Dateierweiterung einzulesen. Sie werden vom Programm immer als einfache Textdateien interpretiert.

Aufruf einer anderen Datei oder Abbruch der Aktion.

zurück   weiter

FEHLERMELDUNG 104: Datei gleichen Namens mit anderem Kennwort vorhanden

Fehlerbeschreibung:

Es erscheint z.B. folgende Meldung:

Diese Fehlermeldung kann erscheinen, wenn eine Datei aufgerufen und geöffnet wird, um sie mit neuen Daten zu überschreiben. Alle Dateien, mit denen das Programm SIRIUS Eingabe- und Ergebnisdaten in das Verzeichnis "./Daten" ausgibt und die es evtl. auch wieder einlesen kann, sind zur Identifikation des Dateninhalts in der ersten Zeile mit einem Kennwort von maximal 13 Zeichen versehen. Das wird bei jedem erfolgreichen Aufruf einer dieser Dateien zunächst ausgelesen und ausgewertet. Damit soll u.a. verhindert werden, aus Versehen Dateien anderen Inhalts zu überschreiben. Stimmt das in der Datei gelesene Kennwort nicht mit dem Kennwort überein, welches die Dateien mit dem entsprechenden Dateninhalt aufweisen sollten, lehnt das Programm die Schreibaktion ab und es erscheint die Fehlermeldung. Bei den Kennwörtern wird auch zwischen Groß-Kleinschreibung unterschieden.

Die Tabelle 4.15 listet alle Arten von Datendateien auf, die zur Dateneingabe oder -ausgabe oder zur Datensicherung erzeugt und zum Teil auch wieder gelesen werden. Es werden das zugehörige Kennwort und der Standarddateiname für diese Dateiart zum schnellen Zwischenspeichern der Daten angegeben. Nicht erfasst sind hier die temporären Ausgabedateien zur Erzeugung von Grafiken und Animationen, die in das Temp-Verzeichnis ausgegeben werden.

Tabelle 4.15: Übersicht der Eingabe- Ausgabedateien
Standard-DateinameKennwortInhaltEingabe /Ausgabe
datensatz.txtdatensatz5Sicherung der primären Eingabe- und ErgebnisdatenE/A
protokoll.txtProtokollAusgabe der primären Eingabe- und Ergebnisdaten in gut lesbarer Formnur Ausgabe
Schmierdaten.txtSchmierdatenAusgabe der Daten der Schmiermittelströmung im Schmierspalt und im peripheren Schmiersystem für einen ausgewählten Zeitpunkt in gut lesbarer Formnur Ausgabe
DruckP.txtDruckPDruckverteilung im Schmierspalt für einen Zeitpunkt zur externen Weiterverwendung oder Übertragung als Anfangsdruckverteilung für eine andere BerechnungE/A
KX00.txtSteuerfeldKXSicherung einer Variante der Anordnung Schmiertaschen im SchmierspaltE/A
Schale.txtschalenformFeld von punktweise gegebenen Formabweichungen der Lagerschale von der ideal zylindrischen FormE/A
Welle.txtwellenformFeld von punktweise gegebenen Formabweichungen der Welle von der ideal zylindrischen FormE/A
Varpara.txtVariableDatenAktuell zeitlich variable primäre Eingabedaten für eine LagervarianteE/A
Chp.txtMatrixChpVerformungsmatrix einer elastischen LagerschaleE/A

Die Fehlermeldung ist enthalten in der Routine "DateiAufruf1".

Fehlerbehebung:

Es ist ein anderer Dateiname einzugeben.

Soll trotzdem im Verzeichnis eine neue Datei mit diesem Namen ausgegeben werden, ist zunächst die bereits existierende Datei zu löschen oder in ein anderes Verzeichnis zu verschieben.

Fehleingaben, die das Programm nicht erkennt:

Das Kennwort in der ersten Zeile der Dateien dient lediglich der Vermeidung eines versehentlichen Überschreibens anderer Dateien oder dem versehentlichen Lesen aus einer ungeeigneten Datei und ist nicht gedacht als Schutz vor böswilligen Manipulationen. Es kann daher leicht gefälscht werden, was das Programm natürlich nicht erkennen kann.

zurück   weiter

FEHLERMELDUNG 105: Temp-Verzeichnis existiert nicht

Fehlerbeschreibung:

Es erscheint folgende Meldung:

Diese Fehlermeldung kann erscheinen, wenn zur Erzeugung einer Grafik oder einer Animation Daten an das externe Programm GNUPLOT übergeben werden sollen und dazu eine oder mehrere Dateien in das Verzeichnis "./Temp" abgelegt werden sollen. Die Fehlermeldung kann folgende Ursachen haben:

Die Fehlermeldung ist enthalten in den Routinen "Anim_2d_Ax", "Anima_2d_Quer", "Anima_3d", Anima_3d_Spiel", "Anima_VarPara", Bild_2d_Ax", "Bild_2d_Quer", "Bild_3d", "Bild_Spiel", "Bild-Q_Lei", "Bild_VarPara".

Fehlerbehebung:

Das Verzeichnis "/Temp" ist einzurichten oder das Verzeichnis "/Temp" ist an die richtige Position zu verschieben.

Der angezeigte Fehler ist zunächst durch Betätigen der ENTER-Taste zu quittieren. Dabei springt das Programm in das Hauptmenü zurück. Nach Beseitigung der Fehlerursache kann die Aktion erneut gestartet werden.

zurück   weiter

FEHLERMELDUNG 106: Falsche Reihenfolge der Kopfdaten

Fehlerbeschreibung:

Es erscheint z.B. folgende Meldung:

Diese Fehlermeldung kann erscheinen, wenn eine Datei aufgerufen und geöffnet wird, um daraus ein Datenfeld in das Programm einzulesen. Neben dem Kennwort in der 1.Zeile der Datendatei sind bei einigen Eingabe-Ausgabe-Dateien in den folgenden Zeilen weitere Parameter angegeben, mit denen das Programm überprüfen kann, ob zu der aktuell im Programm ausgewählten Lagervariante ein passendes Datenfeld eingelesen wird. Die jeweils verwendeten kennzeichnenden Parameter können folgende sein:

      Dim, Sym, Vollum, NT, NX, NZ, Sym3, NSym3, NXP, NZP

Das Programm prüft zunächst, ob diese Parameter in der richtigen Reihenfolge aufgeführt sind. Das ist notwendig, damit nicht unterschiedliche Parameter miteinander verglichen werden. Wenn diese Reihenfolge nicht der vom Programm erwarteten entspricht, kommt eine Fehlermeldung, wie z.B. die oben angezeigte.

Dieser Fehler kann normalerweise nicht auftreten, wenn diese Datei vom Programm SIRIUS selbst erzeugt und ausgegeben wurde und anschließend ohne Manipulation dieser Zeilen der Datei wieder eingelesen wird. Sollte das trotzdem passieren, dann liegt ein Programmfehler vor. Evtl. wurde im Rahmen einer Überarbeitung des Quelltextes die Eingabe und die Ausgabe Routine nicht zueinander passend geändert.

Normalerweise tritt dieser Fehler bei einer unsachgemäßen externen Erzeugung bzw. Bearbeitung der Datei auf.

Die Fehlermeldung ist enthalten in den Routinen "FormSchale", "FormWelle", "LesenDruckP", LesenKX00", LesenMatrixChp", "LesenVarPara".

Fehlerbehebung:

Vertausche die Reihenfolge der Zeilen dieser Parameter in der zu lesenden Datei mit Hilfe eines Texteditors. Es können aber auch Parameter fehlen, die zu ergänzen sind.

TIPP: Um die erforderliche Textstruktur bei externer Erzeugung einer Datei zur Dateneingabe einzuhalten, wird empfohlen, zunächst eine entsprechende Datei als Muster auszugeben.

zurück   weiter

FEHLERMELDUNG 107: Unpassende Werte bei den Kopfdaten

Fehlerbeschreibung:

Es erscheint z.B. folgende Meldung:

Diese Fehlermeldung kann erscheinen, wenn eine Datei aufgerufen und geöffnet wird, um daraus ein Datenfeld in das Programm einzulesen. Neben dem Kennwort in der 1.Zeile der Datei sind bei einigen Eingabe-Ausgabe-Dateien in den folgenden Zeilen weitere Parameter angegeben, mit denen das Programm überprüfen kann, ob zu der aktuell im Programm ausgewählten Lagervariante ein passendes Datenfeld eingelesen wird. Die jeweils verwendeten kennzeichnenden Parameter können folgende sein:

      Dim, Sym, Vollum, NT, NX, NZ, Sym3, NSym3, NXP, NZP

Das Programm überprüft, ob alle diese Parameter in der Datei mit denen übereinstimmen, die aktuell im Programm gelten. Wenn das nicht der Fall ist, kommt eine Fehlermeldung wie z.B. die oben gezeigte.

Die Fehlermeldung ist enthalten in den Routinen "FormSchale", "FormWelle", "LesenDruckP", "LesenKX00", "LesenMatrixChp", "LesenVarPara".

Fehlerbehebung:

Wähle eine andere Datei aus, die ein passendes Datenfeld enthält.

Ändere den oder die abweichenden Eingabeparameter im Programm und rufe dann diese Datei erneut auf.

zurück   weiter

LESEFEHLER 108: Fehler beim Lesen einer Textzeile

Fehlerbeschreibung:

Es erscheint z.B. folgende Meldung:

oder

Diese Fehlermeldung könnte erscheinen, wenn das Programm eine Textzeile erwartet, diese aber nicht lesen kann. Dabei geht es noch nicht um die Interpretation dieser Zeichen.

Wenn in der Datei eine Reihe von Textzeilen zu erwarten sind, dann wird auch der Inhalt der letzten erfolgreich gelesenen Zeichenfolge angegeben, damit der Anwender einen Hinweis erhält, nach welcher Zeile der Datei der Fehler aufgetreten ist.

Diese Fehlermeldung ist vorsorglich eingebaut worden, um einen evtl. auftretenden Systemfehler abzufangen und damit einen nicht erklärbaren Absturz des Programms zu vermeiden. Bisher ist dieser Fehler noch nicht aufgetreten, da aus einer geöffneten Datei irgendwelche Zeichen eigentlich immer gelesen werden können, falls noch welche vorhanden sind. Deshalb können auch noch keine Angaben gemacht werden, wie der Fehler zu beheben ist.

Die Fehlermeldung ist enthalten in den Routinen "FormSchale", "FormWelle", "LesenDruckP", "LesenKX00", "LesenMatrixChp", "LesenPara5", "LesenVarPara".

zurück   weiter

LESEFEHLER 109: Dateiende beim Lesen einer Textzeile

Fehlerbeschreibung:

Es erscheint z.B. folgende Meldung:

oder

Diese Fehlermeldung erscheint, wenn das Programm einen Variablennamen oder eine Textzeile, z.B. eine Zwischenüberschrift, lesen will, aber das Ende der Datei bereits erreicht ist.

Wenn in der Datei eine Reihe von Textzeilen zu erwarten sind, dann wird auch der Inhalt der letzten erfolgreich gelesenen Zeichenfolge angegeben, damit der Anwender einen Hinweis erhält, nach welcher Zeile der Datei der Fehler aufgetreten ist.

TIPP: Meistens liegt bei dieser Meldung die Fehlerursache schon weiter vorne in der Datei.

Die Fehlermeldung ist enthalten in den Routinen "FormSchale", "FormWelle", "LesenDruckP", "LesenKX00", "LesenMatrixChp", "LesenPara5", "LesenVarPara".

Fehlerbehebung:

Möglicherweise wurde ein Teil der Datei aus Versehen gelöscht. Dann ist die Datei mit einem Texteditor wieder zu vervollständigen.

Evtl. muss die Datei neu erzeugt werden.

Möglicherweise fehlt in der Datei auch nur eine Zwischenüberschrift, deren Inhalt zwar nicht zur Kenntnis genommen wird, aber entsprechend dem vorgegebenen Aufbau der Datei vorhanden sein muss. Dann wird die erste Zeile des Datenfeldes als Zwischenüberschrift gelesen und das Lesen der eigentlichen Daten beginnt erst in der 2. Zeile. Dann fehlt natürlich die letzte Zeile des Feldes. Ergänze diese fehlende Textzeile und wiederhole die Leseaktion.

TIPP: Um die erforderliche Textstruktur bei externer Erzeugung einer Datei zur Dateneingabe einzuhalten, wird empfohlen, zunächst eine entsprechende Datei als Muster auszugeben.

zurück   weiter

LESEFEHLER 110: Fehler beim Lesen eines Wertes

Fehlerbeschreibung:

Es erscheint z.B. folgende Meldung:

Diese Fehlermeldung erscheint, wenn das Programm einen Wert eines skalaren Parameters oder eines Datenfeldes lesen will, die gelesene Zeichenkette je nach Typ der Variablen aber nicht als ganze oder Gleitkommazahl interpretieren kann. Dabei wird angegeben, welchen Parameter das Programm gerade lesen wollte. Wenn der Parameter ein Datenfeld repräsentiert, wird auch angegeben, an welcher Stelle im Feld der Fehler aufgetreten ist.

TIPP: Diese Stelle ist aber in der Regel nicht die eigentliche Fehlerquelle. Z.B. kann diese Fehlermeldung erscheinen, wenn in der Datei eine Textzeile zu viel oder zu wenig existiert und das Programm versucht dann aus dieser oder einer folgenden Zahlen zu lesen, obwohl sie Text enthält.

Die Fehlermeldung kommt auch, wenn ganze Zahlen erwartet werden, aber Gleitkommazahlen angeboten werden. Umgekehrt ist das nicht der Fall.

Die Fehlermeldung ist enthalten in den Routinen "FormSchale", "FormWelle", "LesenDruckP", "LesenKX", "LesenMatrixChp", "LesenPara5", "LesenVarPara".

Fehlerbehebung:

Korrigiere den Fehler in der Datei.

Suche dazu evtl. in vorhergehenden Zeilen der Datei nach dem Fehler. Vergleiche dazu die bisher eingelesenen Daten mit denen in der Datei vorliegenden Daten. Dazu kann die Datei mit einem Text-Editor geöffnet, gelesen und evtl. auch korrigiert werden.

zurück   weiter

LESEFEHLER 111: Dateiende beim Lesen eines Wertes

Fehlerbeschreibung:

Es erscheint z.B. folgende Meldung:

Diese Fehlermeldung erscheint, wenn das Programm einen Wert eines skalaren Parameters oder eines Datenfeldes lesen will, das Ende der Datei aber bereits erreicht ist. Dabei wird angegeben, welchen Parameter das Programm gerade lesen wollte. Wenn der Parameter ein Datenfeld repräsentiert, wird auch angegeben an welcher Stelle im Feld der Fehler aufgetreten ist.

TIPP: Diese Stelle ist aber in der Regel nicht die eigentliche Fehlerquelle. Z.B. kann diese Fehlermeldung erscheinen, wenn in der Datei eine Textzeile fehlt und das Programm beginnt erst ab der 2.Zeile die Daten zu lesen. Dann erreicht es vorzeitig das Dateiende.

Die Fehlermeldung ist enthalten in den Routinen "FormSchale", "FormWelle", "LesenDruckP", "LesenKX", "LesenMatrixChp", "LesenPara5", "LesenVarPara".

Fehlerbehebung:

Vervollständige die Datei bzw. korrigiere den Fehler in der Datei.

Suche dazu evtl. in vorhergehenden Zeilen der Datei nach dem Fehler. Vergleich dazu die bisher eigelesenen Daten mit denen in der Datei vorliegenden Daten. Dazu kann die Datei mit einem Text-Editor geöffnet, gelesen und evtl. auch korrigiert werden.

zurück   weiter

FEHLERMELDUNG 112: Variablenname nicht erkannt

Fehlerbeschreibung:

Es erscheint z.B. folgende Meldung:

Das Programm liest Zeichenfolgen von maximal 12 Zeichen aus Textzeilen der Eingabe-Datei und versucht, diese als einen dem Programm bekannten Variablennamen zu identifizieren, damit die danach folgenden Daten auf den richtigen Speicherplatz geschrieben werden. Gelingt das nicht, erscheint diese Fehlermeldung. Diese Fehlermeldung erscheint also, wenn ein Variablenname falsch geschrieben ist.

Diese Fehlermeldung erscheint aber auch, wenn ein bekannter Variablenname nicht in der richtigen Reihenfolge erscheint. In der Datei müssen nicht alle bekannten Variablen erscheinen, sondern nur die relevanten primären Eingabe- und Ergebnisparameter. Sie müssen aber in der vom Programm fest vorgegebenen Reihenfolge innerhalb der Eingabe-Datei aufgeführt werden.

Dieser Fehler kann aber auch auftreten, wenn einzelne Text- oder Datenzeilen in der Datei fehlen oder zu viele existieren, so dass sich Verschiebungen ergeben und das Programm versucht, aus den Zeichenfolgen nicht dafür vorgesehener Zeilen Variablennamen zu lesen.

HINWEIS: In den Datensicherungsdateien, die von SIRIUS ausgegeben und wieder eingelesen werden können, sind zwischen den Zeilen, die die eigentlichen vom Programm lesbaren Informationen enthalten, auch einige Textzeilen als Zwischenüberschriften eingefügt, die der manuellen Lesbarkeit der Dateien mit einem Texteditor dienen. Der Inhalt dieser Textzeilen wird beim Einlesen vom Programm in der Regel ignoriert und kann deshalb beliebig sein. Es müssen aber alle Überschriften an den entsprechenden Stellen als Textzeilen vorhanden sein, weil sonst das Programm beim zeilenweisen Lesen der Datei aus dem Tritt kommt.

Die Fehlermeldung ist enthalten in der Routine "LesenPara5".

Fehlerbehebung:

Korrigiere die Schreibweise des Variablennamens.

Stelle die richtige Reihenfolge der Daten her.

Beseitige überflüssige oder ergänze fehlende Zeilen.

Fehler, die das Programm nicht erkennt:

Das Programm akzeptiert alle Variablennamen, die ihm bekannt sind und in der richtigen Reihenfolge angeboten werden. Es bemerkt nicht, wenn ihm bekannte Variablen und die Daten dazu übergeben werden, die für die aktuell gelesene Lagervariante aber nicht relevant sind. Das ist kein Problem, weil diese Daten zwar unter diesem Variablennamen gespeichert werden, bei der Berechnung aber ignoriert werden.

Das Programm bemerkt aber auch nicht, wenn einige für die aktuell gelesene Lagervariante relevante Daten fehlen. Dann gelten die Werte weiter, die seit der letzten Berechnung der aktuellen Sitzung unter diesen Variablen abgespeichert sind. Wenn das Programm gerade gestartet wurde, sind das die Anfangswerte.

TIPP: An den Dateien, die die primären Eingabe- und Ergebnisdaten enthalten, sollte nicht extern manipuliert werden. Dann tritt dieser Fehler auch nicht auf. Die einzige Änderung die problemlos möglich ist, ist die Änderung der Textzeilen zum Titel der Berechnungsvariante.

zurück   weiter

FEHLERMELDUNG 113 Fehlerhafte Reihenfolge der zeitlich variablen Parameter in LesenVarPara

Fehlerbeschreibung:

Es erscheint z.B. folgende Meldung:

Diese Fehlermeldung kann erscheinen, wenn versucht wird, die zeitlich variablen Eingabeparameter aus einer Datei einzulesen. Das Programm liest die 4.Textzeile der Datei gemäß Bild 4.146, in der die Bezeichnungen und die Reihenfolge der für den aktuellen Fall relevanten zeitlich variablen primären Eingabeparameter angegeben sind. Entsprechen die hier angegebenen Bezeichnungen oder die Reihenfolge nicht den Erwartungen des Programms, kommt diese Fehlermeldung.

Die hier für einen konkreten Fall gezeigte Meldung erscheint z.B. dann, wenn das Hauptmenü "Eingeben bzw. ändern der zeitabhängigen (variablen) Parameter" eine Datenstruktur gemäß folgender Menüdarstellung fordert und die Datei gemäß Bild 4.146 in der 4. Zeile andere Namen anzeigt, bzw. ein Name fehlt.



Bild 4.146: Fehlerhafte 4.Zeile einer Eingabedatei "varpara.txt" zur Eingabe der zeitlich variablen primären Eingabeparameter

Die Fehlermeldung muss nicht nur auf Schreibfehlern in der 4. Zeile beruhen. In den meisten Fällen ist mit dieser Meldung auch zu rechnen, wenn versucht wird, einen an sich korrekten Datensatz zu lesen, der aber von einer anderen Lagervariante stammt und nicht zu der aktuellen Lagervariante passt.

Die Fehlermeldung ist enthalten in der Routine "LesenVarPara".

Fehlerbehebung:

Wenn Du der Meinung bist, dass der Datensatz in der Datei korrekt ist, dann korrigiere die aktuellen Eingabedaten im Programm SIRIUS in der Weise, dass das Programm genau so einen Datensatz anfordert. Ändere dazu im Menü "Festlegungen zur Theorie, zum Berechnungsverlauf und zum Lagertyp" die Merkmale der zu simulierenden Lagervariante. Wenn Du der Meinung bist, dass Deine bisherigen Eingaben zur Lagervariante im Programm SIRIUS korrekt sind, dann wähle eine andere geeignete Datei aus oder erstelle extern eine neue oder geänderte Datei, die der vom Programm geforderten Struktur entspricht. Die Reihenfolge der Spalten der verschiedenen Parameter muss dabei eingehalten werden.

TIPP: Um die erforderliche Textstruktur bei externer Erzeugung einer Datei zur Dateneingabe einzuhalten, wird empfohlen, zunächst eine entsprechende Datei als Muster auszugeben.

Fehleingaben, die das Programm nicht erkennt:

Das Programm geht davon aus, dass die Werte in den Spalten natürlich auch den Parametern entsprechen, die in der Überschrift der 4.Zeile angegeben sind. Es ist also darauf zu achten, dass bei Korrekturen in der Überschrift auch die entsprechenden Daten darunter inhaltlich korrekt abgelegt werden, weil das Programm das nicht kontrollieren kann.

zurück   weiter

FEHLERMELDUNG 115: Fehler beim Lesen eines Testparameters

Fehlerbeschreibung:

Es erscheint z.B. folgende Meldung:

Das Programm hat versucht eine Zeile einer Eingabe zu lesen, in der der Wert und die Bezeichnung eines Testparameters erwartet wird, z.B. der Parameter "Dim". Konnte die Datei diese Zeile nicht lesen, so erscheint diese Fehlermeldung. Eine Ursache könnte sein, dass das Programm die ersten Zeichen nicht als ganze Zahl erkennen konnte. Zur Lokalisierung der fehlerhaften Zeile wird außerdem der Variablenname der zuletzt erfolgreich gelesenen Zeile angegeben. Ist der Variablenname leer, konnte bereits der 1.Parameter nicht gelesen werden.

Die Fehlermeldung ist enthalten in den Routinen "FormSchale", "FormWelle", "LesenDruckP", "LesenKX", "LesenMatrixChp", "LesenVarPara".

Fehlerbehebung:

Korrektur der entsprechenden Zeile und erneut versuchen, diese Datei zu lesen.

TIPP: Um die erforderliche Textstruktur bei externer Erzeugung einer Datei zur Dateneingabe einzuhalten, wird empfohlen, zunächst eine entsprechende Datei als Muster auszugeben.

zurück   weiter

FEHLERMELDUNG 116: Dateiende beim Lesen eines Testparameters

Fehlerbeschreibung:

Es erscheint z.B. folgende Meldung:

Das Programm hat versucht eine Zeile einer Eingabe zu lesen, in der der Wert und die Bezeichnung eines Testparameters erwartet wird, z.B. der Parameter "Dim". Wurde dabei bereits das Ende der Datei erreicht, erscheint die Fehlermeldung.

Die Fehlermeldung ist enthalten in den Routinen "FormSchale", "FormWelle", "LesenDruckP", "LesenKX", "LesenMatrixChp", "LesenVarPara".

Fehlerbehebung:

Vervollständigung der Datei und erneut versuchen, diese Datei zu lesen.

zurück   weiter

FEHLERMELDUNG 121: Zu große Elastizitätsmatrix Chp

Fehlerbeschreibung:

Es erscheint z.B. folgende Meldung:

Entsprechend der aktuell maximal zugelassenen Anzahl der Gitterpunkte NXZMax=NXMax·NZMax zur Diskretisierung der Schmierspaltfläche könnte die zugehörige Elastizitätsmatrix Chp(NZ,NX,NZP,NXP) im ungünstigsten Fall sehr groß werden. Dazu ist im Programm ein entsprechender Speicherplatz zu reservieren. Da dieser Extremfall nur selten auftreten wird, auch aus dem Grund, weil die dazu notwendige FEM-Berechnung sehr aufwendig ist, wird weniger Speicherplatz für das Feld Chp reserviert, nämlich "nur" NChpMax Koeffizienten. Deshalb wird vor jedem Lesen einer Elastizitätsmatrix geprüft, ob diese für das aktuelle Programm nicht zu groß ist.

Ist die Matrix zu groß, lehnt das Programm das Lesen dieses Feldes ab und gibt die Fehlermeldung aus (s.o.). Da das Feld Chp das letzte ist, welches gelesen wird und alle anderen Werte offenbar schon fehlerfrei gelesen wurden, korrigiert das Programm ausnahmsweise einen bisher bereits gelesenen Steuerparameter, so dass die Lagervariante jetzt auch ohne Elastizitätsmatrix als starres Lager widerspruchsfrei simuliert werden könnte. Dazu wird der Steuerparameter "Schale" von 5 auf 1 oder von 6 auf 4 geändert. In der Eingabe-Datei bleibt dieser Wert unverändert.

Die Fehlermeldung ist enthalten in den Routinen LesenMatrixChp" und "LesenPara5".

Fehlerbehebung:

Soll trotzdem mit dieser großen Elastizitätsmatrix chp gearbeitet werden, muss der Parameter NChpMax im Programm entsprechend vergrößert werden. Das ist nur durch Änderung des Quellcodes möglich, aber ansonsten recht einfach. Siehe dazu Anleitung im Abschnitt 4.2.9.

zurück   weiter

FEHLERMELDUNG 122: Falsche Reihenfolge der Teil-Elastizitätsmatrizen

Fehlerbeschreibung:

Es erscheint z.B. folgende Meldung:

Das 4-dimensionale Feld Chp(NZ,NX,NZP,NXP) ist in der Eingabe-Datei als eine Anzahl 2-dimensionaler Teilmatrizen gespeichert. Die Reihenfolge dieser Teilmatrizen ist fest vorgeschrieben, damit jeder gelesene Wert im Programm an der richtigen Stelle in dem 4-dimensionalen Feld Chp abgelegt wird. Diese komplexe Elastizitätsmatrix wird mit einem externen FEM-Programm berechnet und muss mit einem eigens dafür programmierten Hilfsprogramm aus dem FEM-Programm gelesen werden und in eine von SIRIUS lesbare Form gebracht werden. Durch Vertauschen der Teilmatrizen können dabei leicht Fehler entstehen, die das Endergebnis verfälschen würden, aber evtl. nachträglich nur schwer zu erkennen sind. Deshalb wird die richtige Reihenfolge jeder gelesenen Teilmatrix überprüft und gegebenenfalls diese Fehlermeldung ausgegeben. Dazu wird die Zeile " 4·13 = JZP·JXP " vor jeder Teilmatrix ausgewertet.

Die Fehlermeldung ist enthalten in den Routinen LesenMatrixChp" und "LesenPara5".

Fehlerbehebung:

Es ist die richtige Reihenfolge der Teilmatrizen in der Eingabe-Datei herzustellen. Wahrscheinlich ist dazu das Hilfsprogramm zur Transformation der Daten von der Bereitstellung durch das FEM-Programm zur Lesbarkeit durch SIRIUS zu korrigieren.

WARNUNG: Es sind nicht nur die Nummern in den Zwischenzeilen zu ändern, es ist auch dafür zu sorgen, dass die entsprechenden Teilmatrizen folgen.

zurück   weiter

FEHLERMELDUNG 201: Minimale Spalthöhe HMin nicht positiv

Fehlerbeschreibung:

Es erscheint z.B. folgende Meldung:

Trotz der Plausibilitätsprüfungen der einzelnen Eingabeparameter, die die Spalthöhe bestimmen, kann die Überlagerung der verschiedenen Formelemente leicht dazu führen, dass sich an einigen Stellen im Schmierspalt eine Spalthöhe kleiner oder gleich Null ergibt, was bei der Eingabe nicht sofort erkennbar ist und erst während der Hauptrechnung entdeckt wird. Sinnvolle Ergebnisse in der hydrodynamischen Schmierung sind nur mit positiven Spalthöhen zu berechnen. Deshalb muss das Programm die Hauptrechnung abbrechen. Nach Abbruch der Hauptrechnung geht das Programm in den PostProzessor, wo durch numerische oder grafische Darstellung der aktuellen Spaltgeometrie Hinweise auf die Fehlerursache gesucht werden können.

Diese Fehlermeldung ist enthalten in den Routinen "SpaGeo4" und "SpaGeo5".

Fehlerbehebung:

Je nach aktuell angenommener Lagervariante musst Du alle aktuell relevanten Parameter analysieren, die Einfluss auf die Spaltgeometrie haben, und geeignete Änderungen vornehmen.

HINWEIS: Auch bei den Berechnungen der sekundären Ergebnisse werden die Routinen SpaGeo4 und SpaGeo5 angewendet und es könnte auch hier diese Fehlermeldung erscheinen. Nach einer erfolgreichen Hauptrechnung ist das aber nicht möglich, weil dann bereits sicher geklärt ist, dass zu allen Zeitpunkten im gesamten Schmierspalt die Spalthöhe größer Null ist. Wenn aber nach einer Dateneingabe die Hauptrechnung übersprungen oder umgangen wurde und danach im PreProzessor die Spalthöhen nummerisch oder grafisch angezeigt werden sollen, kann diese Fehlermeldung ebenfalls auftreten. Hier kann die Aktion zur Darstellung der Spaltgeometrie fortgesetzt werden, so dass man sich trotz Fehlermeldung das Ergebnis ansehen kann, wie z.B. in Bild 4.147.



Bild 4.147: Darstellungsbeispiel einer Spaltgeometrie mit negativer minimaler Spalthöhe

zurück   weiter

FEHLERMELDUNG 202: Fehler im peripheren Schmiersystem

Fehlerbeschreibung:

Es erscheint z.B. folgende Meldung:

Im Hauptmenü "Universal-Schmiermittel-Versorgungssystem" kann ein recht komplexes Schmiermittel-Versorgungssystem modelliert werden. Dabei werden bei der Eingabe einzelner Daten, soweit möglich, sofort Konsistenzprüfungen durchgeführt und Eingabefehler sofort gemeldet. Das ist aber, bezogen auf eine widerspruchsfreie Struktur des Gesamtsystems, nicht für jede einzelne Eingabe sinnvoll. Deshalb wird am Ende der Bearbeitung das Schmiersystem einer komplexen Kontrolle unterzogen. Diese Kontrolle kann manuell gestartet werden durch Auswahl der Aktion -30- "Systemkonsistenz prüfen". Die Kontrolle wird aber auch automatisch gestartet, wenn versucht wird, das Hauptmenü "Universal-Schmiermittel-Versorgungssystems" mit der Aktion <w> zum nächsten Hauptmenü zu verlassen. Stellt das Programm dabei Fehler fest, so gibt das Programm die FEHLERMELDUNG 202 aus, in der alle Beanstandungen aufgelistet sind. Die Kenntnisnahme dieser Meldung muss mit ENTER bestätigt werden und das Programm springt in das Hauptmenü zurück, so dass die Fehler beseitigt werden können.

So lange nicht alle Fehler beseitigt sind, kann nicht zum nächsten Hauptmenü und weiter bis zum Ende der Eingabe und zum Start der Hauptrechnung gesprungen werden. Es ist aber möglich, trotz vorhandener Fehler zum vorhergehenden Hauptmenü oder in das Startmenü zurück zu springen. So ist es möglich, ohne eine evtl. aufwendige Fehlerbeseitigung, einen anderen Datensatz zu laden oder die Eingabe von vorne zu beginnen.

Wenn eine oder mehrere Schmiertaschen mit keiner Verbindungleitung und damit auch mit keiner Schmiermittelpumpe verbunden sind, dann ist das kein Fehler. In diesem Fall wird nur eine Warnung ausgegeben, so dass der Anwender noch einmal Bedenken kann, ob das auch wirklich beabsichtigt ist. Wenn keine Fehlermeldung und nur eine Warnung erscheint, kann der Anwender frei entscheiden, ob er zum nächsten Hauptmenü weitergehen möchte oder zurück zum aktuellen Hauptmenü.

Die Fehlermeldung und die Warnung sind enthalten in der Routine "SchmierPruefen".

Fehlerbehebung:

Bestätigung der Fehlermeldung mit ENTER und Beseitigung der Fehler durch entsprechende Eingaben im Hauptmenü "Universal-Schmiermittel-Versorgungssystem".

Bestätigung der Fehlermeldung mit ENTER und Rücksprung aus dem Hauptmenü zum vorhergehenden Hauptmenü. Evtl. Beginn einer vollständig neuen Eingabe einer anderen Lagervariante, ohne vorher die Fehler zu beseitigen.

Fehleingaben, die das Programm nicht erkennt:

Der Rücksprung aus dem Hauptmenü "Universal-Schmiermittel-Versorgungs-System" eröffnet nicht nur die Möglichkeit, ohne eine vorherige aufwendige Fehlerbeseitigung der aktuellen Lagervariante eine neue Lagervariante einzugeben. Es eröffnet sich über den "Schleichweg":->Startmenü->PostProzessor-> Solver mit diesem fehlerhaften Datensatz eine Hauptrechnung zu starten, was zu unkontrollierbaren Fehlern führen kann.

zurück   weiter

FEHLERMELDUNG 203: Konsistenzprüfung der konstanten Parameter

Fehlerbeschreibung:

Es erscheint z.B. folgende Meldung:

Beim Eintritt in das Hauptmenü "Eingeben bzw. ändern der konstanten Parameter" werden zunächst alle aktuell relevanten konstanten Parameter dieses Menüs auf Konsistenz überprüft. Findet das Programm einen Fehler, erscheint die Fehlermeldung 203. Es werden die Bedingungen angegeben, die offenbar nicht eingehalten wurden, und es erfolgt eine Eingabeaufforderung. Erst nach einer Eingabe, die die Bedingung erfüllt, kann diese Änderungsaufforderung verlassen werden.

Sind mehrere relevante Parameter fehlerhaft, erscheint nach der Abarbeitung eines Fehlers die nächste Fehlermeldung. Sind alle Fehlermeldungen abgearbeitet erscheint das vollständige Hauptmenü zur weiteren Bearbeitung.

Die Konsistenzprüfungen, die beim Eintritt in das Hauptmenü durchgeführt werden, sind die gleichen, die auch bei der Eingabe des jeweiligen Parameters durchgeführt werden. Da alle Anfangsparameter konsistent sind und in dem Hauptmenü nur konsistente Parameter eingegeben werden können, dürfte diese Fehlermeldung eigentlich nicht auftreten. Mit dieser Prüfung werden aber die Fehler entdeckt, die evtl. in eingelesenen Datensätzen durch externe unsachgemäße Manipulationen am Datensatz entstanden sind. Es ist auch möglich, dass einige Parameter, die in einer vorher bearbeiteten Lagervariante konsistent oder nicht relevant waren, beim Wechsel in die aktuelle Variante nicht mehr konsistent sind.

Diese Fehlermeldung ist enthalten in der Routine "KonstParaPruefen".

Fehlerbehebung:

Ändere den angegebenen Parameter, so dass er die angegebene Bedingung erfüllt.

zurück   weiter

FEHLERMELDUNG 204: Sym=1 und KoWe≠0

Fehlerbeschreibung:

Es erscheint z.B. folgende Meldung:

Beim Eintritt in das Hauptmenü "Eingeben bzw. ändern der konstanten Parameter" werden zunächst alle aktuell relevanten konstanten Parameter dieses Menüs auf Konsistenz überprüft. Stellt das Programm fest, das im Hauptmenü "Festlegen zur Theorie, zum Berechnungsverlauf und zum Lagertyp" festgelegt wurde, dass das Lager vollständig symmetrisch sein soll (Sym=1) und mit KoWe ≠ 0 die Welle außerdem konisch sein soll, wird dieser Widerspruch durch die Fehlermeldung 204 angezeigt. Außerdem behebt das Programm den Fehler, indem KoWe=0 gesetzt wird. Der Festlegung, dass das Lager symmetrisch sein soll, wird hier die höhere Priorität gegeben.

Diese Fehlermeldung ist enthalten in den Routinen "KostParameter" und "KonstParameterDim".

Fehlerbehebung:

Soll das Lager tatsächlich symmetrisch sein und damit die Welle nicht konisch, ist nur die angezeigte Meldung mit ENTER zu quittieren.

Soll doch mit einer konischen Welle gerechnet werden, musst Du in das Hauptmenü "Festlegen zur Theorie, zum Berechnungsverlauf und zum Lagertyp" zurück gehen und ein asymmetrisches Lager vereinbaren. Danach kannst Du einen Wert für KoWe ungleich Null eingeben.

zurück   weiter

FEHLERMELDUNG 205 Sym=1 und KoLa≠0

Fehlerbeschreibung:

Es erscheint z.B. folgende Meldung:

Beim Eintritt in das Hauptmenü "Eingeben bzw. ändern der konstanten Parameter" werden zunächst alle aktuell relevanten konstanten Parameter dieses Menüs auf Konsistenz überprüft. Stellt das Programm fest, das im Hauptmenü "Festlegen zur Theorie, zum Berechnungsverlauf und zum Lagertyp" festgelegt wurde, dass das Lager vollständig symmetrisch sein soll (Sym=1) und mit KoLa ≠ 0 die Lagerschale außerdem konisch sein soll, wird dieser Widerspruch durch die Fehlermeldung 205 angezeigt. Außerdem behebt das Programm den Fehler, indem KoLa=0 gesetzt wird. Der Festlegung, dass das Lager symmetrisch sein soll, wird hier die höhere Priorität gegeben.

Diese Fehlermeldung ist enthalten in den Routinen "KostParameter" und "KonstParameterDim".

Fehlerbehebung:

Soll das Lager tatsächlich symmetrisch sein und damit die Lagerschale nicht konisch, ist nur die angezeigte Meldung mit ENTER zu quittieren.

Soll doch mit einer konischen Lagerschale gerechnet werden, musst Du in das Hauptmenü "Festlegen zur Theorie, zum Berechnungsverlauf und zum Lagertyp" zurück gehen und ein asymmetrisches Lager vereinbaren. Danach kannst Du einen Wert für die KoLa ungleich Null eingeben.

zurück   weiter

FEHLERMELDUNG 206: Konsistenzprüfung der Parameter NPu, NVe und NVar

Fehlerbeschreibung:

Es erscheint z.B. folgende Meldung:

Beim Eintritt in das Hauptmenü "Universal-Schmiermittel-Versorgungssystem" werden zunächst die 3 Parameter NPu, NVe und NVar auf Konsistenz geprüft. Wird hier ein Fehler entdeckt, wird die Fehlermeldung 206 ausgegeben, mit der Aufforderung diesen Parameter umgehend zu korrigieren. Alle anderen aktuellen Parameter des Schmiersystems und die Menüzeilen werden erst angezeigt, wenn für diese 3 Parameter die Konsistenz hergestellt ist.

Diese Fehlermeldung ist enthalten in der Routine "Schmiersystem".

Fehlerbehebung:

Es ist ein Wert einzugeben, der die angegebene Bedingung einhält.

zurück   weiter

FEHLERMELDUNG 207: Konsistenzprüfung der Bezugsparameter

Fehlerbeschreibung:

Es erscheint z.B. folgende Meldung:

Beim Eintritt in das Hauptmenü "Eingeben bzw. ändern der Bezugsparameter" werden zunächst alle Bezugsparameter auf Konsistenz überprüft. Findet das Programm einen Fehler, erscheint die Fehlermeldung 207. Es werden die Bedingungen angegeben, die nicht eingehalten wurden, und es erfolgt eine Eingabeaufforderung. Erst nach einer Eingabe, die die Bedingung erfüllt kann diese Änderungsaufforderung verlassen werden.

Sind mehrere relevante Parameter fehlerhaft, erscheint nach der Abarbeitung eines Fehlers die nächste Fehlermeldung. Sind alle Fehlermeldungen abgearbeitet erscheint das vollständige Hauptmenü zur weiteren Bearbeitung.

Die Konsistenzprüfungen, die beim Eintritt in das Hauptmenü durchgeführt werden, sind die gleichen, die auch bei der Eingabe des jeweiligen Parameters durchgeführt werden. Da alle Anfangsparameter konsistent sind und in dem Hauptmenü nur konsistente Parameter eingegeben werden können, dürfte diese Fehlermeldung eigentlich nicht auftreten. Mit dieser Prüfung werden aber die Fehler entdeckt, die evtl. in eingelesenen Datensätzen durch externe unsachgemäße Manipulationen am Datensatz entstanden sind. Diese Fehlermeldung ist enthalten in der Routine "DimParameter".

Fehlerbehebung:

Ändere den angegebenen Parameter, so dass er die angegebene Bedingung erfüllt.

zurück   weiter

FEHLERMELDUNG 208: Sym=1 und Kante=2

Fehlerbeschreibung:

Es erscheint z.B. folgende Meldung:

Stellt das Programm fest, das im Hauptmenü "Festlegen zur Theorie, zum Berechnungsverlauf und zum Lagertyp" festgelegt wurde, dass das Lager vollständig symmetrisch sein soll (Sym=1) und außerdem die Welle in der Lagerschale verkantet sein soll (Kante=2), wird dieser Widerspruch durch die Fehlermeldung 208 angezeigt. Außerdem behebt das Programm den Fehler, indem Kante=1 gesetzt wird. Der Festlegung, dass das Lager symmetrisch sein soll, wird hier die höhere Priorität gegeben.

Diese Fehlermeldung ist enthalten in den Routinen "Steuerpara".

Fehlerbehebung:

Soll das Lager tatsächlich symmetrisch sein und damit die Wellenachse parallel zur Lagerachse liegen, ist keine weitere Maßnahme erforderlich.

Soll doch mit einer verkanteten Welle gerechnet werden, musst Du zuvor ein asymmetrisches Lager vereinbaren. Danach kannst Du auch eine verkantete Welle vereinbaren (Kante=2).

zurück   weiter

FEHLERMELDUNG 209: Sym=1 und Versatz=2

Fehlerbeschreibung:

Es erscheint z.B. folgende Meldung:

Stellt das Programm fest, das im Hauptmenü "Festlegen zur Theorie, zum Berechnungsverlauf und zum Lagertyp" festgelegt wurde, dass das Lager vollständig symmetrisch sein soll (Sym=1) und außerdem die Sondervariante Versatz=2 "Zwei versetzte Lagerabschnitte" festgelegt wurde, wird dieser Widerspruch durch die Fehlermeldung 209 angezeigt. Außerdem kommt die Aufforderung den Parameter Versatz zu ändern.

Diese Konstellation ist ein Widerspruch, weil sich bei der Annahme von 2 versetzten Lagerabschnitten eine asymmetrische Druckverteilung im Schmierspalt ergibt. Die Variante Versatz=3 "Drei versetzte symmetrische Lagerabschnitte" ist bei Annahme eines vollständig symmetrischen Lagers zulässig. Beschreibung der Sondervariante "Versetzte Lagerabschnitte" siehe Abschnitt 2.1.2.16.

Diese Fehlermeldung ist enthalten in den Routinen "Steuerpara".

Fehlerbehebung:

Wähle für das Merkmal Versatz entweder -1- "Keine versetzten Lagerabschnitte" oder -3- "Drei versetzte symmetrische Lagerabschnitte".

Soll trotzdem die Lagervariante "2 Versetzte Lagerabschnitte" vereinbart werden, ist hier zunächst die Variante 1 oder 3 auszuwählen, um aus dem Widerspruch herauszukommen. Dann musst Du zunächst ein asymmetrisches Lager vereinbaren (Aktion -4- im aktuellen Hauptmenü). Danach kannst Du mit Aktion -7- und Variante -2- die gewünschten 2 versetzten Lagerabschnitte vereinbaren.

zurück   weiter

FEHLERMELDUNG 210: Zu große Datenfelder in der Eingabe

Fehlerbeschreibung:

Es erscheint z.B. folgende Meldung:

Für die im Programm verwendeten Datenfelder sind maximale Größen festgelegt durch die Parameter:

NXZMax Maximale Anzahl der Gitterpunkte NX·NZ
NTMax Maximale Anzahl der Zeitpunkte NT
NTaMax Maximale Anzahl der Schmiertaschen NTa, der Schmiermittelpumpen NPu, der Verbindungsleitungen NVe und der Gerätevarianten NVar
NTyp Anzahl der im Programm implementierten Gerätetypen
NPaMax Maximale Anzahl der möglichen Parameter NPa(JVar) zur Beschreibung eines Gerätetyps

Diese Parameter sind im Programm fest einprogrammiert und können nur durch Quelltextänderungen geändert werden (siehe Abschnitt 4.2.9). Da diese Obergrenzen relativ leicht geändert werden können, können Programmversionen mit unterschiedlichen Obergrenzen in Benutzung sein, die ansonsten kompatibel sind. Deshalb können auch Eingabe- und Ergebnisdatensätze vorliegen mit Feldgrößen, die größer sind als die Obergrenzen der aktuell benutzten Programmvariante.

Um zu vermeiden, dass Felder in zu kleine reservierte Speicherplätze geschrieben werden, wurden deshalb entsprechende Tests eingebaut. Hier wird sofort nach dem Lesen der Parameter NX, NZ, NT, NTa, NPu, NVe, NVar, NPa(JVar) und TypVar(JVar) für JVar= 1 bis NVar, die die erforderlichen Feldgrößen des Eingabedatensatzes angeben, geprüft, ob die im Programm verfügbaren Feldgrößen für den zu lesenden Datensatz ausreichend sind.

Diese Fehlermeldung ist enthalten in der Routine "LesenPara5".

Fehlerbehebung:

Es ist zunächst zu prüfen, ob diese Fehlermeldung evtl. auf einer unsachgemäßen externen Manipulation am gelesenen Datensatz beruht, die dann zu korrigieren ist.

Es ist die Programmvariante zu verwenden, mit der dieser Datensatz erzeugt wurde.

Es sind die verfügbaren Feldgrößen des Programms, gemäß Abschnitt 4.2.9, zu erweitern.

zurück   weiter

FEHLERMELDUNG 211: NGlei>NGleiMax

Fehlerbeschreibung:

Es erscheint z.B. folgende Meldung:

Falls das Programm mit ungepackter Matrix arbeitet, gilt als Obergrenze für die Anzahl der Gleichungen des Gleichungssystems der Parameter NGleiMax.

Diese Fehlermeldung ist enthalten in den Routinen "FilmDruck1" der Quellcodedatei "FilmDruck1_unpack.f" und der Routine "FilmDruck2" der Quellcodedatei "FilmDruck2_unpack.f".

Fehlerbehebung:

Der Fehler kann behoben werden, indem die Anzahl der Gitterpunkte NX und/oder NZ verkleinert wird.

Durch Eingriff in den Quellcode kann auch der Parameter NGleiMax geändert werden. Siehe dazu Abschnitt 4.2.9.

zurück   weiter

FEHLERMELDUNG 212: Vollum=2, deshalb Welle=1 bzw. =2

Fehlerbeschreibung:

Es erscheint z.B. folgende Meldung:

Beim Eintritt in das Hauptmenü "Festlegungen zur Theorie, zum Berechnungsverlauf und zur Lagervariante" werden zunächst alle relevanten Steuerparameter dieses Menüs auf ihre Konsistenz überprüft. Dabei hat das Programm einen Wiederspruch zwischen den Steuerparametern "Vollum" und "Welle" entdeckt.

Dem zuerst gezeigten Parameter "Vollum" wird vom Programm der Vorrang gegeben. Dementsprechend wird der nachfolgende Steuerparameter "Welle" auf einen zulässigen Wert korrigiert. Aus Welle=3 wird Welle=1. Aus Welle=4 wird Welle=2.

Diese Fehlermeldung ist enthalten in der Routine "Steuerpara".

Fehlerbehebung:

Da der Fehler automatisch korrigiert wird, sind keine weiteren Aktionen erforderlich.

Soll im Lager trotzdem mit einer punktweise gegebenen Formabweichung der Welle gearbeitet werden, ist zuvor für das Lager das Merkmal "Voll umschlossene Lagerschale" (Vollum=1) festzulegen.

TIPP: Soll bei einem Lager, dessen Lagerschale die Welle nur teilweise umschließt, trotzdem mit einer punktweise gegebenen Formabweichung der Welle gearbeitet werden, ist das trotzdem möglich. Dazu wird formal eine voll umschlossene Lagerschale angenommen und der gesamte Bereich der Lagerschale, der die Welle nicht umschließt, wird zu einer großen Schmiertasche erklärt. Danach ist ein punktweise gegebenes Feld von Formabweichungen ΔhWe0 bzw. ΔHWe0 der Welle über ihren gesamten Umfang einzugeben.

Siehe dazu auch Abschnitt 4.4.2.8.

zurück   weiter

FEHLERMELDUNG 221: Zu große Elastizitätsmatrix (unbearbeitet)

...

zurück   weiter

FEHLERMELDUNG 222: Vollum=2, deshalb NSym3=1 (unbearbeitet)

...

zurück   weiter

FEHLERMELDUNG 301: GMRES konvergiert nicht

Fehlerbeschreibung:

Es erscheint z.B. folgende Meldung:

Diese Fehlermeldung kann erscheinen während der Berechnung einer Druckverteilung im Schmierspalt. Sie besagt, dass die iterative Berechnung instabil ist und das GMRES-Verfahren zur Lösung eines linearen Gleichungssystems nach 300 Iterationen die geforderten Genauigkeitskriterien immer noch nicht erfüllt hat. Die Ursachen und Möglichkeiten zur Behebung des Problems sind ausführlicher beschrieben im Abschnitt 4.9.2.

Diese Fehlermeldung ist enthalten in den Routinen "FilmDruck1" und "FilmDruck2".

zurück   weiter

FEHLERMELDUNG 302: Iteration des Wellenverlagerungspunktes konvergiert nicht

Fehlerbeschreibung:

Es erscheint z.B. folgende Meldung:

Diese Fehlermeldung kann erscheinen bei der Berechnung einer Verlagerungsbahn der Wellenachse aus einem vorgegebenen Belastungsverlauf des Lagers. Sie deutet daraufhin, dass das Iterationsverfahren zur Ermittlung eines Wellenverlagerungspunktes überfordert ist und nicht mehr konvergiert. Die Ursachen und Möglichkeiten zur Behebung des Problems sind ausführlicher beschrieben im Abschnitt 4.9.2.

Diese Fehlermeldung ist enthalten in den Routinen "Verlagerung1" und "Verlagerung2".

zurück   weiter

.

.

.