fminunc gets first-order optimality of zero on iteration 0, does not find optimum
5 vues (au cours des 30 derniers jours)
Afficher commentaires plus anciens
Hi everyone,
I am trying to optimize a parameter of a Finite Element model by using fminunc. However, the optimization algorithm finishes on iteration 0, with a first-order optimality measure of 0, and therefore does not find the optimum value for the parameter:
![](https://www.mathworks.com/matlabcentral/answers/uploaded_files/344596/image.png)
I have run my Finite element model with a few values for the parameter that I want to optimize:
![](https://www.mathworks.com/matlabcentral/answers/uploaded_files/344599/image.png)
As it looks to me, there is a clear global minimum, but for some reason the fminunc doesn't find it now. Does anyone know how to fix this problem?
Thanks in advance, Koen
0 commentaires
Réponses (3)
John D'Errico
le 11 Août 2020
Modifié(e) : John D'Errico
le 11 Août 2020
First, this appears to be a ONE parameter optimization. Do not use fminunc for that. Instead, us fminbnd. It will be more robust. It may even be more efficient.
Second almost always when someone says what you have, this means the function is coded incorrectly. Before performing an optiimization, test to see if the objective function changes for different inputs. The response you got is the response you would see if a function is just a constant.
For example, see what happens here:
>> testfun = @(x) 1;
>> testfun(1)
ans =
1
>> testfun(pi)
ans =
1
Anything I send into testfun, I get 1 out.
Now, what happens when I try fminunc here?
>> fminunc(testfun,pi)
Initial point is a local minimum.
Optimization completed because the size of the gradient at the initial point
is less than the value of the optimality tolerance.
<stopping criteria details>
ans =
3.1416
I get exactly the same result as you got.
So first, verify that if you send different input parametrs into your function, that you get something differnt.
Next, verify that your function is differentiable. fminunc REQUIRES this. If you do something inside that rounds the inputs or the output, then fminunc cannot be used. Again, an example should suffice:
>> testfun = @(x) round(x);
>> fminunc(testfun,1.1)
Initial point is a local minimum.
Optimization completed because the size of the gradient at the initial point
is less than the value of the optimality tolerance.
<stopping criteria details>
ans =
1.1
So for ANY x in the vicinty of an integer, you get the same integer out. NO change. As far as fminunc is concerrned, this is a constant function, and it will terminate immediately.
testfun(.5:.1:1.4)
ans =
1 1 1 1 1 1 1 1 1 1
Why try to optimize something that does not change?
The odds are therefore good, that if you think your function should produce some non-constant response, then you have a bug in your code. We cannot diagnose that without seeing the code of course, and my MATLAB crystal ball is always on the fritz. :)
5 commentaires
Alan Weiss
le 14 Août 2020
I believe that you need to take huge finite difference steps because your problem has poor scaling. I think that internally your objective function should multiply the parameter YM by 1e4 AND you should set the FiniteDifferenceStepSize option to 1e-2 or even 1e-1. Or perhaps internally take exp(YM) as the parameter; I think that is a better idea, now that I think of it. And still take a reasonably large step size, maybe 1e-3 even with an exponential scaling.
Alan Weiss
MATLAB mathematical toolbox documentation
Bruno Luong
le 14 Août 2020
Modifié(e) : Bruno Luong
le 14 Août 2020
If your gradient is 0, then your FEM returns the exact same result for two different values of YM.
This can be created by many things, such as truncation of the interface between MATLAB and your FEM SW, some thresholing in the equation you are trying to solve, mesh generator, etc... No one can tell since you did not disclose to us the details of FEM part.
3 commentaires
Bruno Luong
le 14 Août 2020
Modifié(e) : Bruno Luong
le 14 Août 2020
Because when you plot you "control" the step.
FMINUNC uses a step-size that might or might not be larger than the threshold to evaluate the gradient, and it requires the function to be differentiable. The FEM obviously is piecewise constant, meaning not differentiable wrt YM parameter.
FMINSEARH is gradient-less method a,nd 1D. It's very poor optimization method IMO.
"the problem is not inside my FEM solver". Let me rephrase itmore accurately: The problem is you select a wrong optimization method because the FEM is not differentiable wrt YM parameter so it does not meet the requirement of "smooth" (C1) objective function.
Bruno Luong
le 14 Août 2020
Again the step you tried might not be the step FMINUNC selects. It has a bunch of decision tree behind FMINUNC. I don't know why the FEM returns the same value for 2 different YM, but obviously that happens. You might be able to track the step FMINUNC used by adding some instrumental code in your objective function.
Again I don't know how your FEM works, I can't recommend you the method. Your function looks also having a very narrows valley where each side ithat look like a concave shape. This also not something gradient method like.
But again the problem seems that the FEM have some thresholding calculation on YM and it makes your objective function non-smooth thus you can't use any gradient method.
I start to repeat myself a lot.
0 commentaires
Voir également
Catégories
En savoir plus sur Solver Outputs and Iterative Display dans Help Center et File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!