Verfasst am: 14.08.2017, 16:24
Titel: Globale Optimierung, aber wie?
Hallo Leute,
ich kämpfe leider seit geraumer Zeit mit einem Problem: Grundsätzlich habe ich eine Funktion (DGL), die einige freie Parameter besitzt. Diese Parameter soll ich nun so bestimmen, dass die Ergebniskurvenschar verschiedene Messkurven optimal trifft.
Ich habe dann viel im Forum und in den Tiefen des Internets quergelesen und nutze momentan lsqnonlin() und drumherum als "Wrapper" MultiStart, um mir verschiedene Startvektoren zu erzeugen. Gleichzeitig gebe ich untere und obere Grenzen der freien Parameter an.
Allerdings scheint mir das nicht sehr zielführend, da das Ergebnis sehr stark von den Startwerten abhängt. So habe ich z.B. vorhin gerade Multistart mit 2000 Instanzen laufenlassen, was mir letztlich einen Fehler von "1e-6" eingebracht hat. ... nicht besonders gut leider.
Durch "Herumspielen" mit den Parametern habe ich nach 2 Versuchen eine Wesentliche Verbesserung auf "5e-9" erreicht. Als ich dieses händisch gefundene Parameterset dann für lsqnonlin() und MultiStart als Startvektor eingegeben hatte, hat sich lsqnonlin() nicht mehr von diesem wegbewegt.
Das Problem, das ich sehe ist, dass die Eingangsparameter zu wenig stark variiert werden bzw. auf der anderen Seite ich kein "TypicalX" vorgeben kann (bzw. möchte, aus "Angst", dadurch möglicherweise die Optimale Lösung "auszugrenzen"), da ich den Einfluss der einzelnen Parameter nicht kenne, da sich diese zum Teil gegenseitig sehr stark beeinflussen.
Gleichzeitig bin ich mir nicht sicher, ob ich nicht durch meine gewählten Grenzen das Ergebnis schon viel zu stark beeinflusse ...
Nun bin ich auf der Suche nach einem effizienten Optimierungsalgorithmus, da ich anscheinend mit lsqnonlin() und Multistart in Kombination nicht weiterkomme.
- Ich bin vorhin über patternsearch() bzw. ga() gestolpert, die beide sehr "brauchbar" klingen, allerdings bin ich förmlich erschlagen durch deren Einstellungsmöglichkeiten und bin mir dann auch nicht sicher, ob sich ga() für meine Problemstellung d.h. u.a. für Regressionsanalysen eignet. (Bei mir geht es im weiteren Sinne um nichts "Biologisches" sondern eher um die Nachrechnung eines Versuches aus dem Betonbau d.h. der Kalibrierung eines Relaxationsmodells ...).
Hätte evtl. jemand von euch ein paar Tips übrig, wie ich dem beschriebenen Problem "Herr" werden könnte?
was mir letztlich einen Fehler von "1e-6" eingebracht hat. ... nicht besonders gut leider.
Ich würde sagen, dass das ziemlich gut ist. Es entspricht nämlich den Standardtoleranzen. Falls du es genauer möchtest: hast du das denn beim Aufruf von lsqnonlin über die Optionen angegeben?
Ich würde sagen, dass das ziemlich gut ist. Es entspricht nämlich den Standardtoleranzen. Falls du es genauer möchtest: hast du das denn beim Aufruf von lsqnonlin über die Optionen angegeben?
Nein, daran habe ich nichts geändert. Da ich teilweise bereits Fehler von 1e-8 und kleiner erzielen konnte, dachte ich nicht daran, dass da eine Änderung notwendig wäre.
Ich habe über die letzten Tage nun meine Modellfunktion nochmals etwas überarbeitet, da sie sich nun - so glaube ich - leichter anpassen lässt. Zumindest gelingt mir das händisch nun recht gut über "trial and error".
Das Problem ist nun, dass lsqnonlin() sich nun nicht mehr vom Startpunkt (hier habe ich meine beste händisch gefundene Näherung angegeben) wegbewegt und nun
"Initialpoint is a local minimum. Optimization completed because the size of the gradient at the initial point is less than the default value of the function tolerance."
meldet.
Ich bin mir aber ziemlich sicher, dass man die Parameter noch besser bestimmen können muss, als ich es bisher händisch geschafft habe. Die Frage ist nur *wie* bzw. welche Parameterkombination innerhalb der von mir angegebenen Grenzen das "Ei des Kolumbus" ist.
Ich habe grundsätzlich zunächst mal MultiStart als Wrapper verwendet, allerdings hat das keinen Erfolg gebracht - auch bei 150+ Startpunkten nicht, wenn ich meinen "guten" Startpunkt als x0 angebe. Wenn ich einen "schlechten" Startpunkt wähle, dann tut sich mit MultiStart schon etwas, allerdings ist das Ergebnis dann auch relativ schlecht
.
Das Problem ist, dass meine Parameter zwar begrenzt sind, die Grenzen allerdings nichts über das Ergebnis einer beliebigen Kombination der Parameter aussagen. - So kann es z.B. sein, dass durch eine ungeschickte Parameterwahl - selbst wenn sie innerhalb der Grenzen liegen - physikalisch unsinnige Ergebnisse herauskommen, wie z.B. Wendepunkte in der gefitteten Funktion, die eigentlich nicht sein dürfen.
Generell sieht mein lsqnonlin-Aufruf (hier ohne Multistart) so aus:
Dabei enthält timevc die Zeiten (spaltenweise), die zur gemessenen Dehnung gehört, die in dhgvc (spaltenweise) enthalten sind. InitialGuess ist der Startvektor mit den Parametern, arr_lb die untere- und arr_ub die obere Grenze der Parameter.
Die Zielfunktion berechnet die Differenz zwischen Messkurven und jener Kurven, die meine DGL "ausspuckt":
Code:
function[ff_err] = objfc_lsq(PAR, arr_tmeas, arr_dhgmeas, dbl_load) for ii=1:size(arr_tmeas,2) try % Berechnen der Dehnung ueber DGL und zu bestimmenden Parametern
arr_dhgcalc = calcdhg( arr_tmeas, dbl_load, PAR(1), PAR(2), ...)
ff_err(:,ii) = (arr_dhgmeas(:,ii)-arr_dhgcalc(:,ii));
catch % Sollte DGL fuer gewaehlte Params nicht loesbar sein - NaN zurueckgeben
ff_err(:,ii) = nan(size(arr_dhgcalc,1),1);
end end
ff_err = reshape(ff_err, [], 1);
end
Da die Globale Optimierung via lsqnonlin anscheinend nicht so wie gedacht zum Ziel führt, habe ich nun versucht, mein Problem via "patternsearch()" anzugehen. - Allerdings scheitere ich hier daran, dass ich es nicht schaffe, Grenzen für meine Parameter zu übergeben. Dabei ist nun das Problem, dass meine DGL nicht definiert ist, wenn manche Parameter = 0 sind - patternsearch() weiß nichts davon und setzt munter "0" ein und dann meckert ode23s: "Warning: Matrix is singular, close to singular or badly scaled. Results may be inaccurate. RCOND = NaN."
entsprechend der Forderung, dass die Zielfunktion einen Skalaren Wert zurückgibt, sieht diese so aus:
Code:
function[ff_err] = objfc_lsq_sqe(PAR, arr_tmeas, arr_dhgmeas, dbl_load) for ii=1:size(arr_tmeas,2) try % Berechnen der Dehnung ueber DGL und zu bestimmenden Parametern
arr_dhgcalc = calcdhg( arr_tmeas, dbl_load, PAR(1), PAR(2), ...)
ff_err(:,ii) = (arr_dhgmeas(:,ii)-arr_dhgcalc(:,ii));
catch % Sollte DGL fuer gewaehlte Params nicht loesbar sein - NaN zurueckgeben
ff_err(:,ii) = nan(size(arr_dhgcalc,1),1);
end end
ff_err = sumsqr(ff_err);
end
... leider funktioniert das nicht wie gedacht, eben auch aus der Tatsache der nicht begrenzten Parameter.
Kann man diese Grenzen bei patternsearch() auch irgendwie mitangeben? (Mit den weiteren Parametern neben x0 der Hilfe bin ich leider nicht weitergekommen bzw. habe diese nicht so wirklich verstanden ...).
Oder gibt es sonstige Möglichkeiten, wie ich zu einem besseren Fit gelange? (Leider sind meine Parameter relativ "breit gestreut" verteilt; d.h. manche bewegen sich zwischen 0 und -3, andere zwischen 1 und 40000 ... - ist hier eine "manuelle Skalierung" zielführend oder vernünftig?)
Ah, eines noch, den Fehler betreffend. - Möglicherweise ist es auch problematisch für meine Fits bzw. lsqnonlin(), dass meine Zielfunktion generell recht kleine Ergebnisse liefert - diese liegen alle im Bereich von "1e-5" ... vielleicht müsste ich allein aus diesem Grund schon die lsqnonlin-Toleranz höher schrauben ... oder meine Zielwerte bzw. die Rückgabewerte der Funktion zunächst skalieren, z.B. gleich mal *1e8 oder so?
ich habe mal bei lsqnonlin 'TolFun' bzw. 'TolX' via optimoptions auf 1e-12 gesetzt. Jetzt hat sich zumindest (zunächst mal noch als Test ohne MultiStart) ein bisschen was in den Werten getan und diese sind von meinem Startvektor ein bisschen weggewandert. Allerdings in sehr sehr sehr geringen schritten. (Und bei manchen Parametern wären größere Schritte angebracht, bei anderen wiederum weniger ... - allerdings habe ich bedenken, mit 'TypicalX' einzugreifen, um nicht dadurch *das* Minimum zu "überspringen", da ich die Schrittweite zu groß vorgebe ... - Oder ist das nur ein Richtwert für Matlab, und es "greift" dennoch selbst ein?)
Danke für den Hinweis bei Patternsearch() - ich rufe dieses nun so auf:
... nun rechnet es seit ca. 15 Minuten. Ich bin gespannt, ob es mir eine "brauchbare" Lösung liefert. Anscheinend scheint es aber viel langsamer zu konvergieren als lsqnonlin(). Das liegt aber wahrscheinlich daran, dass es kein gradientenbasierter Solver ist, sondern wirklich "direkt" das Gebiet abgeschritten wird. ... In wieweit ich durch meine "[]" das Ergebnis beeinflusse hm, kann ich leider nicht sagen, da ich den Hintergrund von A*x<=b bzw. Aeq*x=beq nicht so ganz verstehe.
Jetzt hat sich zumindest (zunächst mal noch als Test ohne MultiStart) ein bisschen was in den Werten getan und diese sind von meinem Startvektor ein bisschen weggewandert
.
Es sollte sich so viel getan haben wie nötig. Hast du die Toleranzen am Ende mal überprüft?
Zitat:
(Und bei manchen Parametern wären größere Schritte angebracht, bei anderen wiederum weniger ... - allerdings habe ich bedenken, mit 'TypicalX' einzugreifen, um nicht dadurch *das* Minimum zu "überspringen", da ich die Schrittweite zu groß vorgebe ... - Oder ist das nur ein Richtwert für Matlab, und es "greift" dennoch selbst ein?)
Aus der Doku: The solver uses TypicalX for scaling finite differences for gradient estimation.
Es kann gut sein, dass die Konvergenz so schneller erfolgt. Kommt auf den Versuch an.
Zitat:
Das liegt aber wahrscheinlich daran, dass es kein gradientenbasierter Solver ist, sondern wirklich "direkt" das Gebiet abgeschritten wird.
Genau. Ich halte auch den MultiStart-Ansatz für sinnvoller.
Zitat:
In wieweit ich durch meine "[]" das Ergebnis beeinflusse hm
Gar nicht.
Zitat:
da ich den Hintergrund von A*x<=b bzw. Aeq*x=beq nicht so ganz verstehe
Damit kannst du lineare Beschränkungen für deine Parameter definieren.
Genau. Ich halte auch den MultiStart-Ansatz für sinnvoller.
Ich ansich auch. Aber irgendwie klappt das trotz beider Toleranzen auf "1e-20" nicht so wirklich. Ich habe mal ein Bild angefügt (krtb.png).
Die schwarzen Linien sind die "Zielkurven". Die blau punktierte Linie zeigt meinen InitialGuess und die rote Linie gibt die "optimierten" Werte nach 2x MultiStart wieder.
(Das ist im Prinzip das, was nach einem einzigen Lsqnonlin herauskommen würde, obwohl ich auch TypicalX gesetzt habe.) - Daneben sieht man den Ergebnisvektor der Parameter. Meine Startvektor war:
Irgendwie würde ich mir wünschen, dass da die einzelnen Parameter noch mehr variiert/kombiniert werden. Ansonsten habe ich teilweise das Gefühl, als wäre ich händisch schneller ... Ich weiß nicht, wie man das ansonsten hinbringen könnte, "gute" Parameter zu finden, die alle Kurven möglichst gut beschreiben bzw. glaube ich, dass da noch mehr möglich sein muss, als es bisher der Fall ist - wenn ich z.T. händisch "besser" hinkomme ...
Leider gehen mir die Ideen aus ... oder ich mache irgendetwas komplett falsch, dass auch Matlab nicht weiterkommt. Ich weiß nicht ... - 10000 Startpunkte in Multistart kann ja auch nicht so ganz der richtige Weg sein denke ich mir.
Wie wählst du denn händisch die Parameter?
Wenn du das als Startwerte angibst, solltest du noch bessere Ergebnisse bekommen.
Naja, also für das obige Beispiel (im angefügten Bild) habe ich herumprobiert und mir Angeguckt, wie sich der Einfluss einer Änderung bzw. der Kombination mit anderen davon auf das Ergebnis auswirken. Als ich dann eine Kombination gefunden habe, mit der ich recht "nah" an allen drei Ergebniskurven gelegen bin habe ich das als Startwert für lsqnonlin() hergenommen bzw. für Multistart.
Dabei habe ich gehofft, dass nun evtl auch andere, möglicherweise "bessere" Parameter gefunden werden, bei denen z.B. die letzten beiden Kurven besser getroffen werden usw. ... - das ist aber anscheinend nicht der Fall.
Bevor ich "resigniere" und sagen muss: "mein Modell kann das halt nicht besser", wollte ich noch alle Optimierungsmöglichkeiten ausschöpfen um vielleicht dennoch noch irgendwie auf eine bessere Näherung zu stoßen ...
Ich weiß nicht, ist es z.B. möglich weitere "Nebenbedingungen" anzugeben, sodass z.B. im Ursprung der jeweiligen Kurven eine vertikale Tangente anzustreben ist bzw. Kombinationen von Parametern vermieden werden sollen, die zu Wendepunkten in den Ergebniskurven führen könnten? (Auch das kann passieren wenn z.B. die Parameter ungeschickt gewählt werden. Für lsqnonlin sieht dann das Ergebnis teilweise besser aus, weil sich die Ergebniskurve quer durch die Messkurven "schlängelt" und im Mittel eine recht geringe Fehlerquadratsumme entsteht. Das lässt sich aber durch das Setzen der genannten Grenzen nicht vermeiden, da die Grenzen zumindest vom phyiskalischen Standpunkt her sinnvoll gewählt sind. ... - Evtl. kann man gar keine Grenzen setzen und die Optimierung nur über die Nebenbedingungen "[möglichst] Vertikale Tangente im Ursprung"/kein Wendepunkt laufen lassen. Aber hier habe ich keine Ahnung, wie man das schaffen kann bzw. ob das möglich ist ...).
Und irgendwie habe ich auch Zweifel daran, ob meine Funktionsparameter (oder die Messwerte/Zielfunktion ansich, da sich das alles in einem recht geringen Zahlenbereich abspielt) nicht noch "skaliert" gehören, da sie schon recht breit verteilt sind, wobei eine kleine Änderung der "großen Parameter" i.d.R. wenig Einfluss hat, im Vergleich zu kleinen Änderungen der "kleinen Parameter".
Liebe Grüße,
pjheinrich
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