alpha simulation fails (NEURON?)

[cjayb]

Walkthroughs in examples for evoked and gamma work fine, but alpha fails mysteriously. I've set 'tstop': 110.0 for speed, but below is equally valid for the default 710.0.

In the hopes of finding a bug in params, I even tried this (3 keys differ, not that they seemed important):

params_fname = op.join(hnn_core_root, '../hnn/param', 'OnlyRhythmicDist.param')

But I get the same plots. The same example works fine in hnn, in the same conda env., where NEURON is from PyPi (7.8.0-127-g91f6e623+).

I guess what I'm asking is: any pointers on where to start debugging my setup? I suppose it's likely my NEURON installation, though I've been through the tests for nrnpython, which run quite happily in a parallel context (openmpi, mpi4py) on my dual-core macOS Catalina laptop.

[jasmainak]

@cjayb thanks for giving this a try!

Interesting, it seems that the example is broken for me as well. So, to proceed I would actually try using git bisect and find the rogue commit. Once we have the rogue commit, we can try to figure out what's wrong!

[cjayb]

I made some progress, but hitting a wall & in need of some help!

I was able to produce similar L-shaped dipole plots for the gamma-example by setting 'T_pois': -1, i.e., switching off the only input to the network. So the problem seems to be missing rhythmic (distal) input. Sure enough, the alpha-net has no spiketimes after execution (this line returns empty lists).

@jasmainak did you reproduce on Neuron 7.8.0? I tried to trace back to the earliest commits of hnn_core, but the problem persisted. NB I still have a hard time accepting that this is an nrnpython-problem, since the example works in hnn-proper.

I've tried to compare the logic in network.py, but get lost in the methods calls. Assuming nrnpython is functional, there must be a difference in how hnn_core and hnn call it? And specifically something with the rhythmic inputs.

Also: WTF? At least it explains the kink in the plots at 37 ms :)

[jasmainak]

@cjayb don't go back too far in the commits either. Because it might have been broken during the refactor. This commit for instance works fine for me. Does it work for you? I'm on Neuron 7.7.2, yes I know shame on me ... I should update :)

I don't think it's an nrnpython problem but more a bug in hnn-core since the code paths of hnn and hnn-core have diverged even though they started from the same parent.

I've tried to compare the logic in network.py, but get lost in the methods calls.

you're not the only one ;-)

Assuming nrnpython is functional, there must be a difference in how hnn_core and hnn call it? And specifically something with the rhythmic inputs.

This is just exposing the fact that there aren't enough tests in either hnn or hnn_core. Otherwise things won't break so easily. I would really try to find the rogue commit. If you do git bisect, it will keep proposing you commits. In each commit, you can run the example and see if you get the right output. Once you identify the rogue commit, the job becomes really easy.

WTF? At least it explains the kink in the plots at 37 ms :)

agreed, wtf indeed! I'm not aware of the historical reasons why this exists. Let's maybe raise a different issue for this and start a discussion? at the very least, the params need to be exposed in the function

[cjayb]

Well, git bisect did the trick :) Not sure what the best way forward is regarding tests, but we can continue that discussion elsewhere. Feel quite strongly about refactoring being needed here, but not experienced enough in API design to dare to take a first stab.

FYI: I don't recommend updating! I spent hours fiddling with compilations of openmpi (4.0.3) and nrn (7.7.2) on macOS clang (1103.0.32.62) and python=3.7 in a conda environment. Ended up ditching the effort and sticking with NEURON (7.8.0) from PyPi instead.

[jasmainak]

FWIW, neuron will soon come to pip so I'm hoping this will become smoother in the future