I thought that KTF didn't need the mV units

Wrong guess. All you did was allow modlunit to skip over the guts of FUNCTION KTF and start finding fault with other statements.

Look at modlunit's message:

Code: Select all

```
units: 1 K
units: 0.001 m2-kg/sec2-coul
The units of the previous two expressions are not conformable
at line 77 in file LcaMig.mod
KTF = ((25./293.15)*(celsius + 273.15))<<ERROR>>
```

It's all about the statement that assigns a value to KTF. KTF is supposed to get a numerical result that is in units of mV. Nothing on the right hand side (RHS) of the assignment statement has units of mV. The only thing that is associated with any particular units is celsius, and its units are degC. modlunit will complain if you try to add anything to celsius that isn't also in degC, so clearly it is necessary to change

(celsius + 273.15)

to

(celsius + 273.15 (degC)).

The (degC) notation tells modlunit that the thing to its left has units of degC.

Doing that makes the RHS into a product of a dimensionless value and something that has units of degC. Clearly the denominator in

(25./293.15)

has units of degC, and its numerator has units of mV (if that isn't so clear, stare at and think about the Nernst equation for a while).

So the completely repaired assignment statement is

KTF = ((25. (mV)/293.15 (degC))*(celsius + 273.15 (degC)))

By the way, notice that none of these changes affects the numerical value that is returned by FUNCTION KTF. They just make modlunit's complaints go away. You'll see a lot of code that uses UNITSOFF...UNITSON because an experienced programmer can write a lot of code that is numerically correct by inspection but which modlunit will complain endlessly about until you insert so many units declarations as to make the code rather unreadable. This happens especially with code that computes transition rates, or time constants and steady state values of gating state variables. Sacrificing readability for the sake of satisfying a finicky program like modlunit is not a good tradeoff.

On the other hand, there are times when it is not so obvious that a numerical conversion factor is not required, or when a statement is algebraically so complex that it contains a serious syntax error, and those are times when it really is useful to insert units declarations and test until modlunit is happy.

Now back to your next problem.

I'm assuming nu has to be dimensionless, but am unsure how to make it so

Really, you brought this one on yourself. First look at how its value is calculated

nu = v/f

where the units of v are mV (as declared in the FUNCTION ghk line) and the units of f are the same as the units of FUNCTION KTF. Oh, wait. If FUNCTION KTF returns a value whose units are nothing, then f will have units of nothing, and v/f will have units of mV. Maybe it's not such a bad thing for the value returned by FUNCTION KTF to be in mV.

It is all very satisfying when these things work out properly, but I should mention again that--so far--none of these changes does anything at all to the numerical values that are generated by the calculations specified in LcaMig.mod. Of course that's isn't to say that the next time you run modlunit, it won't find some units error that can only be fixed by including a numerical scale factor. And that's exactly the kind of error that can really mess up simulation results, because code will run--not crash--and yet results will be way off.