mein Rechner scheint ein Problem mit meiner Simulation zu haben. Weiß aber leider nicht woran dies liegt. Gibt es eine Möglichkeit die SImulation zu verzögern, bzw Pausen einzufügen in denen sich der Rechner wieder "beruhigen" kann? In dieser Zeit könnte ich auch Variablen auslesen und deren Werte löschen, damit die verwendeten Byte nicht zu groß werden.
Wie schaffe ich es damit zum Beispiel nach 20 Sekunden ne Pause zu machen?
Versuche mir mit dem oben erfragten Vorgehen eine Möglichkeit zu schaffen dieses folgende Problem zu umgehen. Eine genauere Beschreibung des Problems findest du hier.
Falls das Modell mit variabler Schrittweite arbeitet, könnte die Beschreibung damit zusammen hängen, dass für eine Weile sehr kleine Schritte numerisch nötig sind und es den Eindruck hat, dass ein Problem vorliegt.
bis ca. 33.7s läuft die Simulation bei mir durch. Zwar nicht schnell, aber sie läuft.
Die genaue Ursache des Problems konnte ich nicht feststellen. Ein paar Hinweise habe ich jedoch:
- Du verwendest fsolve zum Lösen eines Gleichungssystems in jedem Simulationsschritt. Das Problem dabei ist, dass fsolve nicht immer eine Lösung findet. Du solltest also auf jeden Fall exitflag abfragen um festzustellen, ob es irgendwelche Probleme gibt (d.h. exitflag < 0).
- Wenn ich die Simulation abbreche und u ansehe, sehe ich am Ende so etwas:
0,506846442902508
0,506846442897964
-1120401,85285371
-1120453,38638938
0,506846442903247
-1120416,24679726
-1120401,85284955
0,506846442907093
0,506846442905161
... und das bei einer mikroskopischen Schrittweite. D.h. es gibt irgendein Problem in dem System. Evtl. läuft FSOLVE je nach Iteration in eine andere Lösung? Kann aber auch was anderes sein.
- Du scheinst dir die Verwendung verschiedener Algorithmen der Optimization TB überlegt zu haben. Dir ist aber klar, dass sie unterschiedliches versuchen? FSOLVE löst eine Gleichung (d.h. möglichst nahe an 0), FMINCON minimiert eine Größe. Es müsste also ggf. auch MYFUN.M angepasst werden.
- Der Aufbau dieser Anwendung ist recht unübersichtlich, insbesondere die Verwendung von globalen Variablen ist schlimm anzusehen.
- Du scheinst dir die Verwendung verschiedener Algorithmen der Optimization TB überlegt zu haben. Dir ist aber klar, dass sie unterschiedliches versuchen? FSOLVE löst eine Gleichung (d.h. möglichst nahe an 0), FMINCON minimiert eine Größe. Es müsste also ggf. auch MYFUN.M angepasst werden.
Das ist mir bedingt klar. Im Endeffekt für variable Werte von v, F=Null werden.
Also max(es,er)*xRx - 1 = 0. Der Wert (v) für den dies zutrifft soll zurückgegeben werden und in der Embedded Matlab Function verwendet werden. Dabei gilt das v maximal 1 sein darf und danach stetig fällt bis zu einer Grenze (hier vmin=0.1).
Da ich keine Grenze bei fsolve verwenden konnte habe ich mit anderen Funktionen experimentiert. Bin aber letztendlich wieder zu fsolve gekommen und habe dann eine if Abfrage eingebaut.
Zitat:
- Der Aufbau dieser Anwendung ist recht unübersichtlich, insbesondere die Verwendung von globalen Variablen ist schlimm anzusehen.
Das glaube ich dir gerne. Leider habe ich überhaupt keine Ahnung von Matlab gehabt bevor ich mit der Aufgabe anfing. Auch gab es keinen Kurs oder so.
Zitat:
- Wenn ich die Simulation abbreche und u ansehe, sehe ich am Ende so etwas:
0,506846442902508
0,506846442897964
-1120401,85285371
-1120453,38638938
0,506846442903247
-1120416,24679726
-1120401,85284955
0,506846442907093
0,506846442905161
... und das bei einer mikroskopischen Schrittweite. D.h. es gibt irgendein Problem in dem System. Evtl. läuft FSOLVE je nach Iteration in eine andere Lösung? Kann aber auch was anderes sein.
Das ist mir auf einem anderen Rechner auch aufgefallen aber dort konnte dann letztendlich bis 60 sec problemlos simuliert werden. Kann sein das ich dort eine minimale Schrittweite eingestellt hatte.
Das ist mir auf einem anderen Rechner auch aufgefallen aber dort konnte dann letztendlich bis 60 sec problemlos simuliert werden. Kann sein das ich dort eine minimale Schrittweite eingestellt hatte.
Letzteres bedeutet, dass unter Ignoranz von in Ungenauigkeiten resultierenden Problemen einfach weitersimuliert wird. Das heißt aber auch, dass die Lösung dann wertlos ist, weil man sie letztlich genausogut auswürfeln könnte.
japp das werde ich auch anregen. Ich meine es gibt einen Grundkurs, in welchem man aber nichts lernt ausser eben das 1*1 in MAtlab und das ist deutlich zu wenig. Auch ist diesr nicht Pflicht und wenn man ihn macht kommt es nur darauf an wie das Ergebnis aussieht aber nicht der Weg.
Habe meinen Fehler so glaube ich gefunden. Ich habe v ja nur als skalar und da kann ich dann fzero benutzen.
Ich bin nur noch nicht dahinter gekommen warum er in gewissen Intervallen nicht sucht.
Gruß Thomas
P.S.: Danke dir für den Link, den werde ich mir mal anschauen
bei FZERO sucht ausgehend vom Startpunkt nach der "nächsten" Nullstelle. Je nach Funktion kann die allerdings weiter vom Startwert weg sein als die tatsächlich nächste Nullstelle.
Wenn du die Suche auf ein Intervall beschränken willst, ist vielleicht FMINBND besser geeignet.
Wenn das nicht ausreicht, bitte Problematik konkretisieren.
also das Problem mit FMINBND ist, das er keine Nullstelle findet, sondern immer mit dem maximalen Startwert für die Suche arbeitet. FZERO hingegen findet Nullstellen, welche auch stimmen, nur springt er irgendwann in seiner Suche zu weit. Wenn ich dies jedoch unterbinde geht es. Leider bedeutet dies, das ich für jeden Initialzustand erst mühsam von Hand suchen muss ob es solche Stellen gibt.
Nun wird ausgehend von der ersten Nullstelle v = 0.8015, der Wert v immer geringer auf der Suche nach Nullstellen. Soweit so gut. Jedoch springt das Intervall auf dem die Nullstelle gesucht wird bei der Simulationszeit 59,6835 plötzlich. So dass er 5 Intervalle auflistet in denen keine Nullstelle gefunden wurde und letztendlich findet er eine zwischen (grob gesagt) -10 und 10. Diese liegt ungefähr bei v = -7.
v darf aber laut Definition des Reglers nur zwischen 0 und 1 liegen. Wegen möglicher nummerischer Probleme bei einer Division durch Null, wird der Minimalwert für v jedoch auf 0.1 gelegt.
Wie sich herausstellt gibt es auch eine Nullstelle die für den Zeitwert t = 59.6835 auf dem Intervall 0.1 - 1 liegt. Um diese zu finden habe ich die Optimierung wie folgt verändert. Ich füge dem obigen code noch diesen Part bei.
Code:
if v < 0
v0 = 0.2;
[v,fval,exitflag] = fzero(@myfun,v0,options);
end
So kommt für jeden Simulationsschritt ein Ideales v von 1 heraus. Ich weis nun nicht ob es daran liegt das die Grenzen zu Nahe beieinander liegen. In der doc fminbnd steht, das es dann passieren kann das immer die obere Grenze heraus gegeben wird.
dass du je nach Startzeit unterschiedliche Startwerte verwendest ist doch legitim? Ich könnte mir z.B. auch vorstellen, 0, 0.5 und 1 als Startwerte zu verwenden und dann abzuprüfen, wann ich ein (bzw. das beste) Minimum zwischen 0 und 1 bekomme.
Was FMINBND angeht:
Du hast schon daran gedacht, die myfun.m entsprechend anzupassen?
Statt Nullstelle suchen kannst du ja das Quadrat minimieren.
stimmt auch wieder. Legitim ist es, aber auch aufwendig es von Hand jedesmal abzuändern, in dem Wissen das es eine Nullstelle geben muss, welche aber leider nicht automatisch gefunden wird.
Ich stehe bezüglich der Abänderung des myfun.m Files auf dem Schlauch.
Reicht es F= (max(es,er)*xRx-1)^2 zu ändern oder gibt es da mehr?
Was muss ich da genau ändern?
super Harald, weiß gar nicht wie ich dir danken soll.
Gruß Thomas
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