User configurable voltage initialization for the compartmental model

[WillemWybo]

The initial voltage is now made configurable through a parameter "V_init" in the status dictionary.

I have also added functionality to check for unused dictionary items in compartment and receptor parameter dictionaries. However, someone should probably review it to check whether the way I implemented it is the best way. Solves #2315

[clinssen]

@WillemWybo : could you fix the merge conflict? Cheers!

[med-ayssar]

Mainly my review was focusing on the unitest. Maybe take a look at our newly transpiled sli tests to pytest to have an idea about the syntax being used.

For the pre_run_hook it is better to stay consistent with the other interfaces provided by the NEST kernel, and thus I am in favor of removing the newly introduced parameter to this method.

[github-actions]

Pull request automatically marked stale!

[clinssen]

cheers!

[WillemWybo]

Ping @terhorstd @clinssen can we merge this PR?

[clinssen]

@heplesser

[heplesser]

@WillemWybo Please excuse my much delayed review. I have some comments on code style details (not top priority, can be fixed later, except for the double initialization of data members in the class declaration and the constructor; should happen in constructor only).

My main question is if it is really necessary to introduce v_init_. Can the user not set v_comp_ to its initial value directly, i.e., provide {"C_m": 1.00, "g_C": 0.00, "g_L": 0.100, "e_L": -60.0, "V_m": -60.0}? That would avoid a new parameter name and be more consistent with the behavior of NEST models otherwise.

I also wonder if it is necessary to store v_init_ as a member in each channel instance. As far as I can see, it is used only in pre_run_hook(), so if you pass the initial membrane potential from the compartment's pre_run_hook(), you don't need it as a member variable. That will save memory and ensure consistency. Note that since the channel classes are not derived from Node, you can add arguments to their pre_run_hook() method as you like.

Finally, I wonder why you defined compute_statevar_m() with two reference arguments instead of returning the two results as a pair as in f_numstep(). In my opinion this makes for much more readable code. So unless it is proven that this gives a noticeable performance benefit, I would prefer returning a tuple.

[WillemWybo]

@heplesser I modified the compute_statevar functions to returns std::pairs.

[heplesser]

@WillemWybo Thanks for the fixes. I have a few more small comments, a bit more on code formatting, and then a solution to avoid "magic" -75 mV in the Na/K constructors.

[heplesser]

@WillemWybo Thanks!