www.neuron.yale.edu

According to the NetCon documentation http://www.neuron.yale.edu/neuron/stati ... etcon.html it should be possible to use a construction in hoc like: Where, as I understand it, for values of i higher than 0 I should be accessing the extra arguments defined in a NET_RECEIVE block. I tried to get this working in a mechanism derived from tmgsyn.mod, (model: 3815 in ModelDB) in order to be able to move the facilitation and depression time constants into the NetCon object. However regardless of the number of arguments the NET_RECEIVE block takes netcon.wcnt() returns 1 indicating that weight contains only 1 element, and using netcon.weight with values of i higher than 0 givers errors.

It seems some vital ingredient is missing from my understanding of the documentation. has anybody successfully used this construction?

All of the weight vector aspects are working for me and I don't remember any bugs in that area for the past several distributions.
Why don't you send me a zip file with all your code with an init.hoc file that at the end demonstrates the problem and
I'll look into it. Send to michael.hines@yale.edu

But first verify that the NetCon instance you are looking at has a .syn that actually has multiple args in the NETRECEIVE block.

Printing the NetCon.syns was illuminating. Some of my NetCons contained other targets than expected. I supppose this is a blessing in disguise because it clearly showed the difference between what I thought my code was doing and what it actually did.

Thanks!

Raj wrote:the difference between what I thought my code was doing and what it actually did

Happens all the time. Isn't this really the fundamental problem in computational modeling? making sure that there is a close match between what's in one's head and what's in the computer?

Fundamental to modeling. I think it is save to leave the adjective computational out. I remember that one of my former colleagues had to check all his formula's because some of them used results from papers using another convention for the direction of the magnetic field. In my own work I at some point had three different indexing conventions for the same polynomials, also leading to considerable confusion. All conventions had their advantages at the time they where introduced, but when putting the different parts of the work together it required a fair amount of attention.

I think it was Weissert's book `The Genesis of Simulation in Dynamics' that shows how Fermi, Pasta and Ulam had to cope with the same problem and criticism in the early days of computer simulations. In my view there is nothing that can fundamentally solve the problem and all one can do is checking and checking again and at least convince oneself that the correspondence is correct. Then when making claims on the basis of the simulation code one should allow others access to the implementation so they can go into it and check it as well if they feel a need for it.