Flipped running polarity for VBN behavior only sessions

[corbennett]

Describe the bug
Due to a hardware malfunction, the polarity of the encoder used to measure running speed was flipped for a number of behavior sessions run on the behavior boxes for the visual behavior neuropixels dataset. The nwb files for these sessions appear to indicate that the mouse was running backwards. Here's a plot of the running for one of these sessions (note in particular the negative values on the right plot):

Engineering can't provide an exact list of impacted sessions, but looking at the histogram of mean speeds across sessions, they recommend a threshold of -1 cm/s, which looks like a reasonable cutoff:

Here are the behavior session ids for the sessions with mean speeds less than -1. Manual inspection confirms that all of these sessions appear to have flipped encoders.

['1102211933',
'1091800400',
'1029420108',
'1099395913',
'1100194778',
'1099832458',
'1099623071',
'1101322871',
'1100688180',
'1079013681',
'1100176592',
'1101486794',
'1096658058',
'1092231641',
'1100230109',
'1100793165',
'1079223135',
'1078579330',
'1099164948',
'1098371885',
'1098141739',
'1096262499',
'1099579114',
'1096465710',
'1078783957',
'1096951446',
'1100087539',
'1101080541',
'1102183214',
'1101698040',
'1099898239']

To Reproduce
Plot the running over time for any of the above session nwb files.

Expected behavior
The sign of the running traces for these sessions should be flipped (ie the running values for these sessions should be multiplied by -1)

Do you want to work on this issue?
Happy to help validate these when the bug is fixed.

[morriscb]

Hey @corbennett, I was able to verify the experiments you listed above by running through the VBN dataset and finding those sessions that have an average running speed of <-1 cm/s. There is a working version of the proposed fix ready for you to validate on the branch ticket/PSB-70/dev. The fix is coded in such a way that it will fix the already released sessions when a user requests them from the s3 cache and sessions newly loaded from LIMs. Please, take a look when you have a chance.

As part of this validation, I also looked at the already released VBO data. @matchings @DowntonCrabby @mattjdavis there are 10 behavior_sessions in the VBO dataset that seem to exhibit the same behavior that @corbennett describes on this issue. Is this something already known to you, that is has Engineering made you aware that the VBO data has a similar "running backwards" issue? To be clear, the fix as implemented will flip the running speed on the sessions listed below as well. Here's an example plot of the running speed for reference:

The behavior sessions are listed below:
[1078088267,
1078624488,
1078807113,
1079038909,
1096427252,
1096608848,
1096908438,
1097127961,
1098143934,
1102170786]

[DowntonCrabby]

@corbennett has anyone reviewed the behavior videos to make sure that this a problem with the encoder and not actually a mouse who is being strange on the wheel? If you can provide me the behavior video links to all these behavior sessions I'm happy to review them.

[corbennett]

@DowntonCrabby unfortunately, the VBN sessions were all behavior-only sessions that took place on the behavior rigs. The video data for these sessions doesn't get stored permanently and I believe we're well outside the window for which this data would still be available. I'll confirm this. But there are a couple of things that give me confidence that this is actually an encoder issue:

1. the bad sessions are clustered in time for particular rigs (at least the VBN ones)
2. this was a known issue that MPE reported on and fixed.

I suppose there's a (3) which is just my prior on this. I don't think I've ever seen a mouse run backwards in a coordinated way, and certainly not 20-30 cm/s for an entire hour. But I agree, if any of the VBO sessions have video, it would be great to check them out as a sanity check. Do you know if video exists for any of these?

[DowntonCrabby]

I have seen sessions where mice don't run backwards but they like slowly flail backwards and accumulate a fair bit of distance over the course of a session. I suppose the last thing to check would be if all of the sessions that this occurs are in the same mouse/couple of mice. If so, it might be the mouse- if not then I think it's probably a glitch as was proposed.

[morriscb]

@DowntonCrabby Would you say that the VBO session running speed I posted above falls into that catagory? It looks to be running backwards at a consistent ~10 cm/s for the whole session.

[corbennett]

@morriscb This fix looks good!

[morriscb]

Cool. I'll hold off on merging to see what @DowntonCrabby finds as this change would effect both projects.

[morriscb]

Hey @DowntonCrabby, any updates on this from your end?

[DowntonCrabby]

Okay looking into this now and here's what I'm finding. This impacts 4 mice on 4 different rigs, all on different days:

To me this is some evidence that this is actually mouse behavior and not an issue with the wheel encoder.

To follow up I started looking at if other mice were run in the same boxes on the same days as the issue sessions and got mixed results:
For mouse 546819 in box Beh.G-Box1 it looks like there was another mouse run on all the same days that didn't have this issue so I think this is mouse-behavior and not an encoder error

For the other 3 mice, no other mice were run in the same box on the same day

[DowntonCrabby]

I guess I still tend to think this might be a behavior issue with mouse 563231 since it was consistent, but I'll try to track down some ophys sessions from these mice and review their running videos to see how much they run

[DowntonCrabby]

Okay so I tracked down some of the ophys sessions for these mice and watched the behavior videos for them and they were all running forward as usual. Given that- I'd say this is an encoder issue and not a mouse behavior issue.

Lets hit go on the fix!

[morriscb]

Cool. Thanks, Clark. I'll merge the fix into release candidate.

[DowntonCrabby]

Thanks for you patience Chris! Twas a long road