www.neuron.yale.edu

Beginner here. I am having trouble compiling mknrndll on a particular Windows 7 64 bit machine. As an example, this code here doesn't seem to want to compile and spits out the following error message:
This error message is generated using Neuron 7.3 cygwin 64bit version, although I have tried all 7.4 and 7.3 distributions (32 and 64 bit) and they gave the same error message. The code compiles on a different Windows 7 64 bit machine so it's really confusing me. Is this implicative of a missing component in my setup?

There's nothing wrong with the mod file. It's software on your PC that's the problem.

Did your PC already have a version of cygwin installed before you did any of those installs?

When you were trying different versions of NEURON, did you use NEURON's own uninstaller (launched by clicking on the Uninstall icon in the NEURON Program Group) to uninstall whatever was previously installed before installing a different version of NEURON?

Was any of those uninstalls incomplete--did you get an error message about being unable to remove this or that file?

After any uninstall was there still a folder whose name started with
nrn
in the root directory of C: ?

Uninstall NEURON now and check C: for such a folder. If you see it, delete it manually. Do that as Administrator if necessary. Also verify that there is no NEURON folder in your Start menu and no NEURON-related icons on your desktop; if there are, delete all that stuff manually.

Finally, go to the folder that contains your mod file and delete any nrnmech.dll, .o, and .c files that you see.

"But I don't see filename extensions."
Well, configure your PC to make them visible. You're going to need that ability if you continue to use NEURON

Next reboot, then download the latest 64 bit installer from
http://www.neuron.yale.edu/ftp/neuron/v ... -setup.exe
and use that to install NEURON. After installation finishes, click on the neurondemo icon, click on the radio button next to "Release", and then click on the Init & Run button in the RunControl panel. Do the graphs show the time course of v, calcium concentrations, etc.?

Assuming that all went well so far, now try to use mknrndll to compile your mod file. Did it succeed?

If it didn't succeed, what was the error message? Also, tell me if you using the GUI for this, or are you launching a bash shell and working from the command line?

By the way, it's not a good idea for a mod file to calculate ionic current by a formula of the form
ih=g*h*(v-e)*gfactor
Why? You are setting a trap for yourself or anyone else who uses that mod file in the future. The standard hh-style model of an ion channel calculates current as
i = conductance_density*gating_variables*(v-e)
Everybody expects that the parameter that sets conductance density will be the actual effective conductance density. By inserting your "gfactor" term you have obfuscated your code because nobody will expect there to be some additional fudge factor. If the gfactor term is ever assigned a value different from 1, anybody who uses psection(), or NEURON's ModelView tool, or ModelDB's ModelView tool, to try to discover the actual channel density for this mechanism will get back a value that is totally misleading. That can be a debugging nightmare.

"Oh, that will never be a problem. I will know to check the value of gfactor."

Easy for you to say today. Sooner or later it's going to bite you, or some collaborator of yours, or some poor shlub who tries to reuse your code in the future.

"But I really want to be able change this mechanism's channel density by a multiplicative factor, in every segment of every section that has this mechanism."

There are perfectly safe ways to do that without setting booby traps. Example in hoc: "Nice, but what if I want to get rid of the h current by applying a factor of 0?"

Should be adequate just to scale by a factor of 1e-9. Even pharmacological blocking agents can't do as well as that.

Thanks for the reply and critique.

ted wrote:Did your PC already have a version of cygwin installed before you did any of those installs?

I've tried manually uninstalling a previously installed cygwin (following the FAQ provided here) and reinstalling NEURON 7.4, but mknrndll (both GUI and bash) spits out the exact same error. In the end I made a complete system wipe, but the same error still persists.

ted wrote:When you were trying different versions of NEURON, did you use NEURON's own uninstaller (launched by clicking on the Uninstall icon in the NEURON Program Group) to uninstall whatever was previously installed before installing a different version of NEURON?

Yes. After the uninstall process, the root folder is not to be found (as well as Start Menu/Desktop shortcuts). Also, any ghost files should have been removed after the system wipe...

ted wrote:After installation finishes, click on the neurondemo icon, click on the radio button next to "Release", and then click on the Init & Run button in the RunControl panel. Do the graphs show the time course of v, calcium concentrations, etc.?

neurondemo works as it should be.

I've also tried running the setup file as an admin, but it didn't help as well.

ted wrote:By the way, it's not a good idea for a mod file to calculate ionic current by a formula of the form
ih=g*h*(v-e)*gfactor
Why? You are setting a trap for yourself or anyone else who uses that mod file in the future. The standard hh-style model of an ion channel calculates current as
i = conductance_density*gating_variables*(v-e)
Everybody expects that the parameter that sets conductance density will be the actual effective conductance density. By inserting your "gfactor" term you have obfuscated your code because nobody will expect there to be some additional fudge factor. If the gfactor term is ever assigned a value different from 1, anybody who uses psection(), or NEURON's ModelView tool, or ModelDB's ModelView tool, to try to discover the actual channel density for this mechanism will get back a value that is totally misleading. That can be a debugging nightmare.

"Oh, that will never be a problem. I will know to check the value of gfactor."

Easy for you to say today. Sooner or later it's going to bite you, or some collaborator of yours, or some poor shlub who tries to reuse your code in the future.

"But I really want to be able change this mechanism's channel density by a multiplicative factor, in every segment of every section that has this mechanism."

There are perfectly safe ways to do that without setting booby traps. Example in hoc:

Code: Select all

// set_hcurrentGFACTOR(k)
// makes g_hcurrent equal to k times its model setup value
hcurrentGFACTOR = 1 // used to store the current value of the multiplier
proc set_hcurrentGFACTOR() {
  forall if (ismembrane("hcurrent")) {
    for (x,0) g_hcurrent(x)*=$1/hcurrentGFACTOR
  }
  hcurrentGFACTOR = $1
}

"Nice, but what if I want to get rid of the h current by applying a factor of 0?"

Should be adequate just to scale by a factor of 1e-9. Even pharmacological blocking agents can't do as well as that.

Thanks for this. I inherited the code from someone else, so I'll try to keep these points in mind.

Lantern wrote:I inherited the code from someone else, so I'll try to keep these points in mind.

So you're the poor shlub then. Fortunately, there doesn't seem to be anything in ModeDB that uses gfactor, so you're in a position to prevent inflicting this pernicious bug-in-waiting on your colleagues in computational neuroacience. Of course that's no guarantee against somebody doing something similar using a different name for the "factor," but we can always hope it won't occur to anyone else.

Lantern wrote:neurondemo works as it should be.

Tell me, where exactly did you put the mod file before you tried to compile it? Complete path, please.

ted wrote:Finally, go to the folder that contains your mod file and delete any nrnmech.dll, .o, and .c files that you see.

So I missed this. Turns out after deleting the .o and .c file that mknrndll worked out. This confuses me because on my other machine having them there doesn't seem to affect the process. Is there a reason why it's producing an error here in this machine?

Be happy for your good fortune. In my experience using NEURON under MSWin, having to delete .o, .c, and .dll files in order to recompile mod files has been the rule, not the exception. To me the question is why your other machines let you get away without having to do that!