Verfasst am: 01.06.2020, 17:13
Titel: Multistart abbrechen, aber Code weiter ausführen
Hallo zusammen,
ich lasse einen Multistart-fmincon Algorithmus laufen, wobei die Parameter User-seitig über eine GUI eingegeben werden können. Multistart-fmincon ruft die Funktion "nParam" auf, die die restlichen Funktionen steuert (und am Ende dann die CostFunction ausgibt, aufgrund derer fmincon weiter sucht). Nun habe ich vier Probleme/Fragen:
Ich habe einen "Stop" Button implementiert. Dieser hat eine Variable, die dann auf 1 gesetzt wird. Bei nParam wird bei jedem Durchlaufen am Anfang getestet, ob diese Variable 1 ist.
Code:
if(h.StoppButton.UserData == true) error('Stop Button pushed');
end
Hiermit beende ich normalerweise den Matlab Code. Ist eher eine unschöne Form, allerdings weiß ich keine bessere.
Nun meine vier Fragen:
1) Gibt es eine schönere Form als einen Error rauszuwerfen, um Multistart-fmincon zu beenden? Hintergrund ist auch der, dass nachdem Multistart durchgelaufen ist, noch weiterer Code ansteht, der ausgeführt werden soll ... Also speziell die Frage: Gibt es eine Return-Anweisung für solche Algorithmen? Und kann man hier unterscheiden zwischen "fmincon abbrechen und nächste Multistart-Startpunkt testen" und "Multistart komplett beenden, aber Code weiter ausführen"?
2) Nun ein Problem: Meine Berechnung pro fmincon-Iteration ist relativ groß (ein Run dauert gut und gern mal 1-2 Sekunden, da zwischendurch auch noch Daten auf die Festplatte geschrieben werden UND geplottet wird auch). Nun habe ich beobachtet, dass fmincon deutlich länger pro Run braucht, je mehr Iterations ich schon hatte. Das klingt ganz stark danach, dass hier irgendein Speicher vollläuft. Kann das sein? Mein Problem hat ca. 30 Variablen und mehrere Konstanten (unveränderliche Variablen). Und falls ja: Was tun, damit dieser Speicher geleert wird / ausgelagert wird oÄ?
3) Zu meinem Stopp-Button noch eine Frage: Solange ich noch nicht so viele Iterationen hatte (sagen wir mal, innerhalb der ersten 50-100 Runs), kann ich den Stop Button so wie er jetzt ist, zeitnah benutzen. Je mehr Runs ich aber durchlaufen habe, umso zeitverzögerter reagiert dieser Button. Das sehe ich auch daran, dass der Button zu allererst eine msgbox ausgibt, auf der steht "Wait". Am Anfang kommt diese msgbox relativ schnell nach "PressButton", aber nach 1500 Runs braucht das dann gut und gern mehr als 30 min, bis diese msgbox ausgegeben wird. Woran liegt das, dass es hier diesen delay gibt?
4) Ich stolpere immer wieder über parallel computing, da ich für 1500 Runs den Computer schon mal eine Nacht durchlaufen lassen muss. Das ginge ja mit Multistart. Da ich aber uA Daten auf die Festplatte schreibe und auch Daten plotte, ist das für mich überhaupt nicht zugänglich, oder? Oder gibt es eine Möglichkeit, dass quasi ein Sperr-Flag gesetzt wird, während ein Worker an Datei1 schreibt, sodass Worker 2 wartet, bis Worker1 fertig ist, usw.?
Vielen Dank für Eure Antworten schon mal.
LG
Michi
Ich habe mal verschiedene Code-Schnipsel angehängt, wo ich hoffe, dass sie Euch helfen. Wenn wichtige Infos fehlen, reiche ich die natürlich gern nach =)
StopButton:
Code:
Button pushed function: StoppButton
function StoppButtonPushed(app, event)
f = msgbox('Wait till End pls', 'Wait','help');
runningFlag = 0;
app.StoppButton.UserData = true;
app.StartButton.Enable = 'on';
app.StoppButton.Enable = 'off';
app.RunningLamp.Color = 'red';
delete(f);
end
Und zwei kleine Fragen hintendran:
1) fmincon läuft manchmal 20 Runs, manchmal 50 Runs. Woran liegt das? Hängt das mit xTolerance zusammen?
2) Weiß nParam, in welchem Multistart-Run es sich befindet? Kann ich also unterscheiden in "Multistart - Run Index 5" und "fmincon innerhalb der Startparameter 5, Run 10"?
1) OutputFcn erlaubt selbst gewählten Abbruch. Sowohl multiStart als auch fmincon haben eine OutputFcn, und so kannst du auch unterscheiden, was abgebrochen werden soll.
2)
Zitat:
da zwischendurch auch noch Daten auf die Festplatte geschrieben werden UND geplottet wird auch
Das halte ich für keine gute Idee. Die Funktionsauswertungen werden ja in erster Linie genutzt, um den Gradienten zu schätzen.
Wenn, dann sollten solche Operationen in die OutputFcn.
Zitat:
Und falls ja: Was tun, damit dieser Speicher geleert wird / ausgelagert wird oÄ?
Dateien, die geöffnet werden, auch wieder schließen.
Statt vieler Handles auf kleine Plots sollte möglichst ein Handle verwendet werden und die Daten darin erweitert werden.
3) Dürfte mit 2) zusammenhängen, insbesondere den vielen Handles.
4) Eine Möglichkeit wäre, jeden Prozess in eine andere Datei schreiben zu lassen und die Dateien am Ende zusammenzufügen. Ansonsten ist so etwas grundsätzlich möglich, aber wird sehr umständlich und vermutlich nicht unbedingt förderlich für die Performance.
2.1) An unterschiedlichen Startwerten. Je nachdem wie nah der Startwert an welchem lokalen Minimum ist, braucht man mal mehr, mal weniger Iterationen.
2.2) Nicht dass ich wüsste. Da die Reihenfolge der Runs aber nicht wichtig ist, wüsste ich auch nicht, für was man diese Information bräuchte.
Grüße,
Harald
_________________
1.) Ask MATLAB Documentation
2.) Search gomatlab.de, google.de or MATLAB Answers
3.) Ask Technical Support of MathWorks
4.) Go mad, your problem is unsolvable ;)
Natürlich funktioniert es wieder mal nicht auf Anhieb, vielleicht kannst Du mir nochmal einen Denkanstoß geben?
1a) Nach jedem fmincon Run wird ein Counter um eins erhöht. Dadurch weiß ich, wie oft fmincon durchläuft.
Ich habe eine OutputFcn eingebaut, wie Du vorgeschlagen hast. Nun soll fmincon nach jedem Run (nicht nach jedem gefunden Minimum) die OutputFcn aufrufen. Allerdings laufen bei fmincon noch weitere Runs, bis es die OutputFcn aufruft. Ich schätze, bis das Minimum gefunden wird. Gibts da einen Workaround? Denn ansonsten sehe ich vorerst keinen Unterschied zum 'nem Multistart-OutputFcn Aufruf, oder?
1b) Ich rufe also die OutputFcn auf. Dann wird stop = true gesetzt. Und dann läuft der nächste Multistart-Run durch.
==> Ich hätte gern, dass nach jedem fmincon Run die OutputFcn aufgerufen wird und wenn stop = true, dann soll sowohl fmincon als auch Multistart stoppen. Sodass man quasi "instant" unterbrechen kann. Geht das?
2a) Ich bin mir nicht sicher, warum es keine gute Idee ist. Ich möchte in meinem Bericht später auch zeigen können, dass es Funktionsauswertungen gab, die eben kein Minimum ergaben. Deswegen speichere ich die ganzen Eingabewerte, aber auch Zwischenberechnungen, die bei nParam laufen und gar nicht an fmincon / Multistart zurückgegeben werden (deswegen geht das auch nicht in einer OutputFcn). Und jetzt noch ein Grund à la "leichteste Weg": Der Code war ursprünglich mal dazu gedacht, ohne GUI / Algorithmus zu funktionieren. Da sollte zwischenzeitlich immer wieder die Zwischenberechnungen gespeichert werden. Jetzt habe ich den Algorithmus + eine GUI außen herum gebaut, würde aber ungern die 1500 Zeilen Code, die funktionieren, dahingehend ändern, dass eben die ganzen Zwischenberechnungen evtl. in der OutputFcn gemacht würden etc. (never touch a running system) ... Ich wüsste auf Anhieb auch nicht, ob das sinnvoll - schnell zu machen wäre.
2c) Das mit dem "ein Handle, viele Daten" muss ich mir noch überlegen. Im Moment weiß ich noch nicht, wie ich das umsetzen kann. Danke trotzdem für den Hinweis. Werden denn die handles, die ich in nParam aufrufe, nachdem nParam durchgelaufen ist, gelöscht, oder verbleiben die irgendwo in irgendeinem Speicher? Denn bei 30 handles für die ganzen Plots und 1500 Runs würden quasi 45.000 handles rauskommen ... Ein Grund für einen volllaufenden Speicher
2b) Ich schreibe Dateien ausschließlich mit dlmwrite. Ich dachte bisher, dass dlmwrite automatisch die Dateien schließt, die es öffnet. Stimmt das? Wenn nicht: Wie schließe ich diese? Da finde ich per googeln nichts ...
4) Okay, dann lass ich das weg
2.1) Ah okay, danke =) Hätte ich auch draufkommen können, sorry ...
2.2) Stimmt. Habe mich nur gefragt, ob das vom Caller weitergegeben wird =)
Vielen Dank nochmal für die Infos / Antworten / Hinweise =)
LG
Michi
Nach jedem fmincon Run wird ein Counter um eins erhöht. Dadurch weiß ich, wie oft fmincon durchläuft.
Ich vermute, du meinst, wie oft die Zielfunktion ausgeführt wird.
Zitat:
Nun soll fmincon nach jedem Run (nicht nach jedem gefunden Minimum) die OutputFcn aufrufen. Allerdings laufen bei fmincon noch weitere Runs, bis es die OutputFcn aufruft. Ich schätze, bis das Minimum gefunden wird.
Nein, die OutputFcn wird nach jeder Iteration aufgerufen. Innerhalb jeder Iteration wird die Zielfunktion wiederholt (bei 30 Parametern 30 Mal) aufgerufen, um den Gradienten zu schätzen.*
Zitat:
Gibts da einen Workaround?
Keinen mir bekannten. Aus meiner Sicht wäre das aber auch zuviel des guten.
Zitat:
Denn ansonsten sehe ich vorerst keinen Unterschied zum 'nem Multistart-OutputFcn Aufruf, oder?
Doch, da ist ein Unterschied, siehe *.
1b)
Zitat:
Ich hätte gern, dass nach jedem fmincon Run die OutputFcn aufgerufen wird und wenn stop = true, dann soll sowohl fmincon als auch Multistart stoppen.
Dann musst du innerhalb der OutputFcn für fmincon ein Flag setzen (z.B. in der App abgespeichert) und das in der OutputFcn von Multistart abfragen.
2a)
Zitat:
Ich möchte in meinem Bericht später auch zeigen können, dass es Funktionsauswertungen gab, die eben kein Minimum ergaben.
Die Formulierung finde ich merkwürdig.
fmincon führt Iterationen durch und in jeder Iteration eine Schätzung des Gradienten. Bei n Iterationen und p Parametern sind das etwa n*p Funktionsauswertungen, die letztlich dazu beitragen, das Minimum zu finden. Ich finde es sinnvoll, die Ergebnisse der Iterationen abzuspeichern, so wie es in diesem Beispiel gemacht wird:
https://www.mathworks.com/help/optim/ug/output-functions.html
Ich finde es stark überzogen, die Ergebnisse jeder einzelnen Funktionsauswertung abzuspeichern. Zudem würde ich persönlich auch sagen, dass der Bericht dann so umfangreich wird, dass ihn keiner mehr liest.
2c)
Zitat:
Werden denn die handles, die ich in nParam aufrufe, nachdem nParam durchgelaufen ist, gelöscht, oder verbleiben die irgendwo in irgendeinem Speicher?
Die Handles bleiben so lange bestehen, wie die Figure bestehen bleibt.
2b)
Zitat:
Ich dachte bisher, dass dlmwrite automatisch die Dateien schließt, die es öffnet. Stimmt das?
Ja.
Grüße,
Harald
_________________
1.) Ask MATLAB Documentation
2.) Search gomatlab.de, google.de or MATLAB Answers
3.) Ask Technical Support of MathWorks
4.) Go mad, your problem is unsolvable ;)
Es läuft jetzt so weit: Ich habe den Performance-Fresser ausfindig gemacht (zu viele Plots pro Iteration) und auch die OutputFcn laufen jetzt. Vielen Dank dafür.
2a) Es geht darum, dass ich im Bericht zeigen kann, dass auch wenn ich für zB Param1 und Param2 nur eine Lösung gefunden habe, ich trotzdem unzählige Kombinationen aus beiden versucht habe. Deswegen werde ich eine Art Map machen (x-Achse = die jeweilige Run-Nummer, y-Achse der Wert von Param1 bzw. Param2) und somit zeigen, dass ich das ganze Spektrum durchsucht habe, allerdings eben nur bei einer Kombination aus Param1 und 2 eine Lösung gefunden habe.
Jetzt habe ich eine (hoffentlich!) letzte Frage:
Ich plotte inzwischen nur noch, wenn ich in der Nähe eines lokalen Minimums bin. Das weiß ich, weil ich vorneherein eine Bedingung erfüllt haben muss (num_Peaks > 2) und nur falls das der Fall ist, möchte ich die Kostenfunktion als realen Wert ausgegeben haben. Ansonsten setze ich die Kostenfunktion gegen unendlich (10^6) und plotte nicht. Meine Kostenfunktion bewegt sich sonst im Bereich von 0-100. Das mit den num_Peaks > 2 ist gesetzt, quasi eine Randbedingung.
Ich habe geschaut, wie fmincon die neuen Werte setzt, um das Minimum zu finden. Und siehe da: Er setzt 20x die gleichen Werte ein und sagt dann, dass die entweder gleich 10^6 oder zwischen 0-100 wäre. Allerdings ändert er die Werte innerhalb dieser 20 Zielfunktions-Aufrufe nicht. Das ist ja nicht der Sinn der Sache, eigentlich sollte fmincon die Werte der Parameter ändern, um das Minimum zu finden, richtig? Ist schwierig zu erklären, deswegen habe ich mal eine kleine Tabelle unten angehängt, die hoffentlich ein bissi Licht reinbringt (der Code ist artifiziell extra hierfür geschrieben. Ich hoffe, das reicht trotzdem aus).
Unabhängig davon, wie die Kostenfunktion funktioniert und welche Startwerte usw. ich eingebe, sollte doch trotzdem fmincon quasi einen Startwert bekommen, dann von diesem Startwert (bzw. -werten) ausgehend das "umliegende Gebiet" untersuchen, indem verschiedene Werte mit ähnlichen Werten zum Startwert eingesetzt werden, um zu schauen, ob die Kostenfunktion ihren Wert ändert. Wenn ja, sollte weiterhin in dieser Richtung untersucht werden?
Tut mir Leid, dass das gewiss keine Fachsprache gerade ist
Weißt Du oder jemand anderes, woran das liegen könnte?
Ansonsten bräuchte ich ein reproduzierbares Beispiel.
Zitat:
Das weiß ich, weil ich vorneherein eine Bedingung erfüllt haben muss (num_Peaks > 2) und nur falls das der Fall ist, möchte ich die Kostenfunktion als realen Wert ausgegeben haben. Ansonsten setze ich die Kostenfunktion gegen unendlich (10^6)
Das sollte dann meiner Meinung nach als (nichtlineare) Nebenbedingung umgesetzt werden.
Grüße,
Harald
_________________
1.) Ask MATLAB Documentation
2.) Search gomatlab.de, google.de or MATLAB Answers
3.) Ask Technical Support of MathWorks
4.) Go mad, your problem is unsolvable ;)
vielen Dank nochmal!
Format long hat leider keine Änderung gebracht.
Ich habe einen Beispielscode angehängt. Das ist aus dem Orginalcode, allerdings natürlich extrem gekürzt. Ich hoffe, ich habe dabei keine Fehler reingemacht, aber auch hier sieht man, dass fmincon pro Run innerhalb eines Multistart-Runs immer die gleiche Zahl einsetzt (siehe angehängtes Bild).
Ich hätte erwartet, dass der Parameter auch innerhalb eines Multistart-Runs variiert.
Kurze Erklärung zum Code: ist aus dem Orginalcode, deswegen gibt es jetzt natürlich vieles, was ich einfach übernommen habe, in dem Beispiel aber keine Funktion hat. Ich habe auch die ganzen irreführenden Kommentare gelöscht, weil das nichts mit der Problematik zu tun hat. Bitte ignoriere auch die Code-Sinnhaftigkeit, weil das natürlich bei der Kürzung auch nicht mehr gegeben ist. Außerdem habe ich jetzt viele Parameter an fmincon übergeben, die nicht veränderlich sind (als upper bound und lower bound = initial value), das liegt aber daran, dass der User später alle Parameter wahlweise variabel oder fix einstellen können soll.
Einfachheitshalber plotte ich nur einen Parameter, allerdings selbstverständlich einen der Parameter, die durch fmincon verändert werden sollten ...
Es sollte jetzt pro fmincon-Run einmal der Parameter geplottet werden und 20x fmincon pro Multistart-Run durchlaufen werden. Warum genau 20x, weiß ich auch nicht, aber das wird wahrscheinlich intern eine Reglementierung sein, weil meine CostFunction_Output immer 1 ist. In meinem Orginalcode ist es natürlich nicht immer 1, aber auch die Kostenfunktion habe ich gekürzt. Ich hoffe, das passt trotzdem.
Ich hoffe, es ist verständlich, was mein Problem ist...
LG und danke nochmal,
Michi
für ein kleines Beispiel ist das sehr umfangreich und zumindest für mich schwierig zu verfolgen. Ich habe mir die scatter-Info mal im Command Window anzeigen lassen:
Wenn ich es richtig sehe, lässt du dir nur eine von vielen Komponenten (anscheinend die 7.?) anzeigen, und für die Schätzung des Gradienten wird eben immer nur eine Komponente variiert. Das ist eben genau der Grund, warum ich mir das nicht in der Zielfunktion machen würde, sondern nach jeder Iteration in der OutputFcn.
Dir fällt vielleicht auf, dass der Code immer langsamer wird. Das liegt daran, dass dein Code das Graphik-Fenster mit aus einem Punkt bestehenden Scatter-Plots "zumüllst". Besser: ein Scatter-Plot und die Daten verändern.
Grüße,
Harald
_________________
1.) Ask MATLAB Documentation
2.) Search gomatlab.de, google.de or MATLAB Answers
3.) Ask Technical Support of MathWorks
4.) Go mad, your problem is unsolvable ;)
Ja, Du hast alles richtig verstanden, viele Parameter, lediglich einer wird geplottet, um die Komplexität zu reduzieren (so dachte ich zumindest). Aber da das quasi aus dem Orginalcode rauskopiert ist, ist es gewiss nicht ganz einfach nachzuvollziehen, tut mir Leid. Ich hätte da evtl. nochmal bissi kürzen sollen, wollte aber so wenig wie möglich ändern (auch wenn quasi der ganze Code natürlich geändert wurde...). Lange Rede, kurzer Sinn:
Bei Deiner Tabelle sehe ich jetzt, dass Parameter 7 ein einziges Mal um 0.000001 % geändert wird. Ist das so gewollt? Ich hätte mir eigentlich vorgestellt, dass fmincon jeden Parameter öfters als ein einziges Mal um 0.000001 % ändert, um zu schauen, ob in der Nähe ein Minimum der CostFunction ist? Und auch in beide Richtungen, und nicht nur +0.000001 %.
Außerdem wirst Du, wenn Du die ganzen anderen Parameter siehst, feststellen, dass diese auch nicht variiert werden (wenn ich das richtig überblicke) ...
Ich versteh es irgendwie nicht. Ich hätte mir mehr "Aktion" vom fmincon um die Startwerte herum gewünscht, sodass fmincon wirklich sagen kann, dass um den Startwert herum kein Minimum zu finden ist.
Nachtrag: Das mit dem "es wird immer langsamer" weiß ich inzwischen. Das mit dem ScatterPlot + Daten verändern werde ich ausprobieren, danke!
Mein Lösung war es bisher, einfach nicht mehr zu plotten, dann ist der Code auch richtig schnell inzwischen. Das Leben ist kein Ponyhof
Bei Deiner Tabelle sehe ich jetzt, dass Parameter 7 ein einziges Mal um 0.000001 % geändert wird. Ist das so gewollt?
Ja. Es geht darum, den Gradienten über einen Differenzenquotienten zu schätzen. Je kleiner der Unterschied, desto genauer die Schätzung.
Zitat:
Ich hätte mir eigentlich vorgestellt, dass fmincon jeden Parameter öfters als ein einziges Mal um 0.000001 % ändert, um zu schauen, ob in der Nähe ein Minimum der CostFunction ist?
So funktionieren Gradientenverfahren aber nun mal nicht. Ich kann da nur raten, sich zumindest ein kleines Bisschen mit der Theorie hinter dem Verfahren vertraut zu machen. Es gibt durchaus Verfahren, die anders arbeiten, z.B.
patternsearch
.
Zitat:
Und auch in beide Richtungen
Das kannst du haben, indem du mit optimoptions FiniteDifferenceType auf central setzt. Der Hintergrund ist allerdings nicht, dass in beide Richtungen gesucht wird, sondern die Stabilisierung des Differenzenquotienten. Die meisten Funktionen haben es nämlich an fast allen Punkten so an sich, dass es, wenn es in die eine Richtung runter geht, in die andere rauf geht.
Zitat:
und nicht nur +0.000001 %.
Auch das kannst du anpassen, mit FiniteDifferenceStepSize.
Zitat:
Außerdem wirst Du, wenn Du die ganzen anderen Parameter siehst, feststellen, dass diese auch nicht variiert werden (wenn ich das richtig überblicke) ...
... und genau so soll es sein. Es wird immer genau ein Parameter verändert, um den Gradienten zu schätzen. In diese Richtung wird dann ein (zumindest anfangs längerer) Schritt gemacht.
Grüße,
Harald
_________________
1.) Ask MATLAB Documentation
2.) Search gomatlab.de, google.de or MATLAB Answers
3.) Ask Technical Support of MathWorks
4.) Go mad, your problem is unsolvable ;)
das hat mir extrem geholfen, vielen Dank!
Und Du hast Recht, eigentlich sollte man sich zuerst die Methoden anschauen, bevor man sie benutzt. Ich muss zu meiner (zugegebenermaßen recht schlechten) Verteidigung sagen, dass ich der Meinung war, dass es ein radialerer Such-Algorithmus wäre, der mehrere Parameter gleichzeitig verändert, um einen möglichst schnellen Weg zum Minimum zu finden, und ich habe deswegen da nicht weiter geschaut. Aber das werde ich die nächsten Tage ändern ...
Eventuell suche ich dann auch nach einem anderen Verfahren, welches einen radialeren Ansatz nutzt. Das wäre für mich im Moment noch intuitiver und ich sehe im Moment auch noch nicht den Vorteil von fmincon gegenüber eines solchen Verfahrens (Nachteil wäre, dass fmincon gefühlt deutlich langsamer ist, weil eben immer nur ein Parameter gleichzeitig verändert wird). Aber diese Meinung kann sich natürlich auch noch ändern, wenn ich mir das mal etwas genauer angeschaut habe ...
Also wirklich: Vielen lieben Dank, das war extrem hilfreich =)
LG
Michi
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