VI of the Day (10/7/2009) - Nonlinear Curve Fit VI

[Darin.K]

Today is the final installment of the fitting trifecta, and a workhorse of mine, the "Nonlinear Curve Fit VI".  The Levenberg-Marquardt method is an old-standby which I have been using long before LV implemented it.  This was the first code to make the Numerical Recipes to CIN translation years ago.  All of the same tricks for LS fitting work here, such as rearranging the data for 2D fits (see the circle and ellipse fitting examples).

A couple of points, as I always harp on, whenever you are able you should use a VI that generates both the function and the derivative.  This may mean practicing your calculus, but when isn't that a good idea.  Second, I like the constrained version as well, I do not use it unless necessary.  For large fitting problems, each added step takes time, so I like to avoid all of the range checking unless I am actually going to use it.

A familiar example, the suspension bridge is back, this time fitting to a catenary.  I'll let you judge for yourself the shape of the cable.

VIOTD groundrules here. 

[altenbach]

Ah, one of my favorite tools. Let's not forget that nonlinear fitting was barely usable before LabVIEW 8.0, but the 8.0 redesign made it very powerful and useable for anything you can throw at it. 🙂

I am not sure I agree with your statement about the partial derivatives, because the numeric derivatives typically work very well. It needs to be balanced with the added complexity of the model function, which makes it much easier for subtle bugs to sneak in. I usually deal with models where analytical derivatives are not possible (e.g. spectral fitting where the model involves convolutions).

I have models with 100+ parameters where typically only a dozen or so (selection can vary!) are fitted while the rest are kept constant. It would be nearly impossible to write an universal model that includes analytical derivatives for all possible combinations.

You should be ashamed of using a formula node. 😮 😄 LabVIEW programmers (and dyslexics) use plain G. Here's how the model would look like in real LabVIEW (one with, and one without partial derivatives).

Message Edited by altenbach on 10-07-2009 08:21 AM

[altenbach]

Also, if you use analytical derivatives (and are worried about performances), you should use the "output control" and only calculate the partial derivatives if needed. I typically use the same model for "simulation", .i.e. interactively adjusting the initial paramter estimates to see how the function changes. Here you don't need to calculate the derivatives.

[Darin.K]

---

altenbach wrote:

Ah, one of my favorite tools. Let's not forget that nonlinear fitting was barely usable before LabVIEW 8.0, but the 8.0 redesign made it very powerful and useable for anything you can throw at it. 🙂

Completely agree.  I tested the water in 7.0 since I also made a Mac/PC transition at the time, but decided it was still worth dealing with external calls.

I am not sure I agree with your statement about the partial derivatives, because the numeric derivatives typically work very well. It needs to be balanced with the added complexity of the model function, which makes it much easier for subtle bugs to sneak in. I usually deal with models where analytical derivatives are not possible (e.g. spectral fitting where the model involves convolutions).

I have models with 100+ parameters where typically only a dozen or so (selection can vary!) are fitted while the rest are kept constant. It would be nearly impossible to write an universal model that includes analytical derivatives for all possible combinations.

Very reasonable, as much as I would like to, when my fits involve numerical integrations I also have to resort to the finite difference.  Performance issues are waning as more flops per second become available, but roundoff errors should be kept in mind.  Besides, I enjoy a good excuse to put pen to paper and take a few derivatives.  If everyone becomes aware of the caveats involved with simply reaching for the finite difference, I'll have performed my duty (as I see it).

You should be ashamed of using a formula node. 😮 😄 LabVIEW programmers (and dyslexics) use plain G. Here's how the model would look like in real LabVIEW (one with, and one without partial derivatives).

Message Edited by altenbach on 10-07-2009 08:21 AM

---

I meant to comment about the formula node, I use it for toy models and to prototype my function calls.  At 6:30 in the morning I had a choice to use finite differences or a formula node (not the hardest function to find the derivative of, but I was still decaffeinated).  I would have been more ashamed of finite differences.  Knowing that it illicited these comments, I am glad that I forgot.  The formula that I removed from that formula node to modify for this example does not have such an elegant G version.  

On a (more) serious note, if I have a complete rat's nest of G code to implement a formula, I have three choices: (1) an unwieldy block diagram (2) a sub-VI to hide the mess or (3) a formula node.  (1) certainly has the best performance, but is there a noticable performance difference between the other choices?  A sub-VI call has some small overhead a formula node shouldn't but probably does as well.  And what about the implementation via a Call by Reference Node, is there any hit taken there?  More than 99(.9)% of the time you probably won't notice a difference, but I am just a bit curious since every now and then I face a problem where every flop counts.