stdrun.hoc and loading dlls

[Brad]

Take the following script example:

Code: Select all

nrn_load_dll("nrnmech2.dll")
xopen("$(NEURONHOME)/lib/hoc/stdrun.hoc")

create dend
dend insert h

We manually load a set of mechanisms (the only dll present in the current directory); in this example case, it contains a single mechanism named "h". We then open stdrun.hoc because it contains a host of tools we'd like to use later in our simulations/processing. We create a section and insert the mechanism into the section.

The interesting thing occurs when the order of the first two lines is reversed. When stdrun.hoc is loaded before the dll, the interpreter generates a syntax error on/near the insert statement.

We suspected that there might be a name collision (ie a previous use of the variable name "h") but
1. h is an undefined variable
2. the output of allobjectvars() does not indicate that any object with that name is created in the chain of events of opening stdrun.hoc
3. name_declared("h") returns 1, but that return value is ambiguous according to the documentation.

It is not a problem inserting mechanisms with names other than "h".

What is sensitive to sequencing?

Brad

[hines]

I've been in the process of upgrading the alpha distribution
http://www.neuron.yale.edu/ftp/neuron/v ... -setup.exe
to use the latest version of cygwin and the problem seems to have gone away. I moved to c:/nrn58/demo and tested with an init.hoc file with the contents

Code: Select all

load_file("nrngui.hoc")
load_file("demo.hoc")
nrn_load_dll("release/nrnmech.dll")

and then selected the "Release" demo.

So the bottom line is that I do not know why the old version didn't succeed when loading a dll after the gui. However, there have been a number of strange but temporaray occurrences with recent cygwin versions that have been broken in a single item but then fixed in the more recent version. Examples are a system("command") that required a /bin/sh and would not allow one to specify a different one, and a broken scanf which would try to read "neuron"
as a NaN number. Anyway, try again and let me know if the problem still exists on your machine.

[Brad]

Dr. Hines,
Just tried using the newest release (5.8) as you suggested, but problem remains. I could not determine from your reply if you see this behavior on your machine. To your knowledge, is there an object that uses the name "h" in stdrun.hoc?

For part of our project, we are interested in comparing different neuron models (morphology+specified distribution of conductances). I was hoping to have a single interface to each model that the user could dynamically choose at start up with a single "xopen" statement. The specific way we were trying to implement this is to have a single model header file that fully describes a model: it would open the proper morphology description, load the appropriate section lists, and load and insert the active mechanisms. The last step is where we seem to be running into trouble - dynamically loading the mechanisms.

We are having a bit more trouble doing this than the original post would suggest, but I was hoping that your solution would give us enough to go on and fix those problems on our own. In short, it seems we get different simulation results based on the order in which we load the dlls and other library files. Needless to say, it is quite baffling. I didn't post them because the one particular toublesome model is large and somewhat cumbersome; I have not yet been able to replicate the behavior in a reduced system appropriate for posting.

It seems to me that the best strategy at this point is to give up dynamically loading the dlls, merge all the different models' mechanisms into one dll (changing the siffixes where necessary to avoid name duplication) that will be loaded automatically at launch.

Brad

[Brad]

...it seems we get different simulation results based on the order in which we load the dlls and other library files. Needless to say, it is quite baffling.

We resolved this problem. We were not setting the temperature consistently between the two header files. Amazing what a few degrees celsius will do to you simulation results! Another lesson learned the hard way.

The original issue concerning dynamic loading of dlls remains, though.

Brad