... soweit verstehe ich das ja alles wie das für eine "einzelne" DGL funktioniert; aber ich schaffe es nicht so wirklich das nun auf mein DGL-System anzuwenden.
Irgendwie denke ich hier etwas zu umständlich; oder ich weiß einfach nicht wie ich "fun()" entsprechend abändern müsste.
Vielleicht kann mir hier jemand "unter die Arme greifen"?
die DGLen hast du ja schon aufgestellt. Du brauchst eigentlich nur noch aus y1 bis y4 dann y(1) bis y(4) zu machen.
Grüße,
Harald
amtmann
Gast
Beiträge: ---
Anmeldedatum: ---
Wohnort: ---
Version: ---
Verfasst am: 02.09.2017, 17:05
Titel:
Hallo Harald,
Zitat:
die DGLen hast du ja schon aufgestellt. Du brauchst eigentlich nur noch aus y1 bis y4 dann y(1) bis y(4) zu machen.
danke für Deine Antwort - bin mittlerweile auch dahintergekommen. Ich hatte nur einen Knoten im Kopf bzgl. der Übertragung des RK-Verfahrens auf DGL-Systeme ...
Eines, was mir noch einfällt ist etwas anderer Natur. Die DGL die ich hier Löse gilt prinzipiell als "steif". Allerdings bin ich mir ob ihrem "Steifheitsmaß" nicht so sicher, da sowohl ode45 als auch ode23s die DGL gut lösen können; ode45 braucht zwar geringfügig mehrere Schritte je Zeitschritt (41) als ode23s (11), was mich etwas wundert. Ich dachte, dass da sicher der Faktor 100 oder so dazwischenliegt.
Nun denn, ich habe mich nun etwas auch mit den Rosenbrock-Methoden (wie z.B. ode23s) beschäftigt, da mit diese für mein Problem etwas effizienter erscheinen, und bin über https://www.mathworks.com/help/pdf_doc/otherdocs/ode_suite.pdf auf den Abschnitt 3.1. gestolpert, der die in ode23s "verbauten" Gleichungen beschreibt.
Allerdings bin ich auf dem Gebiet von impliziten RK/RO-Methoden ein richtiger "Newbie". Allerdings möchte ich mir auch einen ähnlichen Löser wie ode23s schreiben, da ich die Matlab-Suite leider in einem "externen" Programm nicht verwenden kann/darf.
Ist es viel aufwändiger, ein derartiges Verfahren zu programmieren, als z.B. das vorhin thematisierte DP-Verfahren?
Gibt es evtl. hierzu auch ähnliche Codesnippets, an denen ich mich orientieren kann bzw., die ich auf meine Bedürfnisse anpassen kann?
es ist sehr ungewöhnlich, dass man die fertigen Löser nicht verwenden kann / darf. Darf ich nach dem Grund dafür fragen?
Grüße,
Harald
amtmann
Gast
Beiträge: ---
Anmeldedatum: ---
Wohnort: ---
Version: ---
Verfasst am: 02.09.2017, 20:06
Titel:
Hallo,
Zitat:
es ist sehr ungewöhnlich, dass man die fertigen Löser nicht verwenden kann / darf. Darf ich nach dem Grund dafür fragen?
Sicherlich. Ich muss das o.g. Problem leider in einer Basic-ähnlichen Skriptsprache gelöst bekommen, die selbst keinerlei fertige Algorithmen bereitstellt und nur if/else/schleifen bzw. als "höchsten" Datentyp eindimensionale Arrays kennt.
Bisher habe ich das so gemacht, dass ich die ursprüngliche DGL auf analytischem Weg je Zeitschritt gelöst habe, wobei ich unterstelle, dass sich während eines Zeitschrittes die Koeffizienten der DGL nicht ändern. - Diese Näherung war aus ingenieurmäßiger Sicht hinreichend genau und hat auch gut funktioniert, allerdings treten mit fortschreitender Zeit irgendwann in den Exponenten der e-Funktionen große Zahlen auf, die leider dann einen Overflow verursacht haben - kurz: das Lösungsgleichungssystem war irgendwann immer sehr schlecht skaliert.
Ich versuche zunächst noch, meine Eingangsdaten anders zu skalieren, dass ich z.B. nicht in Tagen sondern in Monaten oder Halbjahren rechne, sodass besagte e-Funktionen relativ kleine Exponenten haben (3 Jahre im Vergleich zu 1000 Tagen macht hier schon einen unterschied).
Den "alternativsten" Weg wollte ich nun beschreiten durch das selbstständige Programmieren eines Zeitintegrationsverfahrens, um dieses dann "inkrementell" zu verwenden: Die DGL wird nun wiederum in Zeitschritte geteilt und auf jeden Zeitschritt wird das Verfahren angewendet. Die Werte die das Verfahren am Ende für y, y', y'' ... ermittelt hat, dienen dann als Anfangswerte für den folgenden Zeitschritt usw.
Um mich nicht den Rosenbrockmethoden (die ich - da ich nur "einfacher Bauingenieur" bin - noch nicht durchschaut habe) stellen zu müssen, habe ich zunächst versucht, ob sich denn auch z.B. mit ode45 oder auch ode23 auf obige DGL zur Lösung anwenden ließe.
Zu meiner Verwunderung hat beides recht unkompliziert geklappt (ode23 auch mit weniger Schritten) obwohl ich der Meinung war, dass die DGL selbst eine steife DGL ist und ich definitiv zu einem impliziten Verfahren ausweichen muss. (Die exakte Lösung ist nämlich von der Form y = S+ Summe_i_N C_i*exp(-bk*t), wobei i = 1, ..., 5 und bk = 0.1, 1, 10, 100, 1000, und S eine Konstante ist.)
Es zeigt sich wohl, dass ode45 mehrere Funktionsaufrufe als ode23s benötigt, dennoch habe ich - beim Vergleich eines Zeitschrittes der Matlab-Solver [die sicher 1000fach besser als eine eigene Implementierung sind] - den Unterschied zwischen 11 (ode23s und auch ode23) und 41 (ode45) nicht allzu groß empfunden.
- Vor allem da ich in meiner bisherigen Lösung auch je Zeitschritt ständig die Nullstellen des charakteristischen Polynoms (Bairstow-Verfahren) ermitteln und eine Gauss-Elimination durchführen muss und das wohl auch annähernd gleich viele Rechenschritte bedeutet ...
Ganz kurz zusammengefasst: Der Grund liegt in einer Skriptsprache, die die Matlabfunktionalität nicht bereitstellt bzw. in die ich diese leider nicht direkt einbinden kann. (Ich hätte zwar noch die Möglichkeit LUA zu verwenden, allerdings weiß ich auch hier nicht, ob man in LUA Matlab-Funktionen "einfach" einbinden kann, ohne diese selbst schreiben zu müssen ...).
sorry, dass ich weiter bohre, aber so ersoarst du dir vielleicht viel Arbeit:
Warum musst du diese Skript-Sprache bzw. LUA verwenden?
Falls es darum geht, den Algorithmus auf spezielle Hardware aufzuspielen, können vielleicht auch die Codegenerierungsmöglichkeiten von MATLAB weiterhelfen?
Eiegene ODE-Solver in einer beliebigen Sprache zu schreiben, ist kein Hexenwerk. Alelrdings ist es nicht trivial die Funktionen zu Testen und die Ergebnisse zu validieren. Eine numerisch korrekte Integration benötigt unbedingt auch eine Analyse der Sensitivitäten, also der Empfindlichkeit der berechneten Trajektorie von einer Variation der Startwerte und der Parameter. Wenn eine Trajektorie hier sehr empfindlich ist (also "instabil"), ist die Integration eher eine Art komplizierter Zufallszahlen-Generator.
Das ODE45 4 mal so viele Funktionsauswertungen für ein steigfes System benötigt wie für ODE23 ist durchaus plausibel, hängt aber auch von der verwendeten Toleranz ab. Das kann darüber hinaus aber auch starke Auswirkungen auf die Sensitivität der Lösung haben.
Zitat:
Ganz kurz zusammengefasst: Der Grund liegt in einer Skriptsprache, die die Matlabfunktionalität nicht bereitstellt
Da dies hier ein Matlab-Forum ist, würde ich den Thread in die Kategorie Off-Topic verschieben, falls die Diskussion sich nicht auf Matlab bezieht.
Gruß, Jan
Einstellungen und Berechtigungen
Du kannst Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen. Du kannst Dateien in diesem Forum posten Du kannst Dateien in diesem Forum herunterladen
MATLAB, Simulink, Stateflow, Handle Graphics, Real-Time Workshop, SimBiology, SimHydraulics, SimEvents, and xPC TargetBox are registered trademarks and The MathWorks, the L-shaped membrane logo, and Embedded MATLAB are trademarks of The MathWorks, Inc.
RSS