-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP: Add dipole recording for individual cells #682
base: master
Are you sure you want to change the base?
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a computational hit when you do this? I think users should be warned ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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....
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.