search

buzsakilab / buzcode

Code for internal lab sharing - polishing has started but is by no means complete
http://www.buzsakilab.com/
GNU General Public License v3.0
119 stars 128 forks source link

Importing ks2-data with 'disconnected' channel via bz_LoadPhy gives wrong channel numbers #374

Closed lmfklaver closed 4 years ago

lmfklaver commented 4 years ago

I am experiencing problems with reading in KS2 data with a 'disconnected' channel via bz_LoadPhy, and hope one of you can help:

Our .dat file consists of 33 channels simultaneously (32EC and 1JC). I run Kilosort2 on 32 of the 33 channels, by 'disconnecting' one of the channels in the channel map. (This works fine, it does not take into account the JC.)

I then open the clustered data in phy2 and there I see 118 clusters (unsorted), detected over 20 unique channels (ranging between Channel # 1 and # 32).

I then label all channels as 'good', so they can be read in by bz_LoadPhy (an older version of buzcode). However, the output I get consists of 117 clusters detected over 20 unique clusters with maxWaveformCh-channels ranging in number from # 1 to # 33. (I assume bz_LoadPhy does not read in the 0 cluster, because it's assumed to be the noise cluster.)

I also tried the latest bz_LoadPhy update in buzcode,, but that results in the following error even before "Pulling out waveforms". 

Error in bz_LoadPhy (line 134)
                wf =
                cat(3,wf,bz_LoadBinary([sessionInfo.session.name
                '.dat'],'offset',spkTmp(jj)
                - (wfWin),...

My xml file specifies 33 channels, and if I manually set the sessionInfo to 32 channels, it does run, but I assume everything will turn out scrambled that way. Also, it still gives me 117 outputs spread over 29 unique channels (ranging from ch# 1 - ch# 32).

What do you think could cause this read-in error / mismatch between the channel numbers and, more importantly, what can I try to do to solve it?

Thank you

Edit: total # clusters was a phy2 issue, for some reason it does not use continuous numbering in the IDs. I changed it for clarity in describing the problem.

dlevenstein commented 4 years ago

@valegarman maybe you can help with this?

I haven't used bz_LoadPhy, but I think everything should go through bz_getSpikes now.

lmfklaver commented 4 years ago

I don't think bz_GetSpikes is taking phy input yet.

I managed to solve the issue by creating a different folder for the ks2/phy2 output, copying the .dat and .xml and creating a new session info in this folder that has the juxta channel indicated in the sessionInfo.badchannels field. It probably had something to do with the need for conflicting sessionInfos, works fine now!

dlevenstein commented 4 years ago

Ah - are you using the master or dev branch? The update to bz_GetSpikes is just on dev, not yet merged to master. Glad you found a solution!

lmfklaver commented 4 years ago

Oh that's good to know, I'm using the master branch, but will check the dev out. Thanks for pointing this out!

valegarman commented 4 years ago

bz_GetSpikes in the dev branch should handle phy inputs. We had never tested KS2 with these functions though...

On Fri, Jan 17, 2020 at 10:45 AM Dan Levenstein notifications@github.com wrote:

Ah - are you using the master or dev branch? The update to bz_GetSpikes is just on dev, not yet merged to master. Glad you found a solution!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/buzsakilab/buzcode/issues/374?email_source=notifications&email_token=ACAEXPMTT43274BDLU6JFA3Q6HHAXA5CNFSM4KHXIFAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJICTNY#issuecomment-575678903, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACAEXPOBDYIWCL5UUVGKTELQ6HHAXANCNFSM4KHXIFAA .

-- Manuel Valero García, PhD Buzsaki Lab http://buzsakilab.com/wp/contact/. NYU Neuroscience Institute. New York University, 435 East 30th Street, 13th floor, New York, NY 10016. http://valeroneuroscience.ddns.net/ http://valeroneuroscience.ddns.net/

brendonw1 commented 4 years ago

Basically never use master branch - always use dev :) Dev is reasonably well vetted already and will have newer versions than master - more features and fixes usually (unless feature adding adds bugs) Unless something suspicious is wrong in something that's in dev, then maybe you could try the version in master, in case

On Fri, Jan 17, 2020 at 10:53 AM valegarman notifications@github.com wrote:

bz_GetSpikes in the dev branch should handle phy inputs. We had never tested KS2 with these functions though...

On Fri, Jan 17, 2020 at 10:45 AM Dan Levenstein notifications@github.com wrote:

Ah - are you using the master or dev branch? The update to bz_GetSpikes is just on dev, not yet merged to master. Glad you found a solution!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/buzsakilab/buzcode/issues/374?email_source=notifications&email_token=ACAEXPMTT43274BDLU6JFA3Q6HHAXA5CNFSM4KHXIFAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJICTNY#issuecomment-575678903 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/ACAEXPOBDYIWCL5UUVGKTELQ6HHAXANCNFSM4KHXIFAA

.

-- Manuel Valero García, PhD Buzsaki Lab http://buzsakilab.com/wp/contact/. NYU Neuroscience Institute. New York University, 435 East 30th Street, 13th floor, New York, NY 10016. *http://valeroneuroscience.ddns.net/ <http://valeroneuroscience.ddns.net/

*

— 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/374?email_source=notifications&email_token=AA26WTJL4XUGVPKJ5VU5RADQ6HH6RA5CNFSM4KHXIFAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJIDNJY#issuecomment-575682215, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA26WTL5WAYDAY4Q3DFYO6TQ6HH6RANCNFSM4KHXIFAA .