Scaling does not match HNN (original) about hnn-core

[jasmainak]

actually I take this back, it looks good to me. What do you say @rythorpe. See here: https://jasmainak.github.io/mne-neuron/auto_examples/plot_simulate_somato.html#sphx-glr-auto-examples-plot-simulate-somato-py

[rythorpe]

What changed to produce this? The simulated waveform looks good, but the scaling still seems a bit off.

[jasmainak]

nothing really. If I use the parameters you sent me, we get this. The problem arose when I tried to use the "diff" -- so maybe not all parameters were updated.

okay let me rename the issue to reflect that the scaling is off. Personally I think the right way to fix these things is with tests rather than trying to figure out what is different.

There are no tests in HNN, so it is really hard to attest a "correctness" to it. Of course, you have sanity checks but it would be hard to do software development without more solid testing.

[rythorpe]

Implementing some formal tests would be good. Let's also keep dialoguing (maybe at a different time and thread) about how to implement "diff" files in a better way.

[blakecaldwell]

Hi folks. As I mentioned to @jasmainak today, I found a couple of things causing inconsistent results with HNN:

1. Refactoring: this fixed the first dipole deviation point:
   8f43e18
   @jasmainak Mainak, since you know the logic for the refactoring, can you attack this? Alternatively, since this code is technical debt and will be removed by netpyne integration, just ignore 1).
2. The one fixed in PR #47. Commit: 8dfc00a

*) This change makes me uneasy because I don't understand the logic. The connection seemed to be unique, so I'm not sure why it's "spurious"?
12c2808

[jasmainak]

Thanks for digging into this @blakecaldwell !

regarding 1. let's fix it if you've already put in the effort into it and the code exists (which seems to be the case). I'll add a whats_new.rst page tomorrow so we can start documenting bug fixes with proper credit. A proper netpyne integration will take some time, but this is already useful!

The connection seemed to be unique, so I'm not sure why it's "spurious"?

okay perhaps I need to explain myself a bit here. This commit is part of #22 which was essentially fixing a bug introduced in the refactor of c76a27b. During the refactor I had mistakenly added a connection that should never have been there in the first place

[blakecaldwell]

Okay, that explanation helps. I wasn't sure if it was introduced by refactoring or was something that seemed ineffectual, so it was removed.

Can you fix the bug by reverting the commit or fixing the refactoring?

[jasmainak]

yep! I'm going to look into it :)