Pdepe for heat conduction and in thermal parameters optimization. Non smooth cost function.

5 views (last 30 days)
I am having a problem with use of Matlab´s pdepe solver that I am not sure of origin. I would like to ask if anybody encountered anything similar or how to possibly explain the features I am seeing.
I have set up a heat conduction model for freezing ground. At this stage, I am doing an optimization of ground thermal properties using measured and simulated ground temperature data. To check the setup of my model, at first, I am using synthetic "measurements" without noise to fit my simulations to. I generate a temperature field using certain ground thermal parameters (so called "true" parameter values). Then I change the value of one of the parameters ("modified" param. values) and I am trying to retrieve its "true" value by minimizing the residual between the temperature field calculated with true and modified parameter set. As said, I do not add any noise so far to the temperature field simulated with the modified target parameter. Also, for now, I am only changing and optimizing for one parameter at once.
My problem is that when I plot the objective function for this optimization problem - the sum of squares between the temperature field generated with "true" and "modified" parameter set - it is not smoothly decreasing, as I would expect - see the picture below. The x-axis shows "modified" values of parameter CRock used for computation of "modified" temperature field that was compared to the "true" temperature field at each step where there is the *.
This objective function represents a problem for consequent optimization using the lsqnonlin solver, which gets stuck in all those local minima that are visible on the cost function plot. Therefore I would like to get rid of the "spikes".
So far, I haven´t found a good explanation why these jags in the cost function appear and a likely explanation of this feature is my actual question. I would expect the cost function to be smoothly decreasing as the target parameter approaches its "true" value. [here, the "true" CRock = 2e6 J/m3/K, the cost function being evaluated on the range of "modified" CRock values 1.4e6:2000:1.42e6] I am guessing that it might be related to the number of iterations taken by the pdepe solver when searching for the solution to the heat equation. I am guessing that at the points where the "spikes" appear, the pdepe solver might be taking an extra iteration comparing to the point before. I can eliminate some of the spikes by adjusting the RelTol and AbsTol of the pdepe solver far below their default values. However, this very much increases the computation time which is not acceptable for my application where the heat model needs to run many times during the optimization.
So far, I managed to overcome the actual optimization problem by using a different optimization algorithm - fminsearch instead of lsqnonlin. However, fminsearch appears not to be recommended choice for problems that are sums of squares. It also takes more iterations than lsqnonlin to converge. The lsqnonlin should be designed for my kind of problem. However, so far, I can´t apply as due to the shape of my cost function, it does not move from provided initial starting point.
Any hints will be greatly appreciated.

Answers (1)

Alan Weiss
Alan Weiss on 25 Oct 2013
Edited: Alan Weiss on 25 Oct 2013
Sonia, did you try setting DiffMinChange and DiffMaxChange to 1e3 and 1e4 respectively? Your plot makes it appear as if you might need to take very large finite difference steps.
Alan Weiss
MATLAB mathematical toolbox documentation
  2 Comments
Sonia
Sonia on 28 Oct 2013
Alan, thank you for your suggestion.
The DiffMin/MaxChange settings only apply to lsqnonlin solver, not to the pdepe solver, right? I have tried to pass the options you suggested to lsqnonlin. In this case, however, the function stops immediately without iterating with message: "Optimization completed because the size of the gradient at the initial point is less than the selected value of the function tolerance." The TolFun is set to 1e-3 in this case. If I set it to 1e-4, the optimization continues for 2 iterations until "lsqnonlin stopped because the size of the current step is less than the selected value of the step size tolerance". However I don´t want to set my TolX smaller because the actual steps are already too small anyway.
With large TolX/TolFun setting, the solver stops immediately saying it reached the tolerance. With small TolX/TolFun settings, the solver continues to iterate until it eventually reaches one of the tolerances. During the whole iterating, the fun(x) is not decreasing at all. However the First-order optimality is very small in the order of 0.000747 despite being far from optimum. The steps are becoming smaller and smaller, despite the DiffMinChange setting. The steps are typically similar to this: start=1.4e6 -> 1401000 -> 1400010 -> 1401010 -> 1400030 -> 1401030 -> 1400015 -> 1401015 -> 1400011.25 -> 1401011.25 etc. while it should be progressing towards the value 2e6, rather then keep staying close to 1.4e6.
I have the same problem with other parameters as well and those other parameters are in the order of 1e-1 to 1e1.
I would just like to make sure that, contrary to my previous question related to the problem with running lsqnonlin on my problem, this question was more oriented towards the problem with the pdepe - I would not expect the "spiky" cost function plots that I am seeing and I was curious what the explanation could be? As I said, most of the spikes are smoothed out when RelTol and AbsTol in pdepe options are reduced but this is not a good way for me as the computation time for forward calculations is largely increased.
Sonia
Sonia on 28 Oct 2013
Of course, a way of making the lsqnonlin work on my problem would be just as good. I was just interested in understanding the issue with pdepe calculation. But the ultimate goal is to use the lsqnonlin (or other suitable solver) for finding the optimum of the given problem.

Sign in to comment.

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!