WIP: Add dipole recording for individual cells #682
Conversation
| @@ -37,6 +37,8 @@ def simulate_dipole(net, tstop, dt=0.025, n_trials=None, record_vsec=False, | |||
| record_isec : 'all' | 'soma' | False | |||
| Option to record voltages from all sections ('all'), or just | |||
| the soma ('soma'). Default: False. | |||
| record_dcell : bool | |||
| Option to record dipole from individual cells. Default: False. | |||
There was a problem hiding this comment.
Is there a computational hit when you do this? I think users should be warned ...
There was a problem hiding this comment.
If there is, it is substantially less than record_isec and record_vsec because the individual cell dipoles have to be recorded by default. The only difference here is that we save them at the end instead of just adding them together.
There was a problem hiding this comment.
With that said I personally haven't noticed a performance hit (will need to followup with timed tests), the main concern would be taking up too much RAM if the recording is really long
| test_dpl._baseline_renormalize(N_pyr_x, N_pyr_y) | ||
| test_dpl._convert_fAm_to_nAm() |
There was a problem hiding this comment.
I'm a little bit uncomfortable with two code paths to achieve the same objective ... the difference in the processing streams is likely to be a source of confusion for users in the future. Could they be harmonized somehow?
There was a problem hiding this comment.
do you mean testing wise? the main motivation here is that there are some very specialized transformations to take dipoles of individual cells to the aggregate dipole
I figured a good test would be making sure that the data pulled out from earlier in the pipeline matches the data produced at the end of the pipeline when we apply the same transformations
There was a problem hiding this comment.
also I admit the baseline renormalize code is a mystery to me right now. It gets applied inside the simulation call automatically...
There was a problem hiding this comment.
I think the postproc flag must be respected by cell_response.dcell ... they should give consistent results without accessing private methods
| @@ -562,6 +568,9 @@ def aggregate_data(self, n_samples): | |||
| nrn_dpl = self._nrn_dipoles[_long_name(cell.name)] | |||
| nrn_dpl.add(cell.dipole) | |||
|
|
|||
| if self.net._params['record_dcell']: | |||
There was a problem hiding this comment.
okay so record_dcell does nothing to the neuron simulation ... the dipoles are recorded no matter what. The only difference is whether they are converted from neuron into python or not ...
you may have opened a pandora's box. If you want to go down that road, we can provide cell_response.dipole ... and then in a later pull request deprecate simulate_dipole to simply simulate
There was a problem hiding this comment.
How about I switch this to a WIP flag and we use this as a PR to work out the simulate_dipole API? I agree this is a natural place to make this happen, but the pandora's box may need to stay half open until COSYNE abstracts are submitted 😉
There was a problem hiding this comment.
I agree with @jasmainak: cell-level dipoles should be accessible to the user via a similar API as other cell-level outputs.
@ntolley, WDYT of hashing out an improved simulated_dipole API with existing features first in a separate MAINT PR and keep this an ENH PR. I'm imagining this getting super huge and unwieldy....
ntolley
changed the title
This has becomes important for one of my personal projects, I've followed the code pattern I've used for recording single cell voltages and currents.