BehaviorSession should raise exception if a user tries to load a VBN session

[alexpiet]

Describe the use case that is addressed by this feature. The BehaviorSession object lets users load behavioral data from the training behavioral boxes as well as the ophys rigs. However, NP rig sessions are not supported by BehaviorSession and users should instead use VBNBehaviorSession. At the moment BehaviorSession.from_lims(behavior_session_id_from_NP_rig) will crash because of a failed lims query, but that crash is unstable and unpredictable. Instead, we should proactively catch this case, and alert the user they are using the wrong function, and pointed to VBNBehaviorSession.

Describe the solution you'd like When a user tries to load a BehaviorSession object using a behavior_session_id that corresponds to a NP rig session, an exception should be raised and the user should be alerted to the VBNBehaviorSession object

Describe alternatives you've considered Currently BehaviorSession crashes after a failed lims query, and provides no information to the user. I worry that relying on a failed lims query is unstable.

[danielsf]

For the record: the problem isn't arising strictly because you are instantiating a VBN behavior session with a class that was written for a VBO behavior session (though: that may be a problem; we haven't thought too hard about how much the unique processing methods we implemented for VBN ecephys sessions apply to the associated behavior-only sessions). The problem is that there are sessions in the LIMS behavior_sessions table with date_of_acquisition = NULL. In most cases, this is because the UPLOAD_TO_MTRAIN_QUEUE failed for the sessions at hand. We need to discuss what the long term solution is. One possibility is adding code to the SDK that, in the event that date_of_acquisition (or foraging_id) is NULL, the relevant data is read directly from the stimulus pickle file.

I apologize for being pedantic. This is mostly for whichever Pika ends up addressing this issue.

[alexpiet]

@danielsf Thank you for clarifying that the problem is due to date_of_acquisition = NULL on LIMS. I suspected something like that was the problem. Which is why I think BehaviorSession should either (1) fully support loading VBN Behavior sessions, or (2) proactively raise an error if they are attempted to load. I worry that at some point the underlying LIMS data issue might get resolved and then BehaviorSession could return without an error, but the data will be incorrect because VBN specific processing has not happened.

[alexpiet]

As I reflect on this, it seems like option (1) - making BehaviorSession support loading VBN sessions - should be reasonable. Are the behavioral streams (stimulus times, eye data, running, licking) that different on NP.1/0 vs the ophys rigs?

[aamster]

@alexpiet I tend to agree with you. You can take a look at the differences in the VBN specific behavior class

[danielsf]

Is the lesson of this rigamarole that there isn't one BehaviorSession class to rule them all and we need to have BehaviorSession classes associated with each data release, i.e.

VBO2021BehaviorSession VBN2022BehaviorSession etc.

?

They can inherit from each other, borrow methods as needed. The onus would be on the user to know which they want to load. This won't be a problem fro people loading from the NWB files, since the NWB files are all stored in data-release-specific caches anyway. Internal users would need to know "in the manner of which data release" they are loading data from LIMS.

Alternatively, internal users can just download the data release from S3 and be sure that they actually have the data released to the public.