Does the RK4 solver VI have a maximum scan length?

[ijustlovemath]

I have to solve a differential equation in one of my VIs, and after adding in some new logic (which decides whether or not to include an extra number in the equation), it ceases the execute. The error from the RK4 solver VI is -23009: Error in Right Hand Side of equation. Further stepping through the dataflow, I've isolated it to two eq'ns: dG/dt and dI1/dt, both of which have their own VI's in the ODE solver folder. I have all number converted to a width 8, precision 12 string, and I think my most recent additions have gone past the max scan limit of the RK4 VIs. Stepping into them, I quickly find that I can't really understand what's going on, so I'm coming to you.

Some good starting parameters:

in VariableCluster.ctl, set Xa to 100, X(t-1) to .01, I1(t-1) to 10, I2(t-1) to .5

in constant control.ctl, set weight to 80, and enable Automatic Glucose.

EDIT: to start execution, run ODE solver.vi which is in the ODE solver folder.

[johnsold · Accepted solution]

In VD.vi VD is set to the value of VD Mult Constant (hidden) which defaults to zero. Later this value is used as a divisor which produces the NaN values in F(X,t). I have no idea of whether that is what you want but the NaN will keep it form solving anything.

I have not dug down past this point.

Lynn

[ijustlovemath]

I added a select there to prevent that and it's back to normal! Thanks for your help!

[johnsold]

Consider that typically default additive constants should be 0 and default multiplicative constants should be 1 to have "no effect" when the defaults execute.

Lynn

[ijustlovemath]

The thing is that, on both the typedef (which is strict) and the user input VI (where the user actually enters these values), I find that I constantly have to do "Data Operations -> Make Current Value Default" after adding new things to the cluster. When controls are hidden, new additions to the cluster apparently reinitializes them to their representation's default. Is there any way to combat this?

[johnsold]

I have never used hidden controls in a cluster, so I do not know how they behave.  I did not even know that you could hide them.

Since everything is driven from the main VI control, try putting a cluster constant on the block diagram. Set all the default values there. Then using Unbundle by Name and Bundle By Name, change only the values modifed by the user on the front panel control. That way the hidden values of the control do not matter.

It might be better to make two clusters. One would have only the visible, user-modifiable elements. The other would have all the values which you currently keep hidden.  The "hidden" cluster would only appear as a block diagram constant. They could be bundled into a single cluster for passing to the subVIs. 

Permanantly hidden controls are often a sign of a poorly thought out user interface design.

Lynn

[ijustlovemath]

That's brilliant! The way the main VI works is that the user is given a choice of entering a constant value for certain parameters, or allowing them to vary over time. Constants are put into a hidden control, and varied values are put into a hidden 2d array alongside the time intervals over which they'll be applied (ie, apply value from column 0 when the time is in between the one in column 1 and the one in column 2). At run time, these values are chosen from (in something like VD.vi) and used directly in the model.

I know this seems like a crazy way to do it, and it probably is. I just couldn't think of any other way to tackle allowing the user to specify constant vs varied parameters for testing.

With your design, that second "passing" cluster would have to be hidden too, right?

[johnsold]

Your "hidden" controls should be just values on a wire, probably on a shift register. No control or indicator required.  To maintain the advantages of typedefs create a typedef control for that data. But do not place the control on the block diagram and then hide it. Just make a constant from the control and use that to initialize the shift register.

I cannot think of a good situation where placing a control on a front panel and then hiding it makes good sense. If a control should only be accessible to the user at certain times, such as during setup, then making the control visible or not via a property node works well.  But a permanently hidden control should be a constant, not a control.

Lynn

[ijustlovemath]

I see. I need to keep track of these values during the user input phase, so I had them as controls so they would persist through everything. The way it currently works is kind of messy; during user input, whenever a value changes on the cluster, it triggers an event. The event then executes some VI to allow the user to change some value. The whole cluster is passed into this VI (using the Value property instead of a shift register), and the modified cluster is handed back and put into the Value property of the cluster again. I do realize this could be done with shift registers, but honeslty I couldn't say why it isn't. I'm working with a bunch of legacy code, so as I add things, I have tried to at least stay consistent.

[johnsold]

OK.  I did not realize that this was a part of a bigger program.

Fixing legacy code is often a delicate balance of applying current best practices against some kind of patch on the original code.

Value property nodes and local variables should be used very sparingly, if at all. They are slower than wires and shift registers, are prone to race conditions, and (worst for you) make it hard to find every place something can be changed.

If the user does not need to see all the values while the program is running, but only when changing things at setup, then consider a pop-up subVI or a subVI in a subpanel. On that subVI front panel have the controls for the values the user is allowed to change. When the user hits an "Accept" button, the pop-up or subpanel VI goes away and all the modified data is placed (via Bundle By Name) into a cluster wire carried throughout the main VI on a shift register. You may never have a cluster on the front panel at all.  If you need to display a summary of the settings, something like a table indicator might work.  It could be quite a bit smaller than the cluster while still providing the users with the information they need. If it is called something like "Settings Summary", they may not even try to change it.

Lynn