New interface for channels with cell.add_global_param()

[michaeldeistler]

cell.add_global_param("e_k", -80.0)
cell.add_global_state("e_ca", -80.0)

then e_k can be accessed via params["e_k"].

[jnsbck]

I dont quite understand this. could you elaborate? :)

[michaeldeistler]

Ah, yes, I created this issue in a rush during a zoom meeting and forgot to add more details.

We got feedback that it is unintuitive that things like reversal potentials or temperature are channel_params. Instead, they should simply be a property of the membrane. I am not sure yet how to best implement this, but the above was my initial idea.

[michaeldeistler]

We (@kyralianaka @huangziwei @jnsbck) decided on the following:

The add_membrane_param() method will replace global channel params.

This implies the following:

1. All parameters and states within a channel are strictly local
2. We can get rid of f"{prefix}_gNa" and just call it gNa.
3. We have a .prefix for every channel which will be used to generate the name of the parameter in self.nodes.
4. Any parameter that is global across channels must be added via add_membrane_param(). We will not provide default values for any global membrane params or states.
5. To distinguish between params and states, we will have add_membrane_param() and add_membrane_state().

Additional improvements to Channel:

• rename channel_params to params
• ensure that dt and delta_t are consistent and the ordering of input args is consistent. We suggest: v, states, params, dt.
• rename _name to name

[michaeldeistler]

@r-makarov see above---we are sketching out a new structure for channels. If you have any feedback, that would be great!

[jnsbck]

While we're at it, we should rename all delta_t to dt for consistency's sake

[michaeldeistler]

or the other way around :) Linters complain about dt, but not about delta_t.

(but I think I also tend towards dt.)

[r-makarov]

@michaeldeistler Sounds great! I'm in favor of all the proposed changes.

2. I would suggest avoiding duplication in names like Na_gNa in general, including in the parameter names within self.nodes. I would use gbar in this case, so it would become Na_gbar.
3. Isn't this the same as the channel's .name? Maybe it could be used directly? For consistency with NEURON notation (e.g. for some automated model construction), I would consider adding the name as a suffix rather than a prefix.
4. To ensure consistency between models, I suggest providing recommended parameter names, even though you won't set default values for these parameters.

[jnsbck]

These suggestions are great!
2. I agree that the channels currently in jaxley should do this!
3. Not necessarily. The purpose of the name attr. is mainly for the user to be able to change how the channel shows up in nodes, i.e.

slow_K = K().change_name("slow_K") 
cell.insert(slow_K)

4. I.e. write a small section on the website about naming conventions or if you meant something else could you give an example?

Another thing I just noticed: The methods in channel / synapse are called update_states and init_state. I think we should settle for either singular or plural.

[r-makarov]

Thanks!

3. Based on Michael's comment above, I thought that the prefix generates the parameter name in self.nodes. When renaming a channel, would users need to modify both the name and prefix attributes?
4. Yes, that would be helpful to document on the website. In addition, probably these parameters can be added to the params dictionary with their values set to None.

Have you made any decision regarding the temperature adjustment factor tadj? Should it be computed in the init_params method? Is it going to be accessed as a parameter or state or just a channel’s attribute directly? Also, when users change global parameters like temperature, would they need to re-run init_params for all channels e.g. to calculate new tadj?