Levenberg Marquardt curve fitting pt.2

[l1k]

I am trying to implement the Levenberg Marquardt curve fitting code, and I was wondering if it was possible to put limits on the parameters.  For example, I know that parameter 'b' can never go below 0.  If it does, the function will output NaN, and the code crashes.  I tried putting limits on the input array (Properties, unclick the default, set min to 0), but I guess that doesn't carry over to the Lev-Mar subroutine during the convergence.  The subroutine is password protected, so I can't go in there and try to put limits there myself.  I'm using Levenberg Marquardt  'f(X,a) as a vi', if that makes a difference (v.8.2).

Also, why don't I have to input a derivitive?  Does the code do this automatically, or have I misunderstood this point?

Thanks,

Laura

[l1k]

Oh yeah, I've tried putting an absolute value in the call function.  It stops the error, but I'm worried it's confusing the converging process.  Plus, in the future, I imagine it would be nice to specifiy the values can only go from 0-1 or something like that....Thanks again in advance!

[altenbach]

If derivatives are not available, the code will use analytical derivatives automatically.

If you want parameter bounds, you would need to upgrade to 8.5 (or implement it yourself).

See http://zone.ni.com/reference/en-XX/help/371361D-01/gmath/con_nonlin_curve_fit/ from the 8.5 help.

The limits apply to the control, not the underlying data so what you were tryinng will not work. You also cannot guarantee that the value will become <0 during a later iteration. You can also try to re-parameterize your model so negative values are allowed.

Which subroutine is password protected? Your model VI?

[l1k]

Thanks, it looks like the 8.5 version is exactly what I need.  It might be awhile before I'm able to upgrade however...

The password protection comes from when I double click the 'Nonlinear Curve Fit LM.vi'.  If I try to make any changes on that vi, and then try to 'Save As' (I don't want to overwrite the built in version), it asks for a password (Authentication: ... is password-protected. Enter the password to allow editing the library.')  I'm guessing there's no way to get past this?

[altenbach]

---

@l1k wrote:
it asks for a password (Authentication: ... is password-protected. Enter the password to allow editing the library.')  I'm guessing there's no way to get past this?

---

This is actually an oversight and is not intended to act like that from what I heard. Still, this same bug snuck into the 8.5 version for some reason. It is even worse in 8.5, because the "save as" is always greyed out! 😞

I thought it was going to get fixed! This is extremely annoying!!!!!

As a workaround:
Just "select all" on the diagram, open a new VI, paste the code, hook up the connectors, save elsewhere.

[Roy_F]

---

@altenbach wrote:

This is actually an oversight and is not intended to act like that from what I heard. Still, this same bug snuck into the 8.5 version for some reason. It is even worse in 8.5, because the "save as" is always greyed out! 😞

---

This was reported to R&D (CAR # 3XT91GJ1) for further investigation.

File >> Save As on a VI in a library has the potential to change the library, which is not allowed for a locked library, hence the reason Save As was disabled for locked libraries. The complicating factor though is that not all Save As operations WILL change the library, hence the bug. In this particular case, the developer intended to protect the library, but not the VIs within the library, hence the VIs themselves are not password protected.

BTW - A slightly easier workaround is to copy the VI on disk to a different name, open the copy, select File >> Disconnect From Library, Save.

Roy

Message Edited by Roy F on 09-19-2007 03:58 PM

[Roy_F]

I forgot to address a related issue: Why are you allowed to modify and save a VI in a password protected library?

Setting password protection on a library just protects the library. If you don't want someone to modify a VI, you have to protect that separately. There are valid use cases for both scenarios, hence the freedom to do either.

Roy

[altenbach]

Thanks Roy 🙂

This looks like a useable workaround once you find you way around in the vi.lib hierarchy. 😉

The other point is along some of the security that VISTA (and later) is trying to address. A plain user simply has no business messing around in "program files", even accidentally.

(True story: Last month, my mouse accidentally slipped to the menu entry "save all" in my toplevel VI (actually intending a "save as...") after casually testing some modified vi.lib VIs that I had still open. Bummer!! I am not sure what a better solution would be, e.g. make vi.lib VIs open as read-only by default. A warning dialog when trying to save in vi.lib?)

Well that's all a bit offtopic here. Let me think about it. 🙂

[Roy_F]

Still off topic - Vista and changing VI.lib VIs...

We continue to make changes to LabVIEW to be more Vista compliant. There were some presentations at NI Week which discussed some of the changes that will be made, but not allowing writes to anything under Program Files is one of them. We'll be publishing some documentation in the months ahead to help users handle the changes we're making and the changes users "should consider" making to their applications.

Roy

[l1k]

Back on topic!  OK, I got my hands on LabView 8.5.  When I try substituting just the new Nonlinear Curve Fit LM bound with the original Lav-Mar.vi, I get an error that says:

Error -20039 occurred at NI_Gmath.lvlib:LM get new coeffiencts.vi
Analysis:  The number of columns in the first matrix is not equal to the number of rows in the second matrix or vector.

I've sort of followed it all back, and I think the problem is that the 'projected gradient' array is never created in the 'CNR project gradient and hessian.vi'.  I don't know why or what that means, but I do know that in the next vi, it then gives me an error because that 'projected gradient' is not the right size. 

The attachment is a screenshot trying to prove that I can put the inputs into the older vi (Lav-Mar.vi) - and the code runs, but if I use the new version, I get the above error.

Are there any examples using this new vi to show me if I'm doing something wrong?  Thanks!