Concerns with Gaussian Peak Fit

[sandsbl]

I have been designing an automated data acquisition/analysis program for lab work that I am involved in. We are running with LV8 and as such, there was a variety of ways to do Gaussian fitting that is needed in our analysis. We have moved away from both of the native fitting routines in Labview for a couple reasons. I have some concerns about the Gaussian Peak Fit vi that comes with LV8. The most obvious is that the gaussian model it is fitting is not very useful in an experimental setting where a zero baseline is difficult to get. To use this fitting routine, the data needs to be offset corrected before performing the fit, and this adds unnecessary complexity considering the simplicity of adding an offset parameter to the model. Unfortunately, the details of this function are hidden in an external library function call. Another problem I noticed while using this is that the parameter mu shows up as the location of the actual peak value of the dataset rather than an interpolated value. For discretized data that can be noisy, the datapoint with the maximum depth is usually not the actual peak of the gaussian. This happens in each fitting mode when I supply X-Y without providing initial conditions. If I do provide initial conditions, the values I supply are not altered significantly if at all. Using the same inputs and initial conditions, the Nonlinear Curve Fit vi does a much better job at fitting both the offset and peak (mainly because it is a user-supplied model). However, I have found this VI to be considerably slower than Gaussian Peak Fit, and it seems to suffer from problems of its own (http://forums.ni.com/ni/board/message?board.id=170&message.id=184873). I have since went to using an external library I built containing a public domain Levenberg-Marquardt algorithm implemented in C. Direct substitution of this where both Gaussian Peak Fit and Nonlinear Curve Fit used to be does not show these problems while at the same time increasing performance. If anyone can show me the error in my ways, I would be greatly interested. Although I have found a way out, it would be considerably easier to use the native LabView functions for Gaussian fitting rather than integrating a separate C routine to do this, especially since LV8 went a long way in making this functionality more accessible. I have a link to debug code I am using for Nonlinear Curve Fit.vi in the link provided above. The same code can be used with Gaussian Peak Fit vi.

Brian.

[pawel]

Hi Brian

I do not have LV8 at hand, but did you try to compare the Gausian fit in LV8 to Matlab?

cheers

Pawel

[sandsbl]

No, unfortunately I've been separated from my Matlab. There doesn't seem to be that many posts on the LV8 Gaussian Fit. Has anyone had success or noticed similar issues with this particular subVI?

[DSPGuy]

Brian,

I agree the Gaussian Peak Fit.vi needs to have an offset.  Could you post your code that demonstrates the improper fit using Gaussian Peak Fit?

Regarding performance with Nonlinear Curve Fit.vi:
As you are aware, there are two interfaces or ways to specify your model.
The first is to use a formula string.  Any bugs aside (I think your bug was addressed in the other thread), a formula string is parsed, and the parse tree is stored for subsequent execution.  Unfortunately there is still significant overhead in evaluating the parse-tree, at least compared to a VI that encodes the same model function.  And that is the second interface: the VI.  LabVIEW 8 added the VI interface for specifying your model function.  To use this interface:
1.  create a VI from a template (...\vi.lib\gmath\NumericalOptimization\LM Model Function and Gradient.vit), and code your model function in it.
2.  pass a reference to your model function VI to Nonlinear Curve Fit.vi

Besides the faster execution, using the VI interface also allows you to explicitly compute the partial derivatives of your model.  If you choose not to compute the partials, the Nonlinear Curve Fit will use finite differences to compute them.  However, if you can compute them this will result in additional performance and numerical accuracy.

To demonstrate this I recoded your example from the other thread to also use a VI reference.  I did not limit the model to just offset and peak, but left all degrees of freedom in the model, and used your code for initial guess coefficients.  The partial derivatives are also computed explicitly.  With this I see an average speed-up over the formula-string interface of ~7x (19ms VS 134ms).  I did this quickly, so apologies for the messy diagram.

I am curious how this coding compares with the C-implementation of the Levenburg-Marquardt algorithm you are using.  Could you post some performance numbers?

-Jim

[sandsbl]

I was unaware that there was so much overhead associated with the formula string version. Thanks for pointing that out. Unfortunately, I picked what at the time was the easiest method of inputting the model, but easiest is rarely best 🙂 . I have attached a zip file containing essentially the same VI that was uploaded for the thread concerning the Nonlinear Curve Fit. I changed it so that both the Nonlinear Curve Fit and Gaussian Fit vi's are used to fit the data. The model being input to the Nonlinear Curve Fit is the same as that used by the Gaussian Fit, and all of the parameters are free. Because of that, the bug in Nonlinear Curve Fit should not show up. I included a couple more example datasets. The problem I was noticing can be seen by examining the CENTER parameter that is output from each function. For the Nonlinear Curve Fit, this parameter is being calculated ok insofar that it is an interpolated value of the location of the peak. The output from the Gaussian Fit however is merely the maximum data point, which can be verified by checking the text file for the data being input. This behavior occurs for no specification of initial parameter values. If I wire in the initial guesses (which are reasonably close to the real values), the final values do not change from the initial inputs. I would ignore the time165_aug.txt file since that data is noisy. This would be the reason why I had to "help" the Nonlinear Curve Fit by determining the peak location by other means.

I will certainly get performance data on the C implementation and post the full results. Since there seems to be such a significant difference between the two Nonlinear Curve Fit input methods, I am very interested to see how this compares. For now, the timing should be considered an upper limit since I am working on linking the C version with the lower level BLAS libraries. I am curious. Since the Gaussian Peak Fit immediately calls an external library function to do the fitting, is it using a lower level implementation of Levenberg-Marquardt, or is it even using that algorithm, because there are others.

Brian.

[sandsbl]

Here is a timing analysis comparing the two methods of Nonlinear Curve Fit and the call to the external C library function:

Nonlinear Curve Fit (formula string): Average time = 202 ms.
Nonlinear Curve Fit (referenced VI): Average time = 10 ms; mode = 8 ms.
external library function call: Average time < 1ms;

These were done on a PIII, 930MHz w/256Mb RAM. The averages were out of 25 separate runs.

Brian.