• Learn to think about possible ensemble firing patterns and ways to characterize them
• Apply a permutation test (shuffle) to determine levels of chance (independent) co-occurrence

As you have seen in the module on decoding, hippocampal place cells tend to be active in specific locations within an environment. As a rat moves, it passes through a number of place fields:

Consider this rat moving from right to left on a linear track. Passing through the place field of each cell (indicated by different colored circles) the firing order will be blue-cyan-green-yellow-orange-red. This firing order corresponds to the order different locations in the environment were experienced.

In rats, memories of past experiences may be re-expressed in association with sharp wave-ripples (SWRs) in the local field potential: the spiking order of place cells during rest is correlated with the field order experienced in the environment (Wilson & McNaughton 1994; Foster & Wilson 2006; Karlsson et al. 2009). This non-local, ordered spiking activity has been called “replay”:

Shown schematically are three putative SWRs, associated with a “forward” replay (cells active in same order as experienced), an indeterminate replay (no order detectable; may be a replay of some different experience from which we do not know the correct place cell order), and a “reverse” replay.

Suppose we want to quantify how much a rat is recalling a certain trajectory (“experience”). We could identify how many times certain trajectories are replayed, like the left trajectory or the right trajectory along arms of a T-maze. There are a few ways of doing this, including co-activation analysis, sequence analysis, and decoding. This module will cover co-activation analysis.

Overview of sharp wave-ripple associated spiking activity analyses:

• Co-activation analysis (covered here): are place fields active together during sharp wave-ripple events?
• Sequence analysis: is spiking order (in time) correlated with field order (on the track)?
• Decoding: given what we know about field locations (tuning curves), does a given combination of spikes represent a place in the environment?

Co-activation or co-occurrence analysis allows us to examine the content of “replay” without direct reference to the field order of place cells in the environment. By grouping place cells into categories such as “left-arm place cells” and “right-arm place cells” we can ask if left cells are significantly more active together than right cells, which would suggest that the rat may have been recalling the left arm more frequently than the right arm.

The logic of looking at pairwise co-occurrence is illustrated in the figure above. If a random selection of cells is active in each SWR, then their co-occurrence would not differ from what we expect based on the activity of each cell individually. This is the case for the “red” cells D-E-F in the diagram. If, in contrast, spiking patterns during SWRs form sequences, then cells with nearby place fields will tend to be active together, as is the case for the “blue” cells A-B-C. This concept of co-occurrence will be made more explicit for real data in the steps below.

The overall workflow for co-occurrence analysis looks like this:

1. Generate candidate events: these are intervals that may contain replays, generally associated with sharp wave-ripple events (SWRs) in the LFP
2. Estimate place fields: get locations in the environment where cells increased their firing rates during behavior
3. Categorize place cells: we want cells that were active on the left or right arm only.
4. Make a Q-matrix: Bin spiking activity during SWRs.
5. Get cell participation during SWRs: are right or left cells more active during SWRs?
6. Get joint probability for cell pairs: how often are right cells active together? How often are left cells active together?
7. Get z-scored coactivity for cell pairs: are the cell pairs co-active at greater than chance levels? (If the cells are firing randomly, we still expect them to co-occur to some degree)

First, make sure you do a git pull as usual, and get the data. We'll be using session R064-2015-04-22. You'll also need to include the tasks\Alyssa-Tmaze and tasks\ReplayAnalysis folders in your path.

Then, we load the data:

% first, cd to where your data lives
LoadExpKeys
cfg = []; cfg.fc = ExpKeys.goodSWR(1);
CSC = LoadCSC(cfg);
 
cfg = []; cfg.load_questionable_cells = 1; % load all cells we've got
S = LoadSpikes(cfg);
 
cfg = []; cfg.convFact = ExpKeys.convFact; % conversion factor from camera pixels to centimeters (see PosCon())
pos = LoadPos(cfg);

Detecting putative sharp-wave ripple events based on thresholding power in a certain frequency band was introduced in Module 6. You can use your own code for detecting sharp wave-ripples (SWRs), or the code below (just make sure your variable containing detected intervals is called evt):

cfg = [];
cfg.type = 'fdesign'; % doit4me
cfg.f = [140 250]; % frequencies present in ripples
CSCf = FilterLFP(cfg,CSC);
 
% Obtain envelope
envelope = abs(CSCf.data);
 
% Convolve with a gaussian kernel (improves detection)
kernel = gausskernel(60,20); % note, units are in samples; for paper Methods, need to specify Gaussian SD in ms
envelope = conv(envelope,kernel,'same');
 
% Convert to TSD
SWR = tsd(CSC.tvec,envelope);
 
% Produce intervals by thresholding
cfg = []; 
cfg.method = 'zscore'; cfg.threshold = 3; % cut at 3 SDs above the mean
cfg.minlen = 0.02; % exclude intervals shorter than 20 ms
cfg.merge_thr = 0; % do not merge nearby events
evt = TSDtoIV(cfg,SWR); % evt is the set of candidate events
 
clearvars -except evt ExpKeys

Normally there is a lot more that goes on during candidate detection, such as the elimination of events that occur when the rat is moving too quickly, and but we will keep it simple for now.

☛ What other steps can you think of that may improve the detection of candidate SWR events? Scan the Methods sections of a few replay papers to see how they do it.

The basics of estimating tuning curves are covered here. Place cells can fire locally (in-field, when the rat is inside the place field) and non-locally (out-out-field, e.g. when the rat is at rest but recalling a previously experienced trajectory). Replay is an example of non-local firing, and it occurs during periods of quiescence. Since non-local firing can affect estimates of place field location, we exclude times when the rat was moving too slowly:

linspeed = getLinSpd([],pos); % linear speed
 
% Threshold speed
cfg = []; cfg.method = 'raw'; cfg.operation = '>'; cfg.threshold = 3.5; % speed limit in cm/sec
iv_fast = TSDtoIV(cfg,linspeed); % only keep intervals with speed above thresh
 
% Restrict data so it includes fast intervals only
pos_fast = restrict(pos,iv_fast);
S_fast = restrict(S,iv_fast);

The next step requires us to know more about the layout of the track used for this data set, so here it is:

• Rats performed 15-20 trials in one session, such as the one you have loaded.
• Rats experienced one of two possible trajectories during each trial: start-to-left, and start-to-right. The end of the left arm had a food reward, and the end of the right arm had a water reward.
• The red line indicates a left trajectory.
• Each trial shared the central arm in common. The intersection of the central arm and left & right arms is the choice point.
• Red and blue circles depict hypothetical locations of some place fields.

Our goal is to group the place cells into left and right categories, so we need to look at how cells were spiking when the rat went left or right. However, it’s not quite this simple because the rat often chose one arm far more often than the other, so we need to make sure we’re estimating place fields for the two groups with the same amount of position data. Let’s cheat by using an existing function called GetMatchedTrials():

LoadMetadata; % contains information about trial times
 
% Get equal numbers of trials
[trials.L,trials.R] = GetMatchedTrials([],metadata,ExpKeys);

Now we need to restrict the data to times when the rat was on the track (i.e. during trial intervals). At this point we separate the data into two different sets corresponding to arm choices or trajectories: left and right.

% Restrict position and spiking data to trial intervals (left and right groups)
pos_trial.L = restrict(pos_fast,trials.L);
pos_trial.R = restrict(pos_fast,trials.R);
S_trial.L = restrict(S_fast,trials.L);
S_trial.R = restrict(S_fast,trials.R);

Right now the position data exists in two dimensions (the horizontal plane), but it’s simpler to think of the data in one dimension, existing from the bottom of the Tmaze out to the end of either the left or right arm. To do this, we linearize the position data onto the left and right trajectories. Coordinates defining linear trajectories exist already in metadata, but they are in units of pixels so we need to standardize them to have a bin size in centimeters:

% Resample coords to have same number of pos units in each bin
cfg = [];
cfg.binsize = 3;
cfg.run_dist = ExpKeys.pathlength;
coord.L = StandardizeCoord(cfg,metadata.coord.coordL_cm);
coord.R = StandardizeCoord(cfg,metadata.coord.coordR_cm);
 
% Note that this step and several previous ones can be done in a more
% complicated loop like this, which guarantees that we haven't make L/R
% copy paste typos:
 
% Define arm categories
arms = {'L','R'}; % L is for the left arm and R is for the right arm
for iArm = 1:length(arms)
    coord.(arms{iArm}) = StandardizeCoord(cfg,metadata.coord.(['coord',arms{iArm},'_cm']));
    % this reads as:
    % coord.L = StandardizeCoord(cfg,metadata,coord.coordL_cm); when iArm = 1
    % coord.R = StandardizeCoord(cfg,metadata,coord.coordR_cm); when iArm = 2
end
 
% Linearize position data onto L and R coordinates
cfg = [];
cfg.Coord = coord.L;
linpos.L = LinearizePos(cfg,pos_trial.L);
cfg.Coord = coord.R;
linpos.R = LinearizePos(cfg,pos_trial.R);
 
% Here is another example of the hard-to-read loop for the linearization step:
for iArm = 1:length(arms)
    cfg = []; cfg.Coord = coord.(arms{iArm});
    linpos.(arms{iArm}) = LinearizePos(cfg,pos_trial.(arms{iArm}));
end

Finally, we can use our restricted spike trains and restricted linearized position data to get place field estimates along the trajectories:

% Get place fields ("PF") for L and R trials.
cfg = [];
cfg.binSize = 1;
PF.L = MakeTC(cfg,S_trial.L,linpos.L);
PF.R = MakeTC(cfg,S_trial.R,linpos.R);

☛ Plot the tuning curves for the left and right arms. imagesc() is a good way of doing this.

☛ Why do we say place fields are “estimated” instead of, say, obtained or computed?

So far, we have place fields (PF) for all cells that were active during left or right traversals of the track, including cells that were active on the central arm and cells that were active on both arms. We need to keep cells that were responsive to a single arm of the track.

To exclude central arm cells, we can select cells with fields that are located beyond the choice point:

% Linearize choice point so that it exists in the same units as the
% linearized position data:
chp_tsd = tsd(0,metadata.coord.chp_cm,{'x','y'}); % make choice point useable by cobebase functions
cfg = []; cfg.Coord = coord.L;
chp.L = LinearizePos(cfg,chp_tsd); % the exact chp for L or R differs depending on the coord
cfg.Coord = coord.R;
chp.R = LinearizePos(cfg,chp_tsd);
 
% Get indices for cells with fields after the choice point
fields.L = PF.L.field_template_idx(PF.L.field_loc > chp.L.data(1));
fields.R = PF.R.field_template_idx(PF.R.field_loc > chp.R.data(1));

The fields struct contains indices of the cells that were not active on the central arm. However, we still need to account for some cells having fields on multiple arms:

% Remove cells that are active on both arms
[~,remove.L,remove.R] = intersect(fields.L,fields.R); % intersect tells us which of the indices are common to both groups
fields.L(remove.L) = [];
fields.R(remove.R) = [];

As a last step, we need to make sure that each cell appears only once in the list (if a cell has multiple fields on the same arm, we don’t want to keep multiple copies of that cell in our analysis):

% Some cells have double place fields on the arms, so they are present
% twice in the list of cells. Remove them.
fields.L = unique(fields.L);
fields.R = unique(fields.R);

(Aside: The function unique() returns sorted output, so the cells will no longer be ordered according to field location like they are when output from MakeTC(). This is not an issue for co-occurrence analysis, but is for sequence analysis.)

Now that we have the indices describing which cells have fields on the left or right arm only, we can select them from our original spike train:

% Select place cells using the indices in the fields struct
% Note that we're indexing into the *original* non-restricted collection of
% spiketrains
S_arm.L = SelectTS([],S,fields.L);
S_arm.R = SelectTS([],S,fields.R);

A Q-matrix is organized such at each row represents a neural unit and each column represents a candidate that units are potentially active in. Thus, each element of the Q-matrix is a count of the number of spikes emitted by the corresponding neural unit in the corresponding time bin. Below, we'll use an existing function, but it is not much more than a wrapped version of the built-in fuction histc():

% There is an existing function that makes a Q-matrix from spiketrains and
% candidate intervals
cfg = [];
cfg.win = 0.1; % In seconds, the binsize for containing spikes. i.e. the interval boundaries are redrawn to all have length 100 ms. If empty [], the exact candidate boundaries are used
Q.L = MakeQfromS2(cfg,S_arm.L,evt);
Q.R = MakeQfromS2(cfg,S_arm.R,evt);

This Q-matrix contains the number of times 10 different left-arm place cells spiked during 1017 candidate, or sharp wave-ripple, events.

Consider column 17 for the “left” cells (Q.L(17,:)): cell 9 spiked three times, cell 5 spiked twice, and cell 4 spiked once. These left arm cells co-occurred during the same candidate interval.

★ Why don't we just look at single-cell activation? Under what conditions would the results from that be the same, or different, from pairwise co-occurrence?

This module was developed by Alyssa Carey.