Standardizing firing rate map

[petersenpeter]

I am also looking for a way to standardize a firing rate map and a PSTH. I consider this a cell specific type of information, but as far as I can see there is no standardization of this in buzcode.

For mazes I linearize, I store the firing rate map as below with supplementary information: firingratemap.cells: a ratemap for each cell stored in cell format but with the same length for all cells, like how waveforms are stored now. The map should as standard be in firing rate (Hz). Can be a Nx1 for a single state or a NxM for M different states. firingratemap.x_bins: the center of the spatial bins for the map in .cells. e.g. [2.5:5:120] for a 120cm maze with 5 cm bins. firingratemap.x_labels: This will typically contain the metric and its unit e.g. Position (cm). We could also separate out the metric and its unit into separate subfields... firingratemap.y_labels: as above but for the y-axis, standard: Firing rate (Hz) firingratemap.boundaries: If a map is combined by multiple sections, the boundaries can be defined here (in the same unit as x_bins). firingratemap.boundaries_labels: The labels for each section. e.g. {'central arm', 'left arm', 'right arm'} firingratemap.state_labels: Provides a description for each state. e.g. {'pre-stim','stimulated trials','post-stim'}

The same subfields can be applied to a PSTH. What do you guys think?

[dlevenstein]

I think david is saving firing rate place fields. Not sure what he’s using

On Feb 28, 2019, at 7:50 PM, Peter Petersen notifications@github.com wrote:

I am also looking for a way to standardize a firing rate map and a PSTH. I consider this a cell specific type of information, but as far as I can see there is no standardization of this in buzcode.

For mazes I linearize, I store the firing rate map as below with supplementary information: firingratemap.cells: a ratemap for each cell stored in cell format but with the length for all cells, like how waveforms are stored now. The map should as standard be in firing rate (Hz). Can be a Nx1 for a single state or a NxM for M different states. firingratemap.x_bins: the center of the spatial bins for the map in .cells. e.g. [2.5:5:120] for a 120cm maze with 5 cm bins. firingratemap.x_labels: This will typically contain the metric and its unit e.g. Position (cm). We could also separate out the metric and its unit into separate subfields... firingratemap.y_labels: as above but for the y-axis, standard: Firing rate (Hz) firingratemap.boundaries: If a map is combined by multiple sections, the boundaries can be defined here (in the same unit as x_bins). firingratemap.boundaries_labels: The labels for each section. e.g. {'central arm', 'left arm', 'right arm'} firingratemap.state_labels: Provides a description for each state. e.g. {'pre-stim','stimulated trials','post-stim'}

The same subfields can be applied to a PSTH. What do you guys think?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/buzsakilab/buzcode/issues/302, or mute the thread https://github.com/notifications/unsubscribe-auth/AG7dmOBIsD6jA6r_bH-yZgD86miqzDUSks5vSHlqgaJpZM4bYCry.

[petersenpeter]

OK. We could also create a file type specifically for PSTHs and firing rate maps, or do you prefer to keep this in a cell info?

[dlevenstein]

My preference would be to try to fit into boxes that already exist if it can. Seems like this goes nicely in a cellinfo file as each map/PSTH is info about a cell. But open to discussion

On Mar 1, 2019, at 5:09 PM, Peter Petersen notifications@github.com wrote:

OK. We could also create a file type specifically for PSTHs and firing rate maps, or do you prefer to keep this in a cell info?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/buzsakilab/buzcode/issues/302#issuecomment-468828918, or mute the thread https://github.com/notifications/unsubscribe-auth/AG7dmFPDPseUKPYeC5f4Xh-tERxIMuR0ks5vSaUAgaJpZM4bYCry.

[petersenpeter]

PSTHs and Firing rate maps are really combinations of two metrics, e.g. event and cells or behavior and cells, but I don't mind keeping it as a cell, but wanted a discussion of this.

[brendonw1]

I'm not sure what to think of this. I think I agree with Dan, but I could see a different argument too

On Fri, Mar 1, 2019 at 5:38 PM Peter Petersen notifications@github.com wrote:

PSTHs and Firing rate maps are really combinations of two metrics, e.g. event and cells or behavior and cells, but I don't mind keeping it as a cell, but wanted a discussion of this.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/buzsakilab/buzcode/issues/302#issuecomment-468835681, or mute the thread https://github.com/notifications/unsubscribe-auth/ADXrTQbjQEhFxypdy4UH6brzr0dAHvk2ks5vSavIgaJpZM4bYCry .

[petersenpeter]

OK I will keep it as a cell, and keep the proposed structure unless other proposals are presented in this thread :-)

[samamckenzie]

I think it can be made very general in the form of inputs to an accumarray function

independent variable 1 (time/space/frequency) bins for variable 1 dependent variable 2 (firing rate, lfp component) normalization variable 3 (occupancy) function handle - mean/median

this can be made into a class that will then compute on the fly.

thoughts?

sam

On Fri, Mar 1, 2019 at 6:00 PM Peter Petersen notifications@github.com wrote:

OK I will keep it as a cell, and keep the proposed structure unless other proposals are presented in this thread :-)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/buzsakilab/buzcode/issues/302#issuecomment-468840649, or mute the thread https://github.com/notifications/unsubscribe-auth/ANnfgMpp7zjgZAzCLRk5y39sP_d7Qqu1ks5vSbERgaJpZM4bYCry .

[brendonw1]

This is a good framework Sam. I'd add more specificity like normalization variable name normalization variable data

On Sat, Mar 2, 2019 at 8:34 AM samamckenzie notifications@github.com wrote:

I think it can be made very general in the form of inputs to an accumarray function

independent variable 1 (time/space/frequency) bins for variable 1 dependent variable 2 (firing rate, lfp component) normalization variable 3 (occupancy) function handle - mean/median

this can be made into a class that will then compute on the fly.

thoughts?

sam

On Fri, Mar 1, 2019 at 6:00 PM Peter Petersen notifications@github.com wrote:

OK I will keep it as a cell, and keep the proposed structure unless other proposals are presented in this thread :-)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/buzsakilab/buzcode/issues/302#issuecomment-468840649 , or mute the thread < https://github.com/notifications/unsubscribe-auth/ANnfgMpp7zjgZAzCLRk5y39sP_d7Qqu1ks5vSbERgaJpZM4bYCry

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/buzsakilab/buzcode/issues/302#issuecomment-468921156, or mute the thread https://github.com/notifications/unsubscribe-auth/ADXrTXn5zQnuSbZITrOiQ_1YU4fr-6WPks5vSn3pgaJpZM4bYCry .

[petersenpeter]

I would like to push again that this should be its own type. This makes an automatic detection of firing rate maps possible. In the Cell explorer pipeline it automatically detects *.firingRateMap.mat files structured as below:

A Matlab struct (ratemap) containing firing rat maps, stored in a .mat file: sessionName.ratemap.firingRateMap.mat with the following fields:

map: a 1xN cell-struct for N units each containing a KxL matrix, where K corresponds to the bin count and L to the number of states. States can be trials, manipulation states, left-right states... x_bins: a 1xK vector with K bin values used to generate the firing rate map. state_labels: a 1xL vector with char labels describing the states.

This allows one to create specific maps per state: trials, stimulation conditions, task specific left/right runs (e.g. for splitter cells). We can discuss the naming of the fields if you have preferences. For my project, I have a general average firing rate map, and maps for states (pre/cooling/post), trials, and left/right each saved to their own firingRateMap.mat file.

[AntonioFR8]

Ok, I will make it give an output as you describe below that is directly compatible with CellExplorer. I made it as it is following what I understand is the current convention in buzcode. For now I will make it generate two outputs then.

I will also include a speed threshold based on Kaman filter as Sam suggested

On Oct 29, 2019, at 7:43 AM, Peter Petersen notifications@github.com wrote:

I would like to push again that this should be its own type. This makes an automatic detection of firing rate maps possible. In the Cell explorer pipeline it automatically detects *.firingRateMap.mat files structured as below:

A Matlab struct (ratemap) containing firing rat maps, stored in a .mat file: sessionName.ratemap.firingRateMap.mat with the following fields:

map: a 1xN cell-struct for N units each containing a KxL matrix, where K corresponds to the bin count and L to the number of states. States can be trials, manipulation states, left-right states... x_bins: a 1xK vector with K bin values used to generate the firing rate map. state_labels: a 1xL vector with char labels describing the states.

This allows one to create specific maps per state: trials, stimulation conditions, task specific left/right runs (e.g. for splitter cells). We can discuss the naming of the fields if you have preferences.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/buzsakilab/buzcode/issues/302?email_source=notifications&email_token=ADHSQQ2446KSAMHFNHCEONDQRAOX3A5CNFSM4G3AFLZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECQF7UQ#issuecomment-547381202, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADHSQQ5RC7MOJZGEOTSTLATQRAOX3ANCNFSM4G3AFLZA.

[dlevenstein]

I think we should do one output. Can't you just make CellExplorer able to check if a cellinfo file has the proper stuff and read it in if it does?

[dlevenstein]

If it must have a different name "firingRateMap", then so be it, but then it can't take advantage of the other features of .cellinfo files - for example, loading cellinfo files from multiple nested folders via bz_LoadCellInfo.

[AntonioFR8]

Well, one output will be best, but then either Peter changes his CellExplorer inputs or we change the buzcode convention. Either one is good for me, since any of these will be different from my current format.

On Oct 29, 2019, at 11:57 AM, Dan Levenstein notifications@github.com wrote:

I think we should do one output. Can't you just make CellExplorer able to check if a cellinfo file has the proper stuff and read it in if it does?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/buzsakilab/buzcode/issues/302?email_source=notifications&email_token=ADHSQQ4ZLNQ57NLJCRACFXTQRBMOXA5CNFSM4G3AFLZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECRBX2Y#issuecomment-547494891, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADHSQQZ7OXIMCYZTYCW62GDQRBMOXANCNFSM4G3AFLZA.

[petersenpeter]

OK. I am not sure what this means, but we can discuss it further in person.

Den tir. 29. okt. 2019 kl. 11.59 skrev Dan Levenstein < notifications@github.com>:

If it must have a different name "firingRateMap", then so be it, but then it can't take advantage of the other features of .cellinfo files - for example, loading cellinfo files from multiple nested folders via bz_LoadCellInfo.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/buzsakilab/buzcode/issues/302?email_source=notifications&email_token=ADLPZOPX7DUE2RKWVECSMQ3QRBMUVA5CNFSM4G3AFLZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECRB6GY#issuecomment-547495707, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADLPZOIDHHWNZVQU6KNG2YDQRBMUVANCNFSM4G3AFLZA .

[dlevenstein]

It just means that if it is a new file type: "firingRateMap", then it can't take advantage of any of the other code that is written to use cellinfo files. This is why I'd like to try to fit it the existing box of cellinfo. How hard would it be to allow CellExplorer to load it as a cellinfo type (which will include all of the fields you specified earlier)?

[petersenpeter]

Loading all cellinfo files to find firing rate maps is not a good strategy but if firing rate maps mat files had a specific naming convention, it could likely still work. For me this breaks the current naming convention if we move the type of data into the struct name and goes agains the naming logic where data types have their own place. basename.structname.datatype.mat will become basename.structname_subdatatype.datatype.mat

Den tir. 29. okt. 2019 kl. 12.05 skrev Dan Levenstein < notifications@github.com>:

It just means that if it is a new file type: "firingRateMap", then it can't take advantage of any of the other code that is written to use cellinfo files. This is why I'd like to try to fit it the existing box of cellinfo. How hard would it be to allow CellExplorer to load it as a cellinfo type (which will include all of the fields you specified earlier)?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/buzsakilab/buzcode/issues/302?email_source=notifications&email_token=ADLPZON2RGM5LVOQUKP2BNLQRBNLPA5CNFSM4G3AFLZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECRCYXY#issuecomment-547499103, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADLPZOM6DQFXWC22R5JWTODQRBNLPANCNFSM4G3AFLZA .

[dlevenstein]

? I'm not sure what you mean by this. I'm not talking about loading all cellinfo files to find firing rate maps, nor does anything I'm saying require changing the naming of data types.

All I'm saying is that there are other functions in the repo that use cellinfo files, which all cellinfo files can take advantage of. If we make this a new file type, it can't take advantage of these features.

It seems to me that this file can fit fine within the confines of a cellinfo file (all the fields you stated will just be auxiliary fields). So I don't see a reason why not use the file type we already have. However, if you want to make it a new file type, you're welcome to.

[AntonioFR8]

Peter, I updated the function so now it gives another, optional, output that is compatible with CellExplorer. Check it and change it as you wish. Ideally we should have only one output.

On Tue, Oct 29, 2019 at 1:02 PM Dan Levenstein notifications@github.com wrote:

? I'm not sure what you mean by this. I'm not talking about loading all cellinfo files to find firing rate maps, nor does anything I'm saying require changing the naming of data types.

All I'm saying is that there are other functions in the repo that use cellinfo files, which all cellinfo files can take advantage of. If we make this a new file type, it can't take advantage of these features.

It seems to me that this file can fit fine within the confines of a cellinfo file (all the fields you stated will just be auxiliary fields). So I don't see a reason why not use the file type we already have. However, if you want to make it a new file type, you're welcome to.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/buzsakilab/buzcode/issues/302?email_source=notifications&email_token=ADHSQQ3S5VP3UDCJ5CBVPS3QRBUDRA5CNFSM4G3AFLZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECRJWUA#issuecomment-547527504, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADHSQQ4DA2NX4NZR57XA6H3QRBUDRANCNFSM4G3AFLZA .

-- Antonio Fernandez-Ruiz, PhD Sir Henry Wellcome Post-doctoral fellow Buzsaki Lab. NYU Neuroscience Institute New York University, Langone Medical Center East River Science Park, 450 East 29th Street, 9th Floor New York, NY 10016