Leider funktioniert das nicht.
Ist dieses Problem einfach nicht auf diese Art lösbar mit ODE oder habe ich irgendeinen blöden Fehler eingebaut?
Mit dem selbstgestrickten Integrator eines Kollegen (Runde-Kutta 4. Ordnung) habe ich es auf diese Weise zum Laufen gebracht.
Wir wäre es aber wesentlich lieber einen der Matlab-interne Integratoren zu verwenden.
2) global oder persistant:
Allerdings ist mir nicht ganz klar, wie ich die Größe (oder stattdessen ) innerhalb von ODE richtig aufrufen kann.
3) OutputFcn:
Dieser Vorschlag stammt von einem Kollegen. Aber entweder habe ich die Option OutputFcn missverstanden, oder was ich brauche funktioniert damit nicht.
da muss man schon bei der Formulierung aufpassen. Ein Bezug auf den vorherigen (Simulations-) Schritt ist bei Differentialgleichungen nicht eindeutig, da dieser Schritt je nach verwendetem Verfahren unterschiedlich lang her sein kann, und somit meines Erachtens nicht sinnvoll.
Was ggf. sinnvoll wäre: eine Verzögerung um einen fest vorgegebenen Zeitraum. Damit hätte man eine Delay Differential Equation, die z.B. mit dde23 gelöst werden kann.
Bitte also die Problemformulierung nochmal überdenken.
entschuldige - hier war ich etwas ungenau.
Ich möchte auf den letzten abgeschlossenen Integrationsschritt zurückgreifen und keine Iterationen innerhalb eines Integrationsschrittes. Ich hatte vor mit fixed steps (und nicht variable steps) zu rechnen, darum bin ich davon ausgegangen, dass das nicht das Problem sein sollte.
Danke für den Hinweis mit den DDE, ich werde es so versuchen!
ode45 ist ein Variable-Step Löser.
Ich sehe nach wie vor das Problem, dass die Lösung je nach Schrittweite variiert. Mir scheint, dass hier kontinuierliche und diskretisierte Formulierung vermischt wird, und das halte ich für keine gute Idee.
Wenn du die Anwendung erläutern kannst, kann man evtl. auch bei der Problemformulierung helfen.
Wenn man ode45 einen Zeitvektor vorgibt und nicht nur Start- und Endzeit, dann gibt der Algorithmus auch nur zu diesen fixen Schrittweiten eine Lösung aus. Ich dachte, das könnte man vielleicht innerhalb einer Schleife nutzen - scheint aber nicht so zu sein?
Mein Code ist ziemlich lang und ich glaube nicht, dass es zweckmäßig ist, ihn hier zu posten.
Im Konkreten geht es um ein vereinfachtes Fahrzeugmodell mit 7 Differentialgleichungen (3 Gleichungen für die Beschleunigungen des Chassis und 4 für die Raddrehbeschleunigungen). Soweit würde das auch noch gut funktionieren.
Damit das Ergebnis trotz des vereinfachten Modells aber exakter wird, brauche ich für ein internes Reifenmodell die Radlastschwankungen, die sich durch im Schwerpunkt angreifende Horizontalbeschleunigungen ergeben. Diese Beschleunigungen entsprechen genau der 1. und 2. Differentialgleichung. Da sich diese beiden Größen nicht sehr schnell mit der Zeit ändern, habe ich kein Problem damit, wenn dieser Wert in Integrations-Zwischenschritten nicht aktualisiert wird.
Hoffentlich war das einigermaßen verständlich
Deinem Hinweis mit den DDE werde ich, sofern nicht wieder was dazwischen kommt, morgen nachgehen!
Wenn man ode45 einen Zeitvektor vorgibt und nicht nur Start- und Endzeit, dann gibt der Algorithmus auch nur zu diesen fixen Schrittweiten eine Lösung aus.
Stimmt, dazu muss der Zeitvektor aber mehr als 2 Elemente haben.
Zitat:
Ich dachte, das könnte man vielleicht innerhalb einer Schleife nutzen - scheint aber nicht so zu sein?
Können grundsätzlich ja. Ob es sinnvoll ist, ist eine andere Frage.
Zitat:
Da sich diese beiden Größen nicht sehr schnell mit der Zeit ändern, habe ich kein Problem damit, wenn dieser Wert in Integrations-Zwischenschritten nicht aktualisiert wird.
Die Frage müsste eigentlich andersherum lauten: was spricht dagegen, diesen Wert in Integrations-Zwischenschritten zu aktualisieren?
grundsätzlich spricht gar nichts dagegen, dass der Wert auch in Zwischenschritten aktualisiert wird. Nichts anderes machen auch DDEs, wenn ich das richtig verstanden habe?
Ich hatte ursprünglich eher (unbegründete) Angst vorm Rechenaufwand.
Die Variante mit den DDEs habe ich übrigens probiert mit meinem Modell - und das funktioniert super!
Die Variante mit den Schleifen ist deshalb für mich auch interessant, weil das Laufen des Modells eigentlich erst der erste Schritt für mich ist. In weiterer Folge möchte ich auch noch Sensitivitäten der Zustandsvariablen auf eine der Eingangsgrößen untersuchen. Dafür brauche ich eine numerische Berechnung der Jacobi-Matrizzen, die ich mit Adimat (http://www.sc.informatik.tu-darmstadt.de/res/adimat/) berechnen möchte.
Zeilenweise funktioniert Adimat auch schon mit meinem Code, die genaue Vorgangsweise muss ich mir noch im Detail durchschauen. Ich befürchte, dass das Gesamtsystem dann nur noch zeilenweise lösbar ist.
Dass ich einen Zeitvektor mit mehr als 2 Elementen vorgeben muss, damit eine fixe Schrittweite von ODE verwendet wird, ist mir an und für sich bewusst. Wenn mir keine bessere Lösung einfällt (was bisher noch nicht der Fall war), würde ich ganz unelegant pro Zeitschritt einen Zeitvektor mit drei Einträgen vorgeben mit [t0 tm te].
Dabei ist t0 der Startwert in diesem Zeitschritt, tm ein mittlerer Wert (tm = t0 + h/2 mit der Schrittweite h) und te der Endwert (te = t0 + h);
Hast du hier vielleicht noch eine "elegantere" Idee?
Du hast mir mit aber auf jeden Fall schon sehr viel geholfen!
Vielen Dank dafür!
grundsätzlich spricht gar nichts dagegen, dass der Wert auch in Zwischenschritten aktualisiert wird. Nichts anderes machen auch DDEs, wenn ich das richtig verstanden habe?
DDEs beschreiben prinzipiell eine andere Dynamik als ODEs. Die zugrundeliegende Idee ist hier, dass eine Größe tatsächlich erst mit zeitlicher Verzögerung Einfluss auf das System nimmt. Die Anzahl der Funktionsauswertungen wird dabei typischerweise nicht sinken!
Was die Adimat-Sache angeht: mir ist nicht klar, was dagegen spricht, ode45 die Lösung direkt auf einem bestimmten Gitter berechnen zu lassen, ohne irgendwelche Schleifen.
Zitat:
Hast du hier vielleicht noch eine "elegantere" Idee?
Ich denke ja. Vektor [startwert, endwert] als tspan verwenden und nur das letzte Element des zurückgegebenen y verwenden. Ein Zwischenschritt zur Extrahierung dieses letzten Elements wird sich dabei nicht vermeiden lassen.
Falls sich der Rechenaufwand tatsächlich als problematisch herausstellen sollte, hätte ich noch eine Idee: in der ode-Funktion mit statischen Variablen arbeiten. Kurzbeispiel:
Code:
persistent last_update
persistent radlast_daten
ifisempty(last_update)
last_update = -inf;
radlast_daten = []; % vermutlich nicht notwendig end if t > last_update + 10% hier z.B. nach 10 Sekunden ein Update % radlast_daten aktualisieren
last_update = t;
end
wie bereits zuvor gesagt: DDEs modellieren eine andere Dynamik als ODEs. Ich würde also nicht einfach eine ODE in eine DDE "umwandeln". Vor allem würde ich da jetzt auch keine großen Unterschiede hinsichtlich Simulationszeit erwarten, so dass diese Umwandlung auch aus dieser Sicht unnötig ist.
Grüße,
Harald
Gast
Beiträge: ---
Anmeldedatum: ---
Wohnort: ---
Version: ---
Verfasst am: 04.11.2013, 13:10
Titel:
Hallo,
ich habe mir zwar eingebildet, ich hätte die Frage schon vorletzte Woche abgeschickt - war aber wohl nicht so...
Was meinst du denn genau mit einer anderen Dynamik der DDE?
Ich hab ein paar Manöver durchsimuliert, von denen ich weiß, was als Ergebnis rauskommen soll, und das hat eigentlich ganz gut funktioniert.
bei DDEs ist die Idee, dass die Wirkung tatsächlich zeitverzögert ist.
Stelle dir z.B. vor, dass du zwei Wassertanks hast, die miteinander verbunden sind. Nun könnte man sagen, dass der Abfluss von einem der Zufluss vom anderen sein muss.
Wenn man lange Leitungen zwischen den Tanks hat, muss man aber eine Zeitverzögerung (delay) berücksichtigen, um die Transportzeit mit zu modellieren.
Wenn es aber keine solche Zeitverzögerung gibt und man trotzdem eine einbaut, dann ist das m.E. nicht sinnvoll.
Grüße,
Harald
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