Lev-Mar template missing

[johnsold]

I am trying to fit A*sin(w*t+phi) to some noisy data (amplitude, frequency, and phase are all to be detrmined from the matched sine). When I looked at the Lev-Mar fitting VIs I could not locate the template for the LM model function and gradient VI template mentioned in the Help file. labview\vi.lib\gmath\opti.llb\numerical is empty. (Help says this template should be there). The figure in the help file shows a cluster called Output Control as an input to the VI, but does not specify the elements of the control. I also could not find a way to put the formula into the String Formula version. Is there a listing of the available functions and syntax? The help did not seem to lead me to it.

LV8.0.1 on Mac OS X

Maybe it is just too late on Friday afternoon.

Lynn

[altenbach]

No, I have the same problem.

I would just Just open one of the fitting examples, then duplicate the model VI.

Also have a look at "extract single tone information", it might just do what you need. 😄

Message Edited by altenbach on 06-16-2006 08:27 PM

[johnsold]

Christian,

Thanks. I found an example and modified it for my function and everything works.

For fitting to sine I find that it is very sensitive to initial guesses, in ways which seem counterintuitive. But then what is intuitve about curve fitting? For example a small change in the initial frequency (with the amplitude and phase exactly as generated) can change the fit from almost perfect to a straight line sloping downward (actually a segment of a very low frequency). Is there any reference I can check to give guidance on how to set this up? Does the order of the parameters to be fitted make a difference to the quality of the fit? Does making the first parameter frequency rather than amplitude make a difference? Any other suggestions?

Fitting to a segment of a sine wave that was about 120 degrees long seems to work better than fitting to 4-5 cycles. Is this to be expected?

I have not yet tried it with noisy data.

Extract Single Tone uses FFT internally and our data sets are 1.5 to 3.5 cycles long where FFT does not work as well as I would like.

Lynn

[sarahk]

Hi, Lynnn.

It sounds like your questions lie with the algorithm itself rather than LabVIEW -- I did a quick Google search and came up with this, although a more careful search might yield something more helpful.

Sorry I can't be more help! Good luck.

[altenbach]

Lynn,

I'm surprised that the fitting is not very stable for you. Could it be that you are actually fitting an alias frequency of the real data? (This could really kill the partial derivatives).

I'd be happy to look at your code. 🙂

[johnsold]

Sarah, Christian,

I had looked at that link and several others. I was hoping to find some reference where someone had made some practical suggestions reagrding optimizing the initial guesses, or at least some clues as to how to go about it.

My data has a frequency range of about 2.5:1 so I was hoping I could just set the initial guess at the middle of the range. In my testing an initial guess 20% above or below the actual frequency resultis in erroneous values about 80-90% of runs with noise at 10% of signal amplitude which is better than the real data. With initial amplitude and phase equal to the data parameters and initial frequency guess at 1.2 times the actual I recorded two runs with the fit frequency at 99.9%. Eight others produced: 160%, 180%, 210%, 160%, 160%, 130%, 60%, and 160%. With the initial frequency at 80%, the results were somewhat worse.

My suspicion is that because the partial derivatives of the model equation are also sines and cosines, the algorithm tends to find some kind of local minimum and converges to that even though it is a really poor fit.

Here is my modified Lev-mar VI and the simple sine model VI (LV8). The default values are fairly typical of the data sets we will be getting.

Thanks for the help.

Lynn

[medvall]

Hi Lynn et al,

Noisy fitting problems are "global" in their characteristics, i.e. a pure local solver cannot find a global solution with 100 % certainty.

I setup the problem with glbDirect (a global solver that only takes simple bounds) in the TOMVIEW Base Module and it works fine as expected.

1. The tighter the bounds are set, the faster you will get a good solution. A global solver will search the entire search space and focus more and more on "good areas".

2. A local solver could be used afterwards to fine-tune the solution.

3. When not getting suitable solutions the number of function evaluation by glbDirect should be increased. It might be good to run a few hundred simulations to make sure it's always returning a nice solution.

Best wishes, Marcus