| mpfit debugging [message #90140] |
Fri, 30 January 2015 16:34  |
Mats Löfdahl
Messages: 263
Registered: January 2012
|
Senior Member |
|
|
I'm debugging a program that does a sequence of mpfit calls, where I fix different parameters in different calls. This is mpfit.pro directly, not mpfitfun etc., so the MYFUNCT function returns the difference between measured samples and model data. I also limit some of the parameters.
By making various errors, so far I've noticed that
* if I forget to make the model data real (there are FFTs involved) the report after each iteration has two lines that begin with "Iter", one with the current iteration number followed by "chi-square" and "dof" and one with some other number that does not change from iteration to iteration and is not followed by chi-square" and "dof". (Something like that, it's been a couple of weeks since I fixed this bug.)
* if my initial parameter array has values that are outside the specified limits, mpfit just returns the initial parameters without writing an "Iter" report and without even calling MYFUNCT once.
But what could cause the following behavior?
It writes the initial "Iter 1" report, calls MYFUNCT a bunch of times to calculate the derivatives, then writes an identical "Iter 1" report, and returns the initial parameters as the answer.
I should add that these initial parameters do not happen to be the optimum. I tried again with slightly different values for some of the non-fixed initial parameters, a different chi-square was printed in the "iter 1" report but the behavior was the same.
Does this ring a bell with anyone? What kind of bug should I look for?
/Mats
|
|
|
|
| Re: mpfit debugging [message #90142 is a reply to message #90140] |
Sat, 31 January 2015 05:26  |
Craig Markwardt
Messages: 1869
Registered: November 1996
|
Senior Member |
|
|
On Friday, January 30, 2015 at 7:34:15 PM UTC-5, Mats Löfdahl wrote:
> I'm debugging a program that does a sequence of mpfit calls, where I fix different parameters in different calls. This is mpfit.pro directly, not mpfitfun etc., so the MYFUNCT function returns the difference between measured samples and model data. I also limit some of the parameters.
>
> By making various errors, so far I've noticed that
>
> * if I forget to make the model data real (there are FFTs involved) the report after each iteration has two lines that begin with "Iter", one with the current iteration number followed by "chi-square" and "dof" and one with some other number that does not change from iteration to iteration and is not followed by chi-square" and "dof". (Something like that, it's been a couple of weeks since I fixed this bug.)
>
> * if my initial parameter array has values that are outside the specified limits, mpfit just returns the initial parameters without writing an "Iter" report and without even calling MYFUNCT once.
>
> But what could cause the following behavior?
>
> It writes the initial "Iter 1" report, calls MYFUNCT a bunch of times to calculate the derivatives, then writes an identical "Iter 1" report, and returns the initial parameters as the answer.
>
> I should add that these initial parameters do not happen to be the optimum. I tried again with slightly different values for some of the non-fixed initial parameters, a different chi-square was printed in the "iter 1" report but the behavior was the same.
>
> Does this ring a bell with anyone? What kind of bug should I look for?
>
> /Mats
You really need to be checking the STATUS keyword and the ERRMSG keyword upon return because they will tell you a lot more about what caused MPFIT to complete.
1. Forgetting to make the data real. MPFIT doesn't handle complex data. Well, it does something with it, but surely not anything correct. So you are probably seeing the real and imaginary components of the sum of the squared residuals. Don't do that.
2. Parameters outside the bounds. Yes, this is an error, and will be flagged as such, if you check STATUS and ERRMSG.
3. Calls your function several times and then returns. Usually indicates that MPFIT things your function has already converged to a solution. But check STATUS and ERRMSG.
Best luck!
Craig
|
|
|
|
| Re: mpfit debugging [message #90143 is a reply to message #90142] |
Sun, 01 February 2015 10:29 |
Mats Löfdahl
Messages: 263
Registered: January 2012
|
Senior Member |
|
|
Den lördag 31 januari 2015 kl. 14:26:48 UTC+1 skrev Craig Markwardt:
> On Friday, January 30, 2015 at 7:34:15 PM UTC-5, Mats Löfdahl wrote:
>> I'm debugging a program that does a sequence of mpfit calls, where I fix different parameters in different calls. This is mpfit.pro directly, not mpfitfun etc., so the MYFUNCT function returns the difference between measured samples and model data. I also limit some of the parameters.
>>
>> By making various errors, so far I've noticed that
>>
>> * if I forget to make the model data real (there are FFTs involved) the report after each iteration has two lines that begin with "Iter", one with the current iteration number followed by "chi-square" and "dof" and one with some other number that does not change from iteration to iteration and is not followed by chi-square" and "dof". (Something like that, it's been a couple of weeks since I fixed this bug.)
>>
>> * if my initial parameter array has values that are outside the specified limits, mpfit just returns the initial parameters without writing an "Iter" report and without even calling MYFUNCT once.
>>
>> But what could cause the following behavior?
>>
>> It writes the initial "Iter 1" report, calls MYFUNCT a bunch of times to calculate the derivatives, then writes an identical "Iter 1" report, and returns the initial parameters as the answer.
>>
>> I should add that these initial parameters do not happen to be the optimum. I tried again with slightly different values for some of the non-fixed initial parameters, a different chi-square was printed in the "iter 1" report but the behavior was the same.
>>
>> Does this ring a bell with anyone? What kind of bug should I look for?
>>
>> /Mats
>
> You really need to be checking the STATUS keyword and the ERRMSG keyword upon return because they will tell you a lot more about what caused MPFIT to complete.
>
> 1. Forgetting to make the data real. MPFIT doesn't handle complex data. Well, it does something with it, but surely not anything correct. So you are probably seeing the real and imaginary components of the sum of the squared residuals. Don't do that.
Yeah, figured that one out... :)
> 2. Parameters outside the bounds. Yes, this is an error, and will be flagged as such, if you check STATUS and ERRMSG.
>
> 3. Calls your function several times and then returns. Usually indicates that MPFIT things your function has already converged to a solution. But check STATUS and ERRMSG.
Right, the status keyword. Never got into the habit of including that. Thanks for reminding me. Indeed it was XTOL that was too large (status=2).
Must be a weird looking target function that is so flat around two more or less randomly selected starting points. So the first few iterations reduced chi2 by really small amounts, then got going for real.
Thanks a lot!
/Mats
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
