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.
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
.
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
:
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
.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
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
.