ich habe gerade ein kleines Problem. Eine Differentialgleichung (linear inhomogen, nicht konstante Koeffizienten; Lösungsalgorithmus ist ode23s()) liefert mir für eine Versuchsnachrechnung eine Ergebniskurve für eine bestimmte Einwirkung. Die Ergebniskurve soll nun optimal eine "Sollkurve" treffen. Hierfür ist es notwendig einige der Eingangsparameter der DGL optimal zu wählen.
Gibt es hierfür in Matlab eine (einfache?) Möglichkeit auf diese optimalen Parameter zu kommen? Ich dachte an eine Art Least-Squares-Fit oder eines der Trust-Region-Verfahren aus der Optimization-Toolbox ... allerdings: welches Verfahren/welche Funktion ist hierfür eine Möglichkeit?
Könnte mir hierbei jemand weiterhelfen, z.B. mit einem "Dummy-Beispiel" das eine derartige Optimierung zeigt oder hat jemand einen Link-Tipp parat? In der Matlab-Dokumentation bin ich irgendwie "versumpft" bzw. nicht noch wirklich an das Ziel gekommen ...
Ich hoffe, ich habe mich einigermaßen verständlich ausgedrückt.
das hat mir schon sehr viel geholfen. - Ich poste später mein Beispiel, für alle anderen, die das noch benötigen.
Bei einer Kleinigkeit (?) stehe ich allerdings noch an: wenn ich einen Einzelnen Fit machen möchte, der sich aus Messdaten einer Zeitreihe (1:0.01:24 Tage) zusammensetzt, klappt alles wunderbar.
Allerdings muss ich nun mehrere Zeitreihen bzw. entsprechend mehrere Messdaten berücksichtigen. D.h. ich habe nicht nur Messwerte von der Zeitreihe 1:0.01:24 Tage, sondern auch welche ab 2.5:0.01:24 Tage bzw. 3.0:0.01:24 Tage.
Zunächst dachte ich daran, alle Zeitreihen und Messergebnisse in einen Vektor zusammenzukoperien (d.h. Zeilenweise anhängen), aber hier schimpft mich nun lsqnonlin, dass das so nicht möglich ist, da für eine Optimierung kontinuierlich steigende oder fallende Zeitreihen erforderlich sind.
Hat jemand von euch eine Idee, wie man dieses Problem lösen könnte?
Vielen lieben Dank im Voraus,
johepet
johepet
Gast
Beiträge: ---
Anmeldedatum: ---
Wohnort: ---
Version: ---
Verfasst am: 25.06.2017, 18:44
Titel:
... Nachtrag: Ich habe mich etwas ungeschickt ausgedrückt. - Also ich habe wie gesagt mehrere Messkurven, und möchte die freien Parameter meiner Zielfunktion so wählen, dass diese jede der Messkurven optimal treffen.
Die Messergebnisse sind nämlich stark vom Belastungszeitpunkt abhängig, d.h. von jenem Zeitpunkt, ab dem ich jeweils unterschiedliche Messkurven/Ergebnisse zur Verfügung habe. Ich habe z.B. Messdaten von t1 = 1d ... 24d; t2 = 2d ... 24d; t3 = 3d ... 24d etc. - Die freien Parameter Sollen nun so bestimmt werden, dass meine Funktion für jeden Belastungszeitpunkt das Optimale Ergebnis liefern kann.
Zunächst dachte ich daran, alle Zeitreihen und Messergebnisse in einen Vektor zusammenzukoperien (d.h. Zeilenweise anhängen), aber hier schimpft mich nun lsqnonlin, dass das so nicht möglich ist, da für eine Optimierung kontinuierlich steigende oder fallende Zeitreihen erforderlich sind.
Poste doch bitte deinen genauen Versuch. Wenn das Zusammenkopieren in der richtigen Reihenfolge erfolgt, sollte das ja an sich gehen.
Grüße,
Harald
johepet
Gast
Beiträge: ---
Anmeldedatum: ---
Wohnort: ---
Version: ---
Verfasst am: 25.06.2017, 23:46
Titel:
Hallo,
Zitat:
Poste doch bitte deinen genauen Versuch. Wenn das Zusammenkopieren in der richtigen Reihenfolge erfolgt, sollte das ja an sich gehen.
Ich habe das nun noch etwas anders gelöst, mein Versuch bzw. nun eingesetztes Skript sieht so aus:
Soweit scheint das eigentlich zu klappen, zumindest gibt es keine "Fehlermeldung", vielmehr meldet Matlab:
"Local minimum found.
Optimization completed because the size of the gradient is less than
the default value of the function tolerance.
<stopping criteria details>"
... die Ergebnisse selbst sehen für mich zunächst aber einmal plausibel aus.
Allerdings bin ich mir in meinem obigen Beispiel nicht so sicher, ob ich das richtig mache, so wie ich den jeweiligen Fehler bestimme und diesen dann an lsqnonlin() gebe. Ich habe das aus einem Beispiel, das ich via Google gefunden hatte abgekupfert - sollten bei error(:,ii) = ... nicht die Fehlerquadrat[summ]e[n] stehen? Oder bestimmt die dann lsqnonlin() für die Optimierung aus meinem "einfachen" Fehler?
zumindest gibt es keine "Fehlermeldung", vielmehr meldet Matlab:
"Local minimum found.
... und das ist eine gute Nachricht: es ist nämlich das beste, was ein gradientenbasierter Löser liefern kann.
Zitat:
sollten bei error(:,ii) = ... nicht die Fehlerquadrat[summ]e[n] stehen? Oder bestimmt die dann lsqnonlin() für die Optimierung aus meinem "einfachen" Fehler?
Was ich mich eher frage ist, ob error bei dir am Ende nicht eine Matrix wird. Falls ja, würde ich das (sicherheitshalber) mit
reshape
in einen Vektor umwandeln.
Grüße,
Harald
johepet
Gast
Beiträge: ---
Anmeldedatum: ---
Wohnort: ---
Version: ---
Verfasst am: 26.06.2017, 10:59
Titel:
Hallo,
Zitat:
Das macht lsqnonlin automatisch.
Was ich mich eher frage ist, ob error bei dir am Ende nicht eine Matrix wird. Falls ja, würde ich das (sicherheitshalber) mit reshape in einen Vektor umwandeln.
Stimmt ... der wird zu einer Matrix. Ich habe nun nach der for-Schleife folgendes Stückchen ergänzt:
Soweit funktioniert das alles ganz fein! Vielen Dank für die Hilfe!
... eines vielleicht noch: Gibt es irgendwelche "Tricks", wie man die Startwerte für die Optimierung bestimmen könnte? Ich habe hier momentan Parameter der DGL verwendet, die ich in der Literatur gefunden habe. Allerdings sind die zum Teil recht "sensibel", sodass eine schlechte Wahl nicht unbedingt zur Lösbarkeit der DGL führt bzw. so dann die ganze Optimierung eigentlich fehlschlägt.
Da error auch ein Befehl ist (um Fehlermeldungen zu erzeugen), würde ich das als Variablenname vermeiden.
ahh, danke für den Hinweis. - In meinem Programm selbst heißt die Variable "diff"; ich dachte mir nur, als ich das Beispiel auf den obigen Code reduziert hatte, dass ichs für das bessere Verständnis in "error" umbenenne ... war wohl eher kontraproduktiv
Vielen Dank für den Hinweis, ich werde mich damit mal beschäftigten! ... Ich frage mich generell, wie das mit diesen Startwerten ist ... wenn ich diese unglücklich wähle, kann es sein, dass meine DGL dahinter "versagt", weil die einzelnen Parameter diese sehr stark beeinlussen; als Startwerte wähle ich deshalb ein "funktionierendes" Parameterset, das aber nicht unbedingt die besten Ergebnisse liefert, weswegen ich diesen Optimierungsalgorithmus benötige.
- Kann man mit dieser globalen Optimierung das Problem "umschiffen", dass ich durch die Vorgabe meiner Startwerte die Genauigkeit/Güte der Optimierung irgendwie "einschränke"? (Was macht lsqnonlin() z.B. wenn es "versehentlich" Parameter erwischt, für die die DGL unlösbar wäre? Bricht es dann ab, oder wählt es das Parmeterset anders? ... oder muss ich mich um diese Art der "Fehlervermeidung" selbst kümmern?)
In meinem Programm selbst heißt die Variable "diff";
diff ist eine Funktion für die Differenz aufeinanderfolgender Werte.
Variablen mit selbem Namen machen allerdings i.d.R. nur dann Probleme, wenn man auch die Funktion dieses Namens verwenden möchte.
Was die anderen Fragen angeht, ist das ein Stück weit auch ausprobieren. Ich würde innerhalb von eps_nonlin_calcmodel abfragen, ob die Simulation bis zum Ende durchläuft (letztes t mit Endzeitpunkt abgleichen). Falls in der Funktion Fehler auftreten, try-catch verwenden und im Fehlerfall hohe Differenzen zurückgeben.
Grüße,
Harald
johepet
Gast
Beiträge: ---
Anmeldedatum: ---
Wohnort: ---
Version: ---
Verfasst am: 27.06.2017, 17:36
Titel:
Hallo,
Zitat:
diff ist eine Funktion für die Differenz aufeinanderfolgender Werte.
Variablen mit selbem Namen machen allerdings i.d.R. nur dann Probleme, wenn man auch die Funktion dieses Namens verwenden möchte.
oh nein ... aber Danke für den Hinweis!
Zitat:
Was die anderen Fragen angeht, ist das ein Stück weit auch ausprobieren. Ich würde innerhalb von eps_nonlin_calcmodel abfragen, ob die Simulation bis zum Ende durchläuft (letztes t mit Endzeitpunkt abgleichen). Falls in der Funktion Fehler auftreten, try-catch verwenden und im Fehlerfall hohe Differenzen zurückgeben.
Diese Idee klingt sehr gut, ich werde sie die Tage ausprobieren bzw. implementieren - vorstellen kann ich mir das schon sehr gut.
Gibt es eigentlich eine Einschränkung bzgl. der Funktionen, die mittels lsqnonlin() gefittet werden können?
Also ich habe auch eine andere "Variante" der Zielfunktion, die ohne den ode23-Löser, der in meiner objective-Function das Ergebnis jeweils bereitstellt, auskommt und die DGL stückweise über ein Anfangswert-Problem nähert. ... d.h. dahinter verbergen sich recht viele Schleifen, usw. ... letztlich wird aber auch ein Array eps_calculated geliefert, das dann mit epsmeas verglichen wird und entsprechend den fehler liefert.
- Meiner Meinung nach sollte ich das auch problemlos verwenden können, oder gibt es hierbei bei lsqnonlin() eine Einschränkung o.ä.?
grundsätzlich keine Einschränkungen. Die Funktion sollte zumindest theoretisch differenzierbar sein. Das ist sie mit ODEs nicht, daher der Link in meinem ersten Beitrag, was dabei zu beachten ist.
Grüße,
Harald
johepet
Gast
Beiträge: ---
Anmeldedatum: ---
Wohnort: ---
Version: ---
Verfasst am: 28.06.2017, 17:33
Titel:
Hallo,
Zitat:
grundsätzlich keine Einschränkungen. Die Funktion sollte zumindest theoretisch differenzierbar sein. Das ist sie mit ODEs nicht, daher der Link in meinem ersten Beitrag, was dabei zu beachten ist.
Vielen Dank. Ich habe mein Skript nun - bzw. die Zielfunktion - nach den Infos in deinem ersten Beitrag adaptiert; dort wird u.a. geraten, dass im Falle eines "Versagens" der Zielfunktion, "NaN" zurückgeben soll:
"Suggestions for Evaluation Failures: Return NaN. If your simulation or ODE solver does not successfully evaluate an objective or nonlinear constraint function at a point x, have your function return NaN. Most Optimization Toolbox and Global Optimization Toolbox solvers have the robustness to attempt a different iterative step if they encounter a NaN value. "
Entsprechend sieht meine Zielfunktion nun aus:
Code:
% Funktion zur Ermittlung des Fehlers entsprechend der gewaehlten % Parameter gegenueber den Messwerten function[ fit_diff ] = objectiveFunction_lsq_2( PAR, tmeas, epsmeas )
% Startbedingungen fuer Berechnung eines jeden Lastfalls
fp1_s = 1;
fp2_eps = [0000];
fp3_kor = 1;
Nun habe ich als Anfangswerte absichtlich einen Parameter so gewählt, dass die Gleichung nicht lösbar ist, in der Hoffnung, dass lsqnonlin() nun den Rest "handled", und sich - auch wenn's länger dauern sollte - zum Zielwert nähert.
Leider meldet Matlab nun:
Code:
Warning: Failure at t=1.128319e+00. Unable to meet integration tolerances without reducing the stepsize below the
smallest value allowed (4.008594e-15) at time t.
> In ode23s at 402
In eps_nonlin_calcmodel at 47
In objectiveFunction_lsq_2 at 21
In @(PAR)objectiveFunction_lsq_2(PAR,timevec,epsvec)
In lsqnonlin at 197
In Optimierungsalgorithmus at 111 Error using snls (line48)
Objective functionis returning undefined values at initial point. lsqnonlin cannot continue.
Error in lsqncommon (line175) [xC,FVAL,LAMBDA,JACOB,EXITFLAG,OUTPUT,msgData]=...
Error in lsqnonlin(line235) [xCurrent,Resnorm,FVAL,EXITFLAG,OUTPUT,LAMBDA,JACOB] = ...
Error in Optimierungsalgorithmus (line111)
calcParam = lsqnonlin(@(PAR) objectiveFunction_lsq_2(PAR,timevec,epsvec), ...
meine Interpretation:
der Anfangsvektor muss einen endlichen Wert zurückgeben.
Die Aussage im Link wird sich darauf beziehen, dass die Solver damit klar kommen, wenn irgendwann im späteren Verlauf der Optimierung NaN zurückgegeben werden.
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