Introduction
As demonstrated in vignette("APackOfTheClones"), after
processing the seurat & clonotype data properly with
scRepertoire, vizAPOTC provides a direct way
to produce the ball-packing clonal expansion visualization, though for
select users it may be somewhat clunky, if certain parameters need to be
readjusted constantly. In this vignette, more details about how
APackOfTheClones runs can be stored and re-adjusted will be covered -
mainly through RunAPOTC, APOTCPlot, and
AdjustAPOTC. Ensure to read the aforementioned vignette
before this one.
As a reminder, here’s how to set up the seurat object and
clonotype data
Overview
All of vizAPOTC’s arguments are actually derived from
RunAPOTC and APOTCPlot. The former is
responsible for storing data of the S4 class ApotcData in
the seurat object under a named list in
@misc$APackOfTheClones under some character run ID, and the
latter allows the visualization of these data objects with some
customization. AdjustAPOTC has many arguments for adjusting
the data associated with some APackOfTheClones run stored by
RunAPOTC, including adjusting cluster positions, colors,
repulsion, etc. which can be visualized again with
APOTCPlot.
Managing APackOfTheClones run data
RunAPOTC has approximate the first half of
vizAPOTC’s arguments until max_repulsion_iter,
meaning it has all the data subsetting, circle size scaling, and cluster
repulsion capabilities covered in the previous vignette. The most
essential difference is the presence of the argument
run_id, which corresponds to an id for the
ApotcData object. If left blank, one will be automatically
generated in the following format:
reduction_base;clonecall;keyword_arguments;extra_filter
where if keyword arguments and extra_filter are underscore
(_) characters if there was no input for the
... and extra_filter parameters.
From the verbal queues, one can see how the run_id was
set. Here’s it ran again but with more optional arguments and a custom
run_id:
Utilities for Managing APackOfTheClones Runs
It is to note that the data abstraction here with a
run_id is intentional, and users should not manually touch
any of the ApotcData objects with the seurat object unless
they are extremely familiar with the latest internal implementation.
Instead, here is a collection of functions that may be useful:
getApotcDataIds(pbmc) gets all current
run_id’s, if any.getLastApotcDataId(pbmc) gets the latest
run_id, if any.containsApotcRun(pbmc, run_id = "foo") returns whether
a run_id exists in the seurat object.deleteApotcData(pbmc, run_id = "foo") deletes all
data associated with a certain run_id.
APOTCPlot
To visualize stored APackOfTheClones runs, APOTCPlot
takes in a seurat object and the run_id. If no
run_id is provided, it defaults to using the latest run.
All other parameters are same as in the second half of
vizAPOTC. Although it is noteworthy that if the user had
always relied on auto-generated run_id’s then
APOTCPlot also has these subsetting arguments:
And putting in identical arguments to generate the original
ApotcData would work too, but this approach is less
recommended as its a lot more (unnecessarily) verbose. Here is
APOTCPlot in action:
#> * using the latest APackOfTheClones Run Data with object id: P19
AdjustAPOTC
This function’s parameters help modify certain attributes about
APackOfTheClones runs, and has the exact same first six parameters as
APOTCPlot for managing which run to modify. It also
possesses the same four repulsion arguments in vizAPOTC and
RunAPOTC if a run is to be repulsed again. See the function
level documentation for the following parameters that can modify cluster
locations, colors, and the adjustment of the
clone_scale_factor and rad_scale_factor.